Метрики: Velocity, Throughput и Cycle Time
Узнайте, почему Throughput и Cycle Time дают более точную картину, чем Velocity, помогая вашей Scrum-команде находить узкие места и точнее прогнозировать поставку.
Большинство инженерных организаций измеряют не то, что нужно, потому что story points кажутся научным подходом. Когда менеджеры смотрят только на цифры, команды начинают оптимизировать цифры, а не поставку работающего софта. Velocity, Throughput и Cycle Time остаются тремя самыми популярными метриками для отслеживания работы, но они измеряют принципиально разные вещи. И только две из них действительно помогают быстрее поставлять ценность.
Проблема с Velocity
Story points представляют собой относительные оценки, которые отдельная команда создает для планирования Спринта. В Scrum Guide вообще нет упоминаний story points или Velocity. Руководство лишь предлагает Разработчикам оценивать размер элементов, чтобы прогнозировать объем работы на Sprint. Когда руководство начинает воспринимать Velocity как показатель продуктивности, возникает инфляция оценок. Команда, закрывшая 20 очков в прошлом Спринте, в текущем оценит пятибалльную задачу уже в восемь очков. Работа быстрее не пошла, но график уверенно ползет вверх.
Velocity служит внутренним инструментом калибровки для конкретной команды, а не внешней мерой продуктивности. Эту метрику нельзя сравнивать между командами, ведь каждая вырабатывает собственную шкалу. Хуже того, чрезмерное внимание к Velocity подталкивает брать в работу слишком крупные пакеты задач ради красивых цифр, что увеличивает риски и откладывает получение обратной связи.
Почему Throughput работает лучше
Throughput показывает количество завершенных элементов работы за единицу времени, например, за неделю или за Sprint. Этой метрике не важны story points. Исправление ошибки считается за единицу, переписанный платежный модуль тоже считается за единицу. Учитываются только те элементы, которые полностью соответствуют Definition of Done.
Подсчет количества задач может показаться слишком грубым, пока вы не взглянете на математику. В разработке софта разброс в размерах задач влияет на результат гораздо меньше, чем длина очередей и задержки. Если команда делит пользовательские истории на небольшие, понятные фрагменты ценности, подсчет завершенных элементов дает прогнозы не хуже, а часто и точнее оценок на основе story points. Кроме того, это избавляет от бесконечных споров о том, стоит ли задача три очка или пять.
Cycle Time показывает, где застревает работа
Cycle Time отслеживает время с момента начала работы над элементом до достижения Definition of Done. Если разработчик начинает писать код в понедельник, а функциональность попадает в прод в четверг следующей недели, то Cycle Time составляет девять рабочих дней.
В отличие от Velocity, метрика Cycle Time прямо указывает на трения в процессе поставки. Большое значение Cycle Time редко связано с тем, что разработчики медленно печатают код. Причина кроется в ожидании: задачи простаивают в очереди на код-ревью, ждут тестирования или развертывания на стенде. Если вы хотите выпускать задачи быстрее, изучайте распределение Cycle Time, а не требуйте от людей работать усерднее.
Как выстроить правильную систему измерений
Вам не нужны громоздкие панели с метриками, чтобы понимать свой прогресс. Для здорового процесса поставки достаточно следить за тремя практическими показателями:
- Лимиты незавершенной работы (WIP limits), чтобы предотвращать заторы и удерживать Cycle Time на низком уровне.
- 85-й процентиль Cycle Time, чтобы давать стейкхолдерам реалистичные прогнозы по срокам.
- Throughput за Sprint, чтобы понимать реальную пропускную способность без игр с оценками в очках.
Scrum Guide напоминает нам, что цель каждого Спринта заключается в создании ценного, полезного Increment, отвечающего критериям Definition of Done. Velocity показывает, сколько работы вы рассчитывали выполнить по своим ощущениям. Throughput и Cycle Time показывают, что именно было сделано на самом деле и сколько времени на это потребовалось.