Чтобы оценить объем работы над Элементом Бэклога Продукта, Скрам-команды обычно используют Стори Поинты. Это условная величина, позволяющая давать Элементам Бэклога относительные веса. Чаще всего для оценки в Стори Поинтах используются числа Фибоначчи (1, 2, 3, 5, 8, 13, …), что позволяет провести оценку достаточно быстро.
Ниже — перевод статьи Джеффа Сазерленда Story Points: Why are they better than hours? с сайта Scrum Inc.
Чем Стори Поинты лучше человеко-часов?
Стори поинты дают более точную оценку, существенно уменьшают время планирования, позволяют лучше прогнозировать дату релиза и повышают производительность команд. Традиционная оценка в человеко-часах является менее точной, приводит к лишним потерям времени на оценку, мешает Владельцу Продукта планировать релиз и не позволяет команде понять, какие из внедренных улучшений процесса действительно сработали.
Точность оценок
Последние исследования от Microsoft показывают, что оценка по agile демонстрирует поразительную точность в сравнении с традиционными методами оценки проектов. Подробнее об этом исследовании вы можете почитать здесь:
Scrum + Engineering Practices: Experiences of Three Microsoft Teams
Многим людям, имевшим опыт управления проектами с оценкой в часах, сложно понять, почему стори поинты работают лучше. Им также сложно принять некоторые фундаментальные факты, которые публикуются в профильной литературе уже в течение 60 лет, равно как и последние исследования, которые только подтверждают их правильность.
Успешность проектов
Давайте посмотрим на последние данные по неуспешным проектам. Глобальная финансовая система рушится, и вместе с этим растет процент провальных проектов в IT. Недавно было проведено одно интересное исследование: консалтинговая фирма Standish Group собрала данные об успешности нескольких десятков тысяч проектов, стартовавших за последние десять лет. Аналитика от Standish Group показывает, что процент успешности agile-проектов в три раза превышает успешность проектов, ведущихся традиционным образом. Джим Джонсон рекомендует использование agile-практик на всех без исключения проектах.
Также последние исследования Forrester Group говорят, что традиционные метрики управления проектами приводят IT-департаменты к неудачам.
Разрыв между оценками сроков и реальностью
Венчурные капиталисты, с которыми я работаю, признаются, что никогда не видели актуальную диаграмму Ганта на встречах правления компаний. Исследуя проблему глубже, они обнаружили, что до внедрения скрама никто из руководства вообще не знал реальной производительности своих команд, и это в 100% случаев озвучивается на встречах правления как главная причина несоблюдения даты релиза.
Дело в том, что для планирования релиза критичным является постоянство пользовательских историй. Три стори поинта сегодня — это те же три стори поинта в следующем году, и для Владельца Продукта эти стори поинты являются измеримой частью релиза продукта. Тогда как количество часов для завершения истории зависит от того, кто ее делает и в какой день. Эти показатели меняются ежедневно. Диаграмма Ганта предполагает фиксированное количество часов на задачу для какого-то гипотетического человека (который зачастую не является фактическим исполнителем задачи) и заведомо известные зависимости (которые на самом деле непрерывно меняются). Исследование восьмидесяти мультимиллионных проектов, проведённое в GSI Commerce (ими сейчас владеет eBay), показало, что лучшие эксперты в компании оказались неспособными правильно оценить время выполнения проекта людьми, которые действительно его реализовывали.
Вам может показаться, что эта статистика могла бы заставить людей поменять своё поведение, но многим компаниям, похоже, проще продолжать терпеть убытки или даже банкротство вместо того, чтобы изменить свои принципы управления проектами.
Вариабельность оценок
Исследование, проведенное Rand Corporation еще в 1940х годах, очевидно продемонстрировало неспособность людей точно проводить оценку в часах, и практический опыт постоянно подтверждает этот факт. Вместо часов для оценки рекомендуется использовать метод «Дельфи», известный в разработке программного обеспечения как техника Wide Band Delphi. Аналогичная техника используется agile-командами и носит название Покер планирования.
Интересные данные по личной продуктивности разработчиков пришли из Йельского Университета. Лучшему разработчику на проекте требуется один час, чтобы сделать задачу, в то время как худшему требуется 10 часов (в рамках его проекта) или даже 25 (если проект незнакомый). Для команд эта разница еще на порядок больше. Данные, опубликованные Ларри Путнемом (Larry Putnam) показывают, что задача, на которую наиболее продуктивной команде требуется час, может превратиться в 2000 часов для наименее продуктивной команды.
Процесс оценки в стори поинтах дает лучшую точность, чем оценка в часах, за счет меньшей вариативности стори пойнтов. Одна компания 5го уровня CMMI определила, что оценка в стори поинтах сокращает время оценки на 80%, что позволяет оценивать больше фич и отслеживать их, в сравнении с каскадной моделью. Другая компания из телеком индустрии заметила, что оценка с помощью стори поинтов и Покера планирования была не только в 48 раз быстрее, чем практики каскадной оценки, но и дала более точные результаты.
Мера прогресса
Для руководства мерой прогресса является законченный функциональный элемент, поэтому важно, чтобы каждая поставка была новым шагом на этом пути. Рабочий функционал является предусловием для получения прибыли, а ведь любая компания создается для увеличения прибыли (даже если при планировании проекта неосознанно делается прямо противоположное). По крайней мере, венчурные капиталисты уверены в том, что компании работают ради денег, и для денег важны скорость производства и качественный продукт. А человеко-часы — это затраты, которые необходимо уменьшать или вообще избавляться от них везде, где это возможно.
Число потраченных часов не дает Владельцу Продукта никакой информации о том, сколько фич можно поставить и когда.
Что действительно является важной метрикой, так это количество стори поинтов, которую команда может поставить за календарный период. Число поинтов за спринт — это производительность команды (velocity). И несмотря на то что все оценки происходят в стори поинтах, Владелец Продукта делает план релизов на основании производительности команды и корректирует его, если эта производительность меняется.
Таким образом, стори поинты быстрее, лучше и дешевле часов, и высокоэффективные команды повсеместно отказываются от оценок в часах как от лишней нагрузки, которая замедляет их и тянет вниз.
Jeff Sutherland, 2013
От редактора: обратите внимание на антипаттерн скрам-команд, связанный со стори поинтами и оценкой задач в целом.