Закоулки мозга

Источник, Упоминание

Резюме

Разработчики и руководители проектов редко правильно оценивают продолжительность проекта и вследствие этого часто назначают нереалистичные даты поставки. Метод оценок, основанных на данных, позволяет увеличить точность прогнозов и предоставляет доверительный интервал для оценок даты поставки

Суть метода

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