Velocity
Velocity (рус. скорость команды) — внутренняя метрика в методологии Scrum, показывающая объём работы, который команда фактически завершает за один спринт. Обычно она выражается в условных единицах оценки сложности задач — Story Points (стори-пойнты) и рассчитывается только по полностью завершённым пользовательским историям[4].[5]
Общие сведения
Определение
Velocity отражает реальную пропускную способность Scrum-команды и преследует две главные цели — прогнозирование объёма работы в будущих спринтах и оценку стабильности процесса разработки[6].
Ключевые характеристики Velocity:
- измеряет только завершённые Story Points; незавершённые задачи в расчёт не входят[7];
- рассчитывается по итогам каждого спринта, продолжительность которого в Scrum составляет от одной до четырёх недель (чаще всего — две недели)[8];
- используется командой для внутреннего планирования и не предназначена для сравнения разных команд[9];
- не является целью, которую необходимо постоянно увеличивать; попытки «накрутить» показатель приводят к снижению качества продукта[4].
История
Понятие Velocity не было частью оригинального фреймворка Scrum, а было заимствовано из методологии экстремального программирования (XP). Концепция зародилась в середине 1990-х годов в ходе работы над проектом Chrysler Comprehensive Compensation System (C3), который стартовал в марте 1996 года под руководством создателя XP Кента Бека[10]. Изначально для планирования мог использоваться «коэффициент загрузки» (англ. load factor), но со временем его заменил термин Velocity. К 1999 году он уже был задокументирован в книге Кента Бека «Extreme Programming Explained» и на официальном сайте методологии[11][12].
Основой для расчёта Velocity стала оценка задач в абстрактных единицах. Эту концепцию предложил Рон Джеффрис, один из соавторов XP. Чтобы избежать путаницы с оценкой в человеко-часах, он ввёл «очки» (англ. points), ныне известные как стори-пойнты[13]. Сумма «очков» по задачам, выполненным за одну итерацию, и составляла скорость команды[13].
Сообщество Scrum начало перенимать практику измерения Velocity из XP примерно в 2002 году. Однако широкую популярность и формализацию в контексте Scrum метрика получила после выхода книги Майка Кона «Гибкая оценка и планирование проектов» (англ. Agile Estimating and Planning) в 2005 году[14]. Книга предоставила командам структурированный подход к прогнозированию на основе исторических данных, что способствовало превращению Velocity в распространённую, хотя и необязательную, практику в Scrum[15].
Структурные элементы термина Velocity
- Завершённые Story Points — сумма оценочных единиц всех историй, удовлетворяющих «определению готовности»[16].
- Спринт — фиксированный промежуток времени (1–4 недели), в пределах которого производится расчёт Velocity[8].
- Последовательная методика оценки — единая для команды система измерения (Story Points, идеальные часы и т. д.), необходимая для корректного сравнения спринтов[17].
- Исторические данные — накопленные значения Velocity за последние 3–5 спринтов, на основании которых вычисляется средняя скорость и строятся прогнозы[8].
Определение единиц и оценка задач
Команда выбирает шкалу (чаще всего Story Points) и оценивает элементы бэклога до начала спринта[5].
Подсчёт Velocity за спринт
По окончании спринта подсчитывается сумма Story Points всех полностью завершённых историй — это фактическая Velocity текущего спринта[18].
Расчёт средней Velocity
После 3–5 спринтов команда определяет среднее значение, которое служит ориентиром для дальнейшего планирования[16].
Использование для планирования
Средняя Velocity позволяет Владельцу продукта прогнозировать объём работы, который можно включить в следующий спринт, а также оценивать сроки релиза[19].
Анализ и улучшение процессов
Резкие колебания Velocity рассматриваются на ретроспективах; команда выявляет причины (перегрузка, технический долг, неясные требования) и внедряет улучшения[16].
Преимущества
Недостатки
- Не является метрикой производительности. Velocity часто ошибочно используется для оценки производительности или для сравнения разных команд. Это некорректно, так как Story Points субъективны и уникальны для каждой команды, а сама метрика не учитывает сложность и качество работы.
- Стимулирует «гонку за числом». Применение Velocity в качестве KPI побуждает команды искусственно завышать оценки задач (англ. story point inflation), чтобы продемонстрировать рост показателя[21]. Это искажает данные для планирования и приводит к снижению качества.
- Не отражает бизнес-ценность. Метрика измеряет объём выполненной работы (англ. output), но ничего не говорит о её ценности для бизнеса или пользователя (англ. outcome)[22][23]. Команда может иметь высокую скорость, но при этом накапливать технический долг или создавать функции, не востребованные рынком.
- Создаёт иллюзию точности. Опора на среднее значение Velocity создаёт ложное ощущение предсказуемости, игнорируя естественные колебания, вызванные отпусками, болезнями, срочными исправлениями ошибок или непредвиденными техническими сложностями[24].
- Теряет актуальность при нестабильности. Метрика ненадёжна, если состав команды часто меняется, так как исторические данные для прогнозирования становятся нерелевантными.
Сферы применения
- прогнозирование и планирование спринтов внутри Scrum-команд[25];
- расчёт сроков релизов и приоритизация бэклога продукта;
- оценка стабильности и зрелости процессов разработки;
- выявление узких мест и точек для улучшения на ретроспективах[26];
- коммуникация с бизнес-стейкхолдерами при планировании дорожных карт.
Актуальность и альтернативы
В профессиональном сообществе актуальность метрики Velocity является предметом дискуссий. Несмотря на то, что она по-прежнему используется многими командами для внутреннего планирования и прогнозирования нагрузки[27][28], её роль снижается под давлением критики и появления более современных подходов.
Ключевая критика связана с тем, что Velocity часто неверно применяют как показатель производительности, что провоцирует команды искусственно завышать оценки задач. Кроме того, метрика измеряет объём выполненной работы (англ. output), но не её ценность для бизнеса (англ. outcome) или качество. Это привело к смещению фокуса на альтернативные метрики.
В качестве замены Velocity набирают популярность следующие подходы:
- Метрики потока (англ. Flow Metrics), заимствованные из Kanban. Они фокусируются на эффективности процесса, а не на объёме. Ключевыми метриками являются:
- Время цикла (англ. Cycle Time) — время от начала работы над задачей до её завершения.
- Пропускная способность (англ. Throughput) — количество задач, выполненных за определённый период.
- Незавершённая работа (англ. Work in Progress, WIP) — количество задач, находящихся в работе одновременно. Ограничение WIP помогает улучшить поток.
Эти показатели считаются более надёжными, так как ими сложнее манипулировать.
- Вероятностное прогнозирование. Вместо опоры на среднее значение Velocity, этот подход использует статистические методы, например, симуляции Монте-Карло. На основе исторических данных о времени выполнения задач он позволяет давать прогнозы в виде диапазона дат с указанием вероятности (например, «проект будет завершён с 1 по 15 декабря с вероятностью 85 %»). Такой подход даёт более реалистичную картину, учитывающую естественные колебания в работе.
- Фокус на бизнес-результатах (англ. Outcomes). Тренд на измерение реального влияния на бизнес и пользователей вместо отслеживания «занятости» команды. Для этого используются такие метрики, как индекс использования продукта клиентами (англ. Customer Usage Index), коэффициент обращений к новой функции (англ. Hit Ratio) и показатели удовлетворённости клиентов (NPS, CSAT).
Таким образом, хотя Velocity остаётся инструментом для внутреннего планирования, в современной гибкой разработке наблюдается устойчивый тренд на переход к метрикам потока и показателям, ориентированным на создание ценности для конечного пользователя.
Инструменты для использования в Velocity
Для отслеживания Velocity команды используется ряд инструментов, которые помогают визуализировать прогресс и прогнозировать производительность:
- Jira — предоставляет встроенные диаграммы Velocity (англ. Velocity Chart) и другие Agile-отчёты.
- Asana — гибкий инструмент, в котором скорость можно отслеживать с помощью пользовательских полей и панелей мониторинга[29].
- ClickUp — универсальная платформа с виджетом «Velocity Chart» для дашбордов[30].
- Zoho Projects — часть экосистемы Zoho, предоставляющая отчёты по скорости команды[31].
- Azure DevOps — включает гаджеты Velocity и диаграммы на досках спринта.
- Trello — позволяет рассчитывать скорость с помощью сторонних плагинов или вручную.
- Yandex Tracker — поддерживает Agile-доски, спринты и диаграммы скорости.
- SimpleOne — российская ESM-платформа, включающая инструментарий для управления проектами по Scrum и отчёты по Velocity[32].
- BigPicture — расширение для Jira с расширенной аналитикой Velocity.
- Визуализация показателя также возможна в самостоятельных таблицах (например, Microsoft Excel, Google Таблицы) или BI-панелях, если команда предпочитает хранить данные локально.