Оценка. Часть 2

В данной статье речь пойдет о разных уровнях оценки (проект, версия, спринт) и о том, как и кто проводит оценку.


Первую часть Вы можете прочитать здесь – http://www.agile.by/2009/03/05/ocenka-chast-1.html. В ней рассматривалась разница между воспринимаемой и объективной точностью (достоверностью), а также разница между реальными, идеальными, инженерными часами и story points.

Разные уровни оценки

Планировать можно на уровне всего проекта, на уровне какой-то отдельной поставки, на уровне спринта. Для каждого уровня целесообразно выбирать свою единицу измерения. Например, если «на глазок» весь проект займет 3 года, то не стоит производить высокоуровневую оценку в часах. Аналогично, для оценки задач в спринте нет смысла использовать месяцы. Но важно, чтобы в рамках одного уровня использовались одни единицы – иначе возникнет путаница.

Рассмотрим 3 уровня:

  • Проект в целом
  • Milestone
  • Спринт
Проект в целом

Заказчик почти всегда хочет знать, сколько ему будет стоить проект, и как быстро он будет сделан. Поэтому необходимо уметь оценивать проект (что представляет собой нелегкую задачу).

Для проекта в целом можно использовать любую единицу измерения. Детальность должна выбираться в зависимости от предполагаемой длительности проекта.

На уровне проекта в целом (за исключением очень маленьких проектов) время на завершение конкретной истории (как правило, есть смысл работать именно на уровне историй, а не задач) не слишком критично, кроме тех случаев, когда от решения этой задачи зависит много других. Достаточно того, сколько историй выполнено, сколько осталось, сколько времени еще нужно на то, чтобы их закончить.

Milestone

В целом, как и для проекта, за небольшими изменениями. Точность должна быть выше. Если используется оценка в story points, то желательно использовать в качестве базовой историю, которая является базовой в рамках всего проекта, а не только этой поставки. В случае небольшой длительности возможна работа на уровне задач, а не историй.

Спринт

На уровне спринта нам необходимо не только оценить, сколько мы успеем сделать, но и отслеживать статус спринта. В целом абсолютная оценка времени (реальные, идеальные или инженерные часы) больше подходит для этого уровня, так как позволяет более адекватно оценивать время, необходимое для завершения задачи.

Процедура оценки

Когда определились с тем, что оцениваем, в каких единицах, с какой точностью, необходимо понять, кто и как это должен делать.

Кто оценивает

Задачи в спринте и milestone’e оценивает команда (возможно привлечение эксперта в сложных случаях).

Есть несколько вариантов того, кто может оценивать проект в целом:

  • PM
  • Эксперт/группа экспертов (PM как организатор)
  • PM + Tech/team lead
  • Команда (PM как организатор или участник)
  • Команда + эксперт (PM как организатор или участник)
PM

Когда проект оценивает только PM, то это наиболее недорогой и, как правило, наиболее быстрый способ оценить проект. Но есть и ряд минусов:

  • PM должен разбираться в технологиях/предметной области (или иметь хорошую базу проектов, с которой можно сравнить)
  • Если нет опыта подобных проектов, то PM может не учесть некоторые серьезные риски
  • Для команды эти оценки являются внешними, так что особого энтузиазма не вызовут
Эксперт/группа экспертов (PM как организатор)

Как правило, оценка, полученная таким образом, одна из наиболее адекватных: учтены возможные риски, есть представление о том, сколько на самом деле занимает та или иная история. Но необходимо правильно скорректировать оценки экспертов для уровня команды. И для команды эти оценки опять-таки внешние.

PM + Tech/team lead

Этот вариант устраняет ряд проблем варианта, когда оценку производит один PM: больше вероятность правильно учесть основные риски, более глубокая техническая экспертиза, для команды эти оценки чуть ближе (так как TL принимал участие в оценке).

Команда (PM как организатор)

Плюсы:

  • Команда принимает оценки и несет за них ответственность
  • Учитывается реальный уровень команды
  • В случае опытной команды будут учтены большинство технологических рисков

Минусы:

  • Если команда не имеет опыта оценки, то есть большая вероятность недооценки/переоценки
  • Для правильной оценки необходим опыт в данной области/технологии
  • Зачастую на этапе оценки состав команды неизвестен
Команда + эксперт (PM как организатор)

Немного более дорогой, но и более надежный вариант, чем предыдущий – эксперт привнесет в оценку дополнительный опыт.

Как оценивать

Когда оценивает один участник, то особых вопросов не возникает – важную роль играет его опыт в оценке и понимание области.

Если оценивает группа, то необходимо, чтобы у каждого участника было четкое понимание, что включается в оценку, а что нет (например, тесты, рефакторинг и т.д.).

Так как в результате для каждой истории должна быть только одна оценка, то необходимо определиться, как ее получать.

Закрытое или открытое голосование

Открытое голосование – это когда участники по очереди называют свою оценку. Из потенциальных проблем – если первым называет оценку человек, обладающий авторитетом, то остальные могут проигнорировать свою оценку, и согласиться с лидером. Это может привести к пропуску важных деталей или отсутствию ответственности за оценку.

Закрытое голосование – каждый участник выдает свою оценку, но эта оценка не сообщается другим, пока все участники не дадут свою.

Одним из популярных вариантов закрытого голосования является poker planning. У каждого участника есть набор карточек с оценками. Допустимые оценки на карточках выбраны таким образом, чтобы точность соответствовала размеру задачи. Когда оценивается задача, карточка кладется оценкой вниз. Когда все участники положили свои карточки, они переворачиваются.

Выбор одной оценки

Если все оценки очень близки, то проблем не возникает. Но что делать, когда оценки сильно отличаются? Опять-таки, существует несколько вариантов:

  • Можно просто взять среднюю оценку
  • Можно взять максимальную оценку
  • Попросить объяснить тех, кто дал минимальную и максимальную оценку, почему они так считают, и после этого провести оценку еще раз

Третий вариант наиболее трудоемкий, но позволяет получать наиболее взвешенные и обоснованные оценки.

Оценка нужна, но она не есть самоцель

Не стоит бояться оценки, или говорить, что у нас agile, поэтому никакой оценки. Если заказчику надо знать, сколько примерно будет стоить данный проект, то необходимо предоставить такую информацию.

Владея несколькими техниками оценки, вы сможете в каждом конкретном случае выбрать ту, что лучше всего подходит в данном случае.

Но не забывайте – затраты на оценку должны быть разумными. Нет смысла тратить на оценку 3 недели для проекта в 2 месяца. Все-таки (не считая редкие исключения), конечная задача проекта по создания ПО – это само ПО, а не оценка, сколько времени займет его создание.

Полезные ссылки

To be continued

Следующая часть будет представлять собой описание того, как оценка выглядит на практике.

Post Author

This post was written by who has written 29 posts on Agile.by.