Зачем мы тратим время на оценки?

Эта статья подготовлена для блогов журнала PCWeek.
В современных технологиях разработки программного обеспечения одним из основных камней преткновения является оценка трудоемкости выполнения задач. Ошибка при оценке может достигать нескольких раз. Именно это демонстрирует конус неопределенности, предложенный Барри Бемом в 1981 году (изображение с сайта http://infostart.ru/):

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

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

Планирование на стене (столе или еще какой-то поверхности) проводится «в открытую». Все требования записываются на стикерах. На плоской поверхности изображаются зоны с оценками. Каждый волен взять стикер из кучи или уже закрепленный на стене и повесить его в зону с той оценкой, которую он считает наиболее целесообразной для этого требования:

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

Эти грубые оценки в Scrum применяются для определения  производительности команды в рамках итерации – Velocity. Ну, а выяснив производительность, можно планировать, какое количество спринтов понадобится, чтобы реализовать оставшиеся в Backlog-е требования.

Цель хорошая, а вот стоит ли тратить время на оценку в команде, которая работает длительное время? И мой ответ– нет. Посмотрим на данные команды, которая работает уже несколько лет с незначительным изменением состава.

Привожу данные за 11 спринтов с 20 декабря 2013 года по 18 июня 2014:

Рассмотрим  эти данные в разрезе спринтов.

Последняя строка - это отношение суммарного веса требований к их количеству. Бросается в глаза, что значения очень близки друг к другу. Математическое ожидание для этого отношения составляет 2,59. Дисперсия составляет всего 0,15. Эти данные позволяют сделать вывод, что дальнейшие оценки требований в этой команде не имеют смысла. Можно ставить оценку 2,59 и, в рамках итерации, большие требования, которые были недооценены, будут компенсированы маленькими требованиями, которые переоценили.

Т.е. при производительности команды в 65 единиц в спринт можно брать 25 требований из вершины Backlog-а. Это подтверждается правой частью представленной таблицы, где как раз количество требований на итерацию колеблется в районе 25-ти. В левой части в связи с новым годом и производственной необходимостью размер итерации был меньше и колебался от нескольких дней до двух недель.
Подводя итоги, можно сделать вывод, что на начальном этапе формирования команды оценки нужны, без них нельзя будет определить производительность команды, да и среднюю оценку будет не посчитать. А вот для команд, работающих достаточно длительное время, смысл такой оценки теряется.