Всем привет!

Хочу сравнить разные способы оценки задач в разработке.

1) «честная» трудоемкость. Честная я взял в кавычки не потому, что она не реалистичная/оптимистичная. А потому, что на самом деле она в большинстве случаев не честная, т.к. не устраивает риски и фокус-фактор. Пример рисков: нечеткая постановка задачи, сломавшаяся локальная сборка, сломавшийся pipeline, неработоспособность стендов, проблемы у смежника, болезнь. В теории даже про то, что часть спринта попадает в отпуск можно забыть) Пример не учета фокус-фактора - часть времени участника команды тратится на Agile церемонии, на отдых в рабочее время, менторство, код-ревью, помощь коллегам, семинары, митапы...
Собственно, по этим двум причинам чистая трудоёмкость совсем не равна календарному времени. И поэтому это самый плохой способ оценки. Из плюсов - только простота.

2) оценка с учётом рисков и фокус фактора. Подходит для экспресс оценки задачи до передачи ее в команду. Это может быть или типовая задача для нескольких команд, например, миграция, или просто сложная и важная задача, еще не распределенная в команду.
Главный минус данной техники - зависимость от опыта конкретного эксперта и отсутствие учета особенностей команды. Но для экспресс оценки это не важно.
Особое внимание стоит обратить на прозрачность используемых повышающих коэффициентов. Иначе эти коэффициенты будут дублироваться на каждом уровне иерархии компании, что приведёт к экспоненциальному росту финальной оценки

3) story points. О минусах этой методики писал ранее https://t.me/javaKotlinDevOps/104
Плюсы: учет особенностей команды (velocity), оценка непосредственно исполнителями, согласование внутри команды.
Хорошо работает для оценки story, кроме первого релиза, т.к. со временем у опытной команды story должны стать похожими. Также хорошо работает и для задач внутри спринта при выполнении 2 условий: команда fullstack разработчиков и участники примерно одного уровня. Ну или когда в команде для большинства участников выполняются эти условия. Иначе мы получим, что из 8 человек, оценивших задачу по бэк разработке, только 2 примерно понимают ее трудоёмкость) Или в команде из 1 сеньора и 4 джунов оценки будут сильно смещены к уровню джунов, и сеньор часть времени будет «курить бамбук»)

4) capacity planning.
Решает большинство проблем story points. Вводится коэффициент фокус-фактора, причём оценка даётся со стороны исполнителя. Вводится коэффициент «сеньорности» для учёта разницы в опыте. Команда делится на группы: бэк, фронт , аналитики, тестировщика, оценка идёт только внутри группы. Сразу видно, когда не хватает трудоёмкости конкретной группы, например, тестировщиков, для выполнения задачи «под ключ» за спринт. Т.к. оценка в человеко-часах - проще понять, где затык внутри спринта и больше личной ответственности. При этом все плюсы story points сохраняются.
Соответственно, хорошо подходит для оценки задач внутри спринта.

5) диаграммы Ганта.
Главный плюс - учёт взаимозависимостей задач и наглядное представление точки во времени, куда сходятся все задачи.
Главный минус - сложность и необходимость ПО. Сфера применения: макропланирование на несколько команд для сложных интеграционных задач.

#planning #agile