Традиционно для проектов создается большой список детальных требований. В случае работы по принципам Agile объем предварительного планирования меньше. Это позволяет быстрее создавать ценные продукты для пользователей.
Но компании, которые только начинают внедрять Agile, беспокоятся: насколько работа команды будет предсказуемой? Ведь полностью от планирования, по времени и по бюджету, отказаться нельзя.
Есть метрика Velocity. Она измеряет прогресс команды. Разберемся, как измерить эту скорость и как использовать показатель для планирования релизов. Также покажем, что можно прогнозировать с данной метрикой.
Что такое Velocity?
Вместо Velocity можно использовать термин «скорость» или «мощность» команды. Она показывает, какой объем работы выполняет команда за определенный период времени. Этот показатель может измеряться в человеко-часах, количестве задач, очках истории или любой другой единице измерения работы.
Например, в Kanban команды разбирают постоянный поток входящих задач, которые примерно одинакового размера. В этом случае Velocity можно измерить по количеству задач, отмеченных как сделанные за один день. Усредняя ежедневный показатель в течение недели, уже можно оценить, сколько команда сделает за более длительный период.
В этой статье мы будем опираться на свою практику работы со scrum-командами, поэтому рассмотрим скорость команды в этом фреймворке.
Можно уточнить определение скорости команды в Scrum — это количество очков историй, выполненных за спринт.
Как считать
Всю технологию рассмотрим на примере.
У нас есть гипотетическая продуктовая команда. Назовем ее ABC. На спринт она взяла несколько историй, общей сложностью 51 SP. В конце спринта выполнила 7 задач суммарно в 34 SP, оставшиеся истории перенесутся в следующий спринт.
Значит, скорость ABC на этот спринт 34 SP. Но по одному спринту судить рано, так как:
- неизвестно, насколько завершены оставшиеся истории на 17 очков;
- неизвестно, сколько дополнительной работы сделала команда или в какие необычные обстоятельства попала.
Пока мы знаем, что задач было больше, чем разработчики смогли сделать.
Для среднего значения потребуется статистика нескольких спринтов. Это также связано с психологическими особенностями работы: в начале пути новая команда работает неравномерно. Сначала она более замотивирована, потом идет период притирки между коллегами. По истечении этих этапов, возможно, скорость работы за спринт выровняется.
Команда АВС в первом спринте сожгла 34 SP, во втором — 40 SP и 39 SP — в третьем. Средняя скорость за три спринта составляет 37,6 SP.
Чем больше больше статистики собрано, тем точнее отрегулируется цифра. Ее можно использовать для прогнозирования: сколько оцененных историй возьмет команда, и можно предположить, какие функции попадут в релиз. Иногда про будущий релиз важно сообщить заранее: например, когда маркетологи должны подготовить промоматериалы или провести рекламные кампании под обновления.
Мы говорим «предположить», но не «определить точно». Метрика имеет допущения, потому что не содержит всю информацию о деятельности команды за спринт. Полноценно работать с Velocity могут владельцы продукта или scrum-мастера, поскольку знают другие детали.
Метрика лучше работает с командами, собранными надолго: есть время, чтобы оценить их среднюю скорость, и статистика понадобится для прогнозирования работы на будущее. Если практикуется частая смена состава, метрика будет не столь значима.
Что еще нужно знать о Velocity:
- Это не самоцель, главное в Agile — поставляемая ценность. Есть даже движение #NoEstimates, которое выступает против всяких оценок.
- Скорость одной команды соотносится с другой, только если их система оценок тоже одинакова. А так, 40 SP у одной и у другой группы может означать совсем разный темп работы.
- Хорошо, если scrum-мастер оформляет график скорости по спринтам. Например, так:
График можно детализировать:
— добавлять, что хотели сделать и что сделали по факту;
— отражать дополнительные задачи, баги и прочее.
Вот пример диаграммы со множеством деталей:
Максимальная скорость = максимальная производительность?
Точно нет. Если команда стремится достичь высокой скорости, может прийти к низкой производительности и пожертвовать качеством выпускаемого продукта. В попытке увеличить показатель, команда будет отказываться от тестирования, сбора обратной связи и других практик, которые являются ключевыми в гибком подходе. Краткосрочное улучшение ведет к долгосрочному негативному эффекту.
Цель не в высокой скорости, а в оптимальной.