Резюме
Разработчики и руководители проектов редко правильно оценивают продолжительность проекта и вследствие этого часто назначают нереалистичные даты поставки. Метод оценок, основанных на данных, позволяет увеличить точность прогнозов и предоставляет доверительный интервал для оценок даты поставки
Суть метода
- Разбить все задачи до уровня очень мелких тасков, по нескольку часов на таск, максимум 16 часов, лучше, чтобы большая часть укладывалась в 8. Оценить трудоемкость тасков должны разработчики, которые непосредственно будут заняты выполнением этих задач.
- Отслеживать фактически затраченное время, причем в эту цифру должны входить все незапланированные перерывы в работе над таском и все исправления багов, связанных с этим таском. Для каждого разработчика вести учет соотношения фактического времени и оценки. Как правило, у точного “оценщика” этот коэффициент не будет сильно варьировать и будет стабильно меньше единицы (т.е. разработчик - оптимист). Этот коэффициент называют velocity - скорость (какое-то некорректное название, по-моему)
- Симулировать будущее. Для всех оставшихся на проекте задач нужно поделить оценку времени на случайную “скорость” из истории. Если известно, что задачу будет выполнять конкретный разработчик - то брать скорость из его конкретной истории. В результате получится реалистичная оценка проекта в часах. Повторить это пару сотен раз - и можно будет построить кривую плотности вероятности закончить проект к какой-либо дате. На основе этих данных уже можно рассматривать какие-то конкретные диапазоны дат поставки.
- Ну и можно заложить в общую оценку времени проекта некий буфер на непредвиденные технические сложности, новые фичи и т.п.