← Назад к вопросам

Как работает метрика Velocity?

2.3 Middle🔥 202 комментариев
#Метрики и мониторинг

Комментарии (2)

🐱
deepseek-v3.2PrepBro AI6 апр. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Метрика Velocity: как работает, зачем нужна и как использовать

Velocity (Скорость) — это ключевая метрика в гибких методологиях разработки (Agile, Scrum, Kanban), которая измеряет объём работы, выполненной командой за один спринт. Её основная цель — не оценка производительности отдельных сотрудников, а прогнозирование скорости работы команды для улучшения планирования будущих спринтов.

Как рассчитывается Velocity?

Velocity рассчитывается как сумма оценочных единиц (story points, идеальные человеко-часы) по всем завершённым пользовательским историям (User Stories), принятым в конце спринта по критериям готовности (Definition of Done).

# Пример расчёта Velocity в условных story points
story_points_в_спринте = [3, 5, 8, 13, 1]  # Оценки завершённых историй
velocity = sum(story_points_в_спринте)  # Суммируем все оценки
print(f"Velocity текущего спринта: {velocity} story points")
# Вывод: Velocity текущего спринта: 30 story points

Важные правила расчёта:

  • Учитываются только истории, полностью соответствующие Definition of Done.
  • Незавершённые или частично выполненные задачи не включаются в расчёт.
  • Технический долг и баг-фиксы обычно оцениваются отдельно.

Как используется Velocity на практике?

Основное применение — прогнозирование и долгосрочное планирование:

  1. Прогноз завершения бэклога продукта (Product Backlog):

    // Пример прогноза в JavaScript
    const totalStoryPointsInBacklog = 300;
    const averageTeamVelocity = 40; // Средняя скорость за последние 3 спринта
    const numberOfSprintsNeeded = totalStoryPointsInBacklog / averageTeamVelocity;
    
    console.log(`При скорости ${averageTeamVelocity} SP/спринт`);
    console.log(`На выполнение бэклога потребуется ~${Math.ceil(numberOfSprintsNeeded)} спринтов`);
    // Вывод: На выполнение бэклога потребуется ~8 спринтов
    
  2. Определение реалистичного объёма работ на следующий спринт: Команда использует исторические данные о своей скорости, чтобы не перегружать спринт.

Ключевые принципы работы с метрикой

  • Velocity — относительный, а не абсолютный показатель. 30 story points у одной команды ≠ 30 story points у другой. Сравнивать скорости разных команд бессмысленно.
  • Фокус на тренде, а не на единичном значении. Важна средняя скорость за 3-5 спринтов.
    # Пример анализа тренда через условные данные
    Спринт 1: Velocity = 28
    Спринт 2: Velocity = 32
    Спринт 3: Velocity = 30
    Спринт 4: Velocity = 29
    # Средняя Velocity (за 3 последних спринта) ~30.3
    # Тренд стабилен, можно планировать следующий спринт в диапазоне 28-32 SP
    
  • Это инструмент для команды, а не для микроуправления. Роль Project Manager/Scrum Master — объяснять её назначение стейкхолдерам, предотвращая использование Velocity как KPI для давления на команду.

Ограничения и риски

  • Неточное прогнозирование в начале проекта. Пока команда не стабилизировалась, Velocity сильно колеблется.
  • Искушение "накрутить" метрику. Если начальство требует постоянного роста Velocity, команда может начать завышать оценки story points.
  • Не учитывает качество и сложность. Высокая Velocity не гарантирует, что команда делает именно то, что нужно бизнесу.

Best Practices от эксперта

  • Используйте совместно с другими метриками: Burn-down chart (диаграмма сгорания работ), Cumulative Flow Diagram (диаграмма накопленного потока) для комплексной картины.
  • Проводите ретроспективы при аномалиях. Если Velocity упала на 30% — не ищите виноватых, а анализируйте причины вместе с командой (технические долги, непредвиденные сложности, внешние помехи).
  • Регулярно калибруйте оценки. На ретроспективах планирования пересматривайте, насколько прошлые оценки соответствовали реальным трудозатратам.

Итог: Velocity — это мощный инструмент эмпирического планирования, который работает только в условиях доверия и прозрачности. Его правильное применение помогает команде найти устойчивый ритм работы, а менеджеру — реалистично управлять ожиданиями заказчика относительно сроков и объёмов релизов.