Я решил оставить на своей странице перевод статьи, которая часто меняет восприятие руководителями процесса планирования. Уверен, это будет полезно.
Ссылка на оригинальный текст https://www.scruminc.com/story-points-why-are-they-better-than
Story Points: чем они лучше часов?
Story points дают более точные оценки, они радикально сокращают время планирования, они точнее предсказывают даты релиза и помогают командам повысить производительность. Часы дают худшие оценки, вносят большие объемы отходов в систему, затрудняют планирование релиза владельцем продукта и сбивают команду с толку относительно того, какие улучшения процесса действительно сработали.
Появилось новое интересное исследование. Standish Group обновила свои выводы о показателях успешности проектов на основе анализа данных за последнее десятилетие с десятками тысяч точек данных. Кроме того, у Microsoft есть новые результаты исследований, показывающие, что гибкая оценка поразительно точнее традиционной оценки проектов.
Для любознательных) https://collaboration.csc.ncsu.edu/laurie/Papers/ESEM11_SCRUM_Experience_CameraReady.pdf
Многие люди, которые управляли проектами с часами, с трудом понимают, почему Story Points лучше. Они не смогли понять некоторые фундаментальные данные, которые публиковались в течение более 60 лет в отраслевой литературе, а также последние исследования.
Сначала давайте рассмотрим последние данные о провалах проектов. Показатели провалов растут для ИТ-проектов в условиях текущего сбоя в работе мировой финансовой системы. Последний анализ Standish Group показывает, что agile-проекты имеют в три раза более высокий показатель успешности, чем традиционные проекты. Джим Джонсон теперь рекомендует повсеместно использовать agile-практику во всех проектах.
Фактически, последние исследования Forrester Group показывают, что общие показатели управления проектами обрекают ИТ-отделы на провал.
Венчурные капиталисты, с которыми я работаю, говорят, что они никогда не видели правильной диаграммы Ганта на заседании совета директоров. Когда они углубляются в проблему, они говорят, что никто из их управленческих команд не знал скорости своих команд до внедрения Scrum. Незнание скорости производства команд является основной причиной 100%-ной неточности планов релизов на заседаниях совета директоров.
Стабильность пользовательской истории имеет решающее значение для планирования. История из трех пунктов сегодня — это история из трех пунктов в следующем году, и она является измеримой частью выпуска продукта для владельца продукта. Часы на создание истории зависят от того, кто ее делает и в какой день этот человек ее делает. Это меняется каждый день. Диаграмма Ганта предполагает фиксированное количество часов для некоторого вымышленного человека (который часто не является тем человеком, который должен внедрять) и предполагает фиксированные зависимости (которые всегда меняются). Исследование 80 многомиллионных проектов в GSI Commerce (теперь принадлежит eBay) показало, что лучшие эксперты в компании были совершенно неспособны оценить, сколько времени займет проект у людей, которые фактически его внедряют.
Можно было бы подумать, что эти данные заставят людей изменить свое поведение, но многие компании, похоже, предпочитают продолжать терпеть неудачи и быть поглощенными или банкротиться, вместо того чтобы совершенствовать свои методы управления проектами.
Исследования Rand Corporation в 1940-х годах ясно показали, что люди не очень хороши в оценке часов, и практический опыт неоднократно подтверждает это исследование. Рекомендованный подход Delphi к оценке был принят в разработке программного обеспечения как метод Wide Band Delphi . Этот же метод теперь встроен в практику, называемую Planning Poker для гибких команд.
И снова для любознательных) https://en.wikipedia.org/wiki/Wideband_delphi
Метрикой управления для реализации проекта должна быть единица продукции. Производство является предпосылкой для дохода, и компании говорят, что они занимаются бизнесом для увеличения дохода и маржи (хотя при планировании проектов они часто делают наоборот). По крайней мере, группа венчурного капитала ясно понимает, что все дело в деньгах, а деньги поступают от скорости производства в сочетании с качеством продукта. Часы — это расходы, и их следует сокращать или исключать, когда это возможно.
Лучшие данные по производительности отдельных разработчиков получены из Йельского университета и ранее уже были опубликованы в этом блоге. Лучшему разработчику в проекте требуется один час, чтобы выполнить задачу, в то время как худшему разработчику требуется 10 часов (в рамках проекта) или 25 часов (между проектами). Для команд разница на порядок больше. Опубликованные данные Ларри Патнэма показывают, что час для самой продуктивной команды превращается в 2000 часов для наименее продуктивной команды.
Затраченные часы ничего не говорят владельцу продукта о том, сколько функций он может выпустить и когда он может их выпустить.
Важной метрикой является количество очков истории, которые команда может предоставить за единицу календарного времени. Очки за спринт — это скорость. Поэтому мы оцениваем все в очках для владельца продукта, чтобы он создал дорожную карту релиза на основе скорости команды и скорректировал план, если скорость изменилась.
Метод оценки Story Points, который мы используем, дает лучшие оценки, чем почасовые оценки, поскольку они более точны и имеют меньше отклонений. Компания CMMI уровня 5 определила, что оценка Story Points сокращает время оценки на 80%, позволяя командам выполнять больше оценок и отслеживания, чем типичная команда водопада. Телекоммуникационная компания заметила, что оценка Story Points с помощью Planning Poker была в 48 раз быстрее, чем практика оценки водопада в компании, и дала такие же хорошие или лучшие оценки.
Таким образом, Story Points быстрее, лучше и дешевле, чем часы, а самые эффективные команды полностью отказываются от любой почасовой оценки, поскольку считают ее пустой тратой, которая только замедляет их работу.