Comments 4
Спасибо за статью! Очень откликается. У нас в команде есть проблема: при планировании многие задачи сначала кажутся «простыми», а потом выясняется куча скрытых нюансов, и сроки съезжают. Из-за этого оценки часто оказываются заниженными, и команда начинает терять доверие к планированию вообще.
Оцениваем в человеко-часах, потому как сторипоинты не отвечают прямо на вопрос,когда будет готово. Проблемы всегда возникают изза того, что обьем работ не всегда виден полностью. Зачастую понятно становится только тогда, когда исполнитель полностью пооружается в задачу и часть уже делает. Также часты случаи, когда происходит затык на какой то детали, что то может упорно не хотеть работать и поиск решения занимает дополнительное время. Бывает, аналитика описала в задачах все не так, как есть на самом деле. Много факторов, потому зачастую время хоть и проставлено, но верить ему нельзя. И это при том, что в отрасли достаточно долго, больше десяти лет, точные оценки все равно не даю. Просто оценивать только тогда, когда функционал новый, и уже разрабатывался в подобном виде N раз.
Благодарю за комментарий! Полностью согласен: помимо story points, на крупных проектах также хорошо использовать оценку времени (Time Estimated) и сопутствующие параметры — Time Remaining, Time Logged. В дальнейшем было также полезно выводить данные по проекту для отслеживания отклонений в оценках и фактическом затраченном времени, что поможет лучше определить буфер.
И конечно при работе с задачами необходимо максимально подробно их анализировать, декомпозировать и использовать acceptance criteria для четкого определения готовности. Лайк и подписка!
Scrum & Estimates! Погружаемся в теорию вместе, плюс кейсы из практики