Во время планирования спринта команда совместно определяет, сколько они смогут сделать в текущем цикле, чтобы создать программное обеспечение для поставки по его итогам. Но как именно команда это делает?
У каждой команды свой способ оценивать, какой объем работы она может сделать в спринте. Один из методов оценки пользовательских историй, подтвердивший на практике свою эффективность, – использование очков историй. Очки историй – это способ понять, сколько усилий вам потребуется, чтобы создать функцию для конкретной истории пользователя. Команда выставляет эти очки, сравнивая текущие пользовательские истории с затратами труда на реализованные ранее.
Нет никаких жестких правил, определяющих, сколько баллов (очков) следует присваивать той или иной истории. Некоторые команды назначают от 1 до 5 баллов за любую пользовательскую историю. Максимальное значение «пять» выбрано произвольно. Другие команды дают своим историям от 1 до 10 баллов или используют другие пределы, не меняющиеся от спринта к спринту. Некоторые команды используют числа из последовательности Фибоначчи либо значения экспоненциальной зависимости. Вы можете выбрать любую из работающих схем, при которой все в команде чувствуют себя комфортно. Одна история, оцененная в 3 очка, должна требовать столько же работы, сколько и другая история, оцененная так же. Когда ваша команда оценивает в очках все истории, над которыми она работает, ее члены начинают понимать, на сколько очков они могут выполнить (или «сжечь») историй в текущем спринте. Если ваша команда завершает за один спринт в среднем историй на 25 очков, то говорят, что ее скорость составляет 25 очков историй за спринт.
Команды, как правило, работают с примерно постоянной скоростью, если оценивать по нескольким спринтам. Поскольку до того, как команда начнет работать, трудно предсказать, какой будет скорость, вы можете использовать прошлый опыт, чтобы точнее спланировать следующие спринты.
Если вы сталкивались с инвестиционными фондами, то знаете, что прошлые показатели не гарантируют будущих доходов. То же самое применимо и к очкам историй. Даже если ваша команда «сожгла» 32 очка в прошлом спринте и 29 в позапрошлом, нет никакой уверенности, что в очередном спринте эти результаты удастся повторить. В каждом конкретном спринте люди могут неправильно истолковывать отдельные истории, сталкиваться с неожиданными техническими проблемами, кто-то уходит в отпуск, заболевает, увольняется и т. д. Но несмотря на это очки историй и скорость команды с течением времени становятся наиболее надежным ориентиром для большинства scrum-команд, и вы сможете воспользоваться им при планировании спринтов.
Сессия планирования спринта при помощи очков историй может проходить так.
1. Начните с самых ценных историй пользователей из бэклога продукта.
2. Возьмите историю из этого списка – лучше самую маленькую, это удобно для сравнения. Затем найдите историю такого же размера из предыдущего спринта и назначьте первой из них то же самое количество очков, какое было у второй.
3. Обсудите с командой, можно ли считать эту оценку точной: обнаружив дополнительные проблемы, работы или технические вопросы, повысьте оценку, и наоборот, выявив упрощающие факторы, такие как повторное использование существующего кода или уменьшение объема необходимой функциональности, – понизьте ее.
4. Продолжайте переходить от истории к истории, пока не наберете достаточное количество очков, чтобы заполнить спринт.
Не перегружайте бэклог текущего спринта. Полезно оставлять в нем запас и нежелательно увеличивать нагрузку сверх той, что имела место в прошлом. Если средняя скорость команды – 28 очков за спринт и на очередной спринт запланировано новых историй на сумму в 26 очков, то вы можете добавить только одну историю размером в 2 очка или две – в 1 очко. Так как разработчики – оптимисты по натуре (так и должно быть, поскольку мы созидатели), команда захочет добавить еще 3 очка, превысив свой план на один балл. Не поддавайтесь этому соблазну: нет более верного способа разочаровать пользователей при следующем обзоре спринта.
Но что делать, если вы впервые взялись за такое планирование? Вам потребуется время, чтобы наработать архив историй и сформировать у команды понимание того, насколько велика трехочковая история. Что ж, тогда для начала вам придется руководствоваться предположениями. Выберите одну историю, которая, по вашему мнению, находится примерно в середине шкалы трудоемкости, и произвольно назначьте ей 3 очка. Затем найдите самую большую историю и оцените ее в 5 очков. Теперь возьмите самую маленькую и назначьте ей 1 очко. Используйте их все в качестве отправной точки для оценки историй и наполнения своего спринта. К концу второго спринта вы будете иметь целый набор историй для сравнения, а также неплохую оценку средней скорости команды.
Как и сами пользовательские истории, очки историй не так просты, как кажутся. Командам легко начать применять их в работе (хотя есть множество нюансов их использования, которые мы здесь не будем рассматривать). Но почему они так эффективны?
Они просты
Новому члену команды легко объяснить, как их применять. Кроме того, их сумма за проект оказывается не очень большой. Это десятки или сотни, но никак не тысячи, что не забивает головы членам команды огромными числами.
У них нет волшебных свойств
Многие разработчики и менеджеры проектов видели немало неправильных оценок, не подтвердившихся впоследствии, и считают, что разработку программного обеспечения просто невозможно оценить более или менее точно. Присуждение очков историй исходя из реального опыта конкретной команды не делает тайны из того, откуда возникла та или иная оценка.
Команда контролирует их
Когда руководитель говорит вам, что вы должны соответствовать жестко заданным требованиям, это воспринимается как давление и увеличивает нагрузку на команду. Но когда команда самостоятельно принимает решение, как ей измерять свою работу и использовать для планирования только отобранные ею методы, такой подход становится для нее ценным инструментом.
Они побуждают вашу команду оценивать свою работу
Когда разработчик впервые попадает в scrum-команду, он, вероятно, впервые начинает открыто говорить об оценках, во всяком случае, его мнением интересуются. Выставление оценок – это навык, и единственный способ улучшить его – практика, которая в большинстве случаев предполагает обсуждение того, сколько сил понадобится на решение конкретных задач.
Разработчики их не боятся
Уже довольно много разработчиков имеют опыт выставления оценок в процессе работы. Затем эти оценки передаются руководителю проекта, после чего устанавливается жесткий дедлайн плана проекта. Подобное никогда не случится с очками историй, потому что они не превращаются в часы или конкретные сроки. Единственная зафиксированная величина – это дата окончания спринта, а запланированный объем работ может быть изменен во время ежедневного scrum-митинга в ходе цикла «обзор-контроль-адаптация».
Они помогают команде выяснить, в чем заключается смысл истории
Если вам кажется, что перед нами пятибалльная история, а я оцениваю ее в 2 балла, то мы, скорее всего, расходимся в понимании ее смысла. После обсуждения[42] может оказаться, что я полагал, будто для этой истории достаточно создания простого инструмента командной строки, а вы считали необходимым создание инструмента с графическим интерфейсом. Хорошо, что мы выяснили это во время планирования спринта. Иначе нас мог ждать неприятный сюрприз уже во время работы, когда двухбалльная история превратилась бы в пятибалльную!
Они помогают всем членам команды стать по-настоящему вовлеченными
Очки историй и скорость команды дают каждому участнику «точку опоры», от которой он может отталкиваться: например, команда считает, что раз в последнем спринте было «сожжено» 26 очков, то одна из его историй заслуживает более высокой, четырехбалльной оценки. Новички нередко склонны уклоняться от участия в подобном обсуждении, но позже выясняется, что в этом случае решения принимаются без них. Когда вы осознаете, что у вас была информация, которая могла бы помочь команде оценить историю в 3 балла, а не в 1 и тем самым избежать ошибки, вы наконец начнете заботиться о планировании спринта и станете по-настоящему вовлеченным в дело.
Диаграмма сгорания – это способ наглядно показать текущий прогресс спринта в сравнении с ранее достигнутой скоростью команды. Вот как можно построить этот нисходящий график на основе очков историй (этот способ также работает с другими единицами измерения, например часами, но мы будем использовать очки историй).
1. Начните с пустого графика. По оси Х отсчитываются даты, начиная с первого дня спринта и заканчивая последним его днем. По оси Y – очки историй с максимумом примерно на 0−20 % больше, чем общее количество очков в бэклоге спринта. Поставьте первую точку на графике: количество очков в спринте в день начала работы. Нарисуйте прямую («направляющую») линию от стартовой точки до конца периода – ноль очков должно остаться к моменту завершения спринта.
2. Как только первая пользовательская история завершена и перешла на доске задач в колонку «сделано», нарисуйте следующую точку на графике: количество баллов, оставшихся в спринте на текущий день. По мере завершения вами следующих историй и «сжигания» большего числа очков историй бэклога заполняйте последующие дни в этом нисходящем графике.
Рис. 5.4. Диаграмма сгорания в момент начала спринта. Мы создали этот нисходящий график, используя очки историй, но вы также можете использовать часы, дни или иные единицы измерения