Если задача новая и ты ранее её никогда не «щупал» (за телеса), бесполезно угадывать, сколько времени займет задача. Можно долго «тыкать пальцами в небо» и проводить другие ритуалы, чтобы явилась реальная оценка задачи — не получится достоверно её выявить, пока задача не будет сделана. Звучит как парадокс, но доля правды в этом есть.
Фух, добрались до важного! Оценка — это не попытка угадать, сколько займет задача. Оценка — это договоренность между заказчиком и исполнителем о рамках и способе выполнения задачи.
Внутри нашей компании мы часто вводим внутренние правила работы с задачами. Они необходимы для того, чтобы организовать процесс работы как разработчика так и движения разработки на проекте, и чтобы PM не вышел из окна при сдаче отчетности заказчику.
На самом деле все достаточно просто: перед тем, как брать задачу в работу, а также включать задачу в спринт, у нее должна быть оценка. При планировании спринта стоит провести общий митинг, обговорить с командой задачи, которые будут выполнены в ближайший спринт и пройтись по оценкам. Это даст возможность спланировать нормальную загрузку. Нормальную — это когда разработчики не проклинают PM, представляя его в адском котлище.
После того, как задача была взята в работу, и время, которое было дано в оценке выработано — оценку можно изменить, но только после того, как в известность будет поставлен PM, а разработчик грамотно разъяснит, почему так вышло (а вообще он белый и пушистый и не виноват). После обсуждений составляем план дальнейших действий. Обычно согласовываются дополнительные часы с заказчиком и задача доводится до завершения.
По итогам спринта проводим ретроспективу, делаем сводный анализ по планируемым vs затраченным часам и прорабатываем стратегию, как в дальнейшем избегать таких ситуаций.
Эти правила позволяют избежать перевес часов разработки за оценку задачи, без ведома PM’а. Тем самым, при подготовке отчетности и при сведении часов не будет каких-то неожиданных сюрпризов, разъяренного PM’а и хлопающего глазами разработчика.