Метрики прогресса проекта

Назначение: визуализация и прогноз хода проекта; основа для решения «в срок или нет».

Аудитория: PM, Scrum Master, PO, команда.

Статус: устоявшийся (Agile/Scrum-практики).

Не путать с: метриками здоровья команды (happiness, turnover — про состояние людей, а не про ход работ), Earned Value Management (финансовые метрики освоения бюджета, статья готовится) и DORA-метриками (deployment frequency, lead time for changes — инженерные метрики процесса поставки из development-managment).

Общее #

Метрики прогресса — инструменты измерения хода проекта: сколько работы сделано, сколько осталось и с какой скоростью движется команда. Их задача — заменить ощущение «кажется, мы успеваем» проверяемыми данными, на которых строятся прогноз сроков, ранние сигналы проблем и коммуникация со стейкхолдерами.

Ответ на вопрос «идём ли мы по графику» в классическом проектном управлении даёт диаграмма Ганта: полосы работ сравниваются с календарём. В итеративной разработке, где состав работ меняется каждые пару недель, статичное расписание перестаёт работать — и его место занимают метрики, пересчитываемые с каждым спринтом или потоком задач: Velocity, Burn-down, Burn-up, CFD, Lead/Cycle Time.

Lagging против leading #

По временной направленности метрики делятся на два класса:

• Lagging (запаздывающие) — измеряют то, что уже произошло: сколько story points закрыто в прошлом спринте, каков был cycle time завершённых задач. Они точны, но смотрят в прошлое.
• Leading (опережающие) — предсказывают будущее: текущий остаток работы относительно скорости команды, ширина полосы WIP на CFD (растущая очередь завтра обернётся ростом cycle time), тренд velocity. Они менее точны, но именно они позволяют вмешаться до того, как проблема случилась.

Зрелая система метрик комбинирует оба класса: lagging поставляет фактуру для прогноза, leading — ранние сигналы.

Throughput против effort-based #

По единице измерения метрики прогресса делятся на два семейства:

• Effort-based (на основе оценки сложности) — Velocity, Burn-down/Burn-up в story points. Требуют предварительной оценки задач (story points), дают сопоставимый с планом масштаб «сколько осталось от задуманного».
• Throughput-based (на основе счёта задач) — CFD, Lead Time, Cycle Time в штуках задач. Оценки не требуют вовсе; жертвуют сопоставимостью «сложной» и «простой» задачи ради отсутствия оценочного шума. Канон Kanban.

Выбор семейства следует методологии: Scrum с его оценкой бэклога естественно порождает velocity, Kanban с потоком — throughput и время цикла.

Зачем нужны метрики прогресса #

Три базовые функции, ради которых метрики ведут:

1. Прогноз. «При текущей скорости 40 sp за спринт остаток в 200 sp закроется за пять спринтов» — прогноз, который можно проверить. Без метрик срок назначается переговорами.
2. Ранние сигналы. Расширяющаяся полоса на CFD, три спринта падающей velocity, рост cycle time — симптомы, видные за недели до срыва срока.
3. Коммуникация со стейкхолдерами. Burn-up диаграмма отвечает на вопрос заказчика «когда будет готово» честнее, чем словесные заверения, — и одновременно показывает, почему «когда» зависит от того, сколько требований добавили.

Граница с соседними наборами метрик важна: эта статья — про ход работ. Метрики здоровья команды (happiness index, turnover, eNPS) разобраны в командных метриках; инженерные метрики процесса поставки (DORA) — за пределами проектного управления; финансовые метрики освоения бюджета — в Earned Value Management.

Сводная таблица #

Velocity #

Velocity (скорость команды) — сумма оценок всех элементов, полностью завершённых командой за спринт. Измеряется в story points (реже — в количестве задач или идеальных человеко-днях). Если за спринт команда довела до Definition of Done истории на 34, 8 и 13 story points, velocity спринта — 55.

Ключевое слово — «полностью завершённых». Незакрытая к концу спринта история не даёт частичного вклада: задача на 8 sp, выполненная на 90%, в velocity идёт как ноль (и целиком возвращается в бэклог следующего спринта). Это правило защищает метрику от иллюзии прогресса: «почти готово» — не готово.

Как считать #

Velocity конкретного спринта — арифметика; рабочая величина — окно из нескольких спринтов:

1. По итогам спринта суммируются оценки всех историй, прошедших DoD.
2. Для прогноза берётся среднее или медиана за последние 3–5 спринтов — «установившаяся» velocity.
3. Новым командам нужно 3–5 спринтов на стабилизацию: первые значения использовать для прогноза нельзя.

Важно понимать, что измеряет velocity. Это количество scope, которое команда реально проносит через спринт при текущем составе, контексте и качестве, — откалиброванная на опыт поправка к оценкам планирования. Если команда стабильно берёт 40, а на планировании очередной спринт набрали на 60 — это не «амбициозный план», а план на два спринта вперёд, растянутый на один.

Использование для прогноза #

Базовый сценарий — Sprint Planning в Scrum: команда выбирает в спринт объём, близкий к установившейся velocity, а не к желаемому. Прогноз релиза строится так же: остаток бэклога в story points делится на velocity — получается число спринтов до релиза с точностью ±один спринт (позже это число уточняется каждым новым спринтом).

Корректный прогноз всегда включает диапазон: при velocity от 35 до 50 остаток в 300 sp — это 6–9 спринтов. Команда, рапортующая одну цифру без диапазона, создаёт ложную точность (подробнее — в разделе об антипаттернах).

Типичные ошибки #

• Сравнение velocity между командами. Story points калибруются командой по своим задачам: «8» у одной команды и «8» у другой — несопоставимые величины. Команда, делающая 60, не «быстрее» команды, делающей 30: у них просто разные шкалы и разный размер историй. Velocity — внутренняя метрика команды, для внешних сравнений она непригодна.
• Требование «увеличить velocity». Velocity — измерение, а не цель. Рост сам по себе не означает производительности: он одинаково возникает от устранения блокеров и от надувания оценок. Когда от команды требуют роста, растут оценки — при той же реальной скорости.
• Gaming. Дробление историй на мелкие с завышенной суммой оценок, «заливание» баллов за счёт качества (пропуск тестов), переоценка незакрытых задач вверх — метрика растёт, продукт нет. Закон Гудхарта в действии (разобран в конце статьи).
• Реактивное управление по одному спринту. Velocity шумит по естественным причинам (отпуска, инциденты, сложные истории). Реагировать на падение в одном спринте — всё равно что перестраивать процесс по одному броску кубика; тренд из 3–4 спринтов — минимум для выводов.

Sprint Burn-down Chart #

Sprint Burn-down Chart (диаграмма сгорания спринта) — график остатка работы спринта: по горизонтальной оси — время (дни спринта), по вертикальной — оставшийся объём в story points. Обновляется ежедневно после стендапа.

 осталось
 работы, sp
 40 ┤●
    │ ╲
 35 ┤  ╲●                    ● — фактическая линия
    │   ╲
 30 ┤    ╲●                  ┄ — идеальная линия
    │     ╲ ╲
 25 ┤      ╲  ●
    │       ╲   ╲
 20 ┤        ╲    ●          факт выше идеала —
    │         ╲     ╲          команда отстаёт
 15 ┤          ╲      ●
    │           ╲       ╲
 10 ┤            ╲        ●      ┄┄┄
    │             ╲          ┄┄┄┄┄
  5 ┤              ╲     ┄┄┄●
    │               ┄┄┄┄┄┄
  0 ┼──────────●┄┄┄┄──────────────→
    0    2    4    6    8    10
                 дни спринта

Две линии на графике:

• Идеальная — прямая от полного объёма спринта до нуля: равномерное сгорание по 1/N работы в день. Это эталон, а не план с обязательствами.
• Фактическая — остаток по дням. Ключ в её наклоне относительно идеала, а не в конкретных значениях.

Как читать #

• Ahead (опережение): фактическая линия ниже идеала — работа сгорает быстрее эталона. Не всегда хорошо: возможен знак переоценённых задач.
• On track (в графике): линия колеблется вдоль идеала — нормальный ход спринта.
• Behind (отставание): линия выше идеала и не сходится — спринт под угрозой; тема для стендапа: что мешает и что убрать из спринта, чтобы закрыть цель.

Горизонтальная «полка» (линия не снижается несколько дней) — отдельный сигнал: работа идёт, но не закрывается — типичный признак задач в состоянии «почти готово», раздутого WIP внутри спринта или неготового критерия приёмки.

Сценарии #

• Late discovery (позднее обнаружение). В середине спринта выясняется, что «простая» история тянет за собой интеграцию на неделю. На burn-down это видно как внезапный выгиб линии вверх после дня плато — сигнал переоценки остальных задач спринта: остаток пересматривается сразу, а не «ещё деньок подумаем».
• Scope change mid-sprint (изменение состава). PO вносит срочную историю в спринт, выводя эквивалент по оценкам. На корректном графике это отражается ступенькой вверх с пометкой; «тихое» добавление без выведения ломает главную функцию диаграммы — честный остаток. В Scrum состав спринта защищён Sprint Goal именно поэтому.
• Стартовый лаг. Первые 2–3 дня линия почти не снижается: задачи ещё не доходят до Done. Для коротких спринтов это нормально; лечить «разгон» следует декомпозицией, а не паникой на стендапе третьего дня.

Release Burn-down и Burn-up #

Sprint burn-down отвечает про остаток внутри спринта. Для горизонта релиза — «когда увидим весь продукт» — нужны диаграммы другого масштаба, и здесь выбор между burn-down и burn-up принципиален.

Release Burn-down #

Считается так же, как спринтовый: по оси X — спринты, по оси Y — остаток всего релизного бэклога в story points. После каждого спринта из остатка вычитается velocity, и линия должна дойти до нуля к релизу.

Проблема release burn-down в том, что он показывает остаток, но скрывает изменение знаменателя: если в релиз добавили 100 sp новых требований, а команда закрыла 40, то «остаток» вырос на 60 — и по одной линии непонятно, команда замедлилась или scope расползся. Диаграмма отвечает «сколько осталось», но не «почему».

Burn-up со scope line #

Release Burn-up рисует две линии: снизу — накопленный сделанный объём, сверху — весь объём релиза (scope line). Расстояние между линиями в любой точке — остаток работы.

 объём
 работ, sp
 120 ┤                        ●━━━━━ scope = 120
     │                ●━━━━━╱        (+20 sp: согласовали
 100 ┤        ●━━━━━╱                новые требования)
     │  ●━━━━╱    ╱┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄●  сделано = 70
  80 ┤  ╱        ╱
     │ ╱        ╱       ← расстояние между линиями —
  60 ┤╱        ╱           остаток работ (≈50 sp)
     │        ╱
  40 ┤      ╱
     │    ╱
  20 ┤  ╱
     │╱
   0 ┼──────────────────────────────→
     старт    спринт 1    спринт 2    спринт 3

Чтение диаграммы:

• Нижняя линия (сделано) — сумма закрытых story points к концу каждого спринта; её наклон — фактическая velocity.
• Верхняя линия (scope) — суммарная оценка всего согласованного объёма релиза. Растёт ступеньками при добавлении требований, опускается при выведении.
• Зазор — сколько осталось; сходится к нулю — релиз приближается, расходится — нет.

Почему burn-up предпочтительнее для релиза #

Главный аргумент: burn-up делает расползание scope видимым. На burn-up добавление требований — ступенька вверх верхней линии, отрывающая зазор; на burn-down то же самое выглядит как «остаток не уменьшается», и виновником выглядит команда. Burn-up разделяет ответственность честно: скорость работы команды (наклон нижней линии) и изменение объёма решением PO/стейкхолдеров (движение верхней) — два независимых, наглядно разделённых фактора.

Для релизного планирования это даёт разговор со стейкхолдерами в терминах управления объёмом: «при текущей скорости входа требований проект не завершится никогда — либо фиксируем scope, либо режем» — и связку с roadmap, где окна релизов согласовываются с объёмом.

Дополнительный аргумент — устойчивость к шуму: burn-up накапливает сделанное (монотонно растущая величина стабилизирует глаз), тогда как burn-down ежедневно дёргает остаток.

Расползание объёма релиза — симптом Scope Creep (статья готовится): неуправляемого добавления требований без пересмотра сроков и ресурсов. Burn-up — инструмент, который делает этот процесс управляемым: каждое движение scope line — осознанное решение с видимыми последствиями для даты релиза.

Cumulative Flow Diagram (CFD) #

Cumulative Flow Diagram (кумулятивная диаграмма потока) — каноническая метрика Kanban. По оси X — время, по оси Y — кумулятивное (накопленное с начала) число задач в каждой стадии процесса. Каждая стадия рисуется своей полосой; полосы наложены друг на друга от нуля:

 кумулятивное
 число задач
 200 ┤░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░  ░░ Backlog
     │░░░░░░░░░░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
 150 ┤░░░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒████████████  ▒▒ In Progress
     │░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒████████████████████  ██ Done
 100 ┤▒▒▒▒▒▒▒▒▒████████████████████████████
     │▒▒▒▒████████████████████████████████
  50 ┤████████████████████████████████████
     │████████████████████████████████████
   0 ┼─────┬─────┬─────┬─────┬─────┬─────→
        нед1  нед2  нед3  нед4  нед5  нед6

Верхняя граница самой верхней полосы — сумма всех когда-либо поступивших задач; нижняя граница полосы Done — накопленное число завершённых. Каждая полоса между границами — задачи, находящиеся в данной стадии на данный момент.

Что показывает CFD #

• Наклон нижней границы Done — throughput: скорость, с которой система выдаёт завершённые задачи. Чем круче граница уходит вверх, тем быстрее поток.
• Ширина полосы In Progress — WIP: число задач, находящихся в работе прямо сейчас. По закону Литтла (WIP ≈ throughput × среднее время в системе) ширина полосы при известном throughput напрямую определяет cycle time: расширение полосы — это будущий рост времени цикла, даже если ничего пока не задержалось.
• Расширение полосы (расходящиеся границы) — сигнал узкого места: задачи входят в стадию быстрее, чем выходят из неё. Полоса, расползающаяся в середине диаграммы, указывает на bottleneck ровно в этой стадии — за недели до того, как задержки станут видны заказчику.
• Сужение полосы — разгрузка: очередь рассасывается (типично после введения WIP-лимита на входную колонку).
• Ступенька верхней границы Backlog — рост входящего потока: согласован новый объём; если вход постоянно круче выхода — это scope creep в терминах потока: система не успеет переварить то, что в неё закладывают.

Практика чтения #

Диагностика по CFD сводится к трём вопросам: наклонены ли границы равномерно (стабильный поток), какая полоса расширяется (где bottleneck), и что делает верхняя граница (управляем ли вход). Ответы дают план действий: выровнять вход, установить/опустить WIP-лимит на расширяющейся стадии, разбировать скопление. Серьёзный анализ CFD стоит вести на «сглаженном» окне в несколько недель — ежедневные флюктуации полос шумят.

Earned Value: SPI #

Для полноты картины о метриках прогресса нужна связка с классическим лагерем. Earned Value Management (EVM, управление освоенным объёмом) — методика интеграции scope, сроков и стоимости; детально она разбирается в статье Earned Value Management (статья готовится). Здесь важна одна проектная метрика:

SPI (Schedule Performance Index) — индекс выполнения календарного плана:

SPI = EV / PV

EV (Earned Value)  — освоенный объём: бюджет завершённых работ
PV (Planned Value) — плановый объём: бюджет работ, запланированных на эту дату

Интерпретация: SPI = 0,8 — проект выполняет 80% запланированного на дату; SPI > 1 — опережение расписания, SPI < 1 — отставание. В паре с CPI (Cost Performance Index, EV/AC) методика даёт прогноз даты и стоимости завершения проекта.

Принципиальное отличие от Agile-метрик: EVM измеряет прогресс в деньгах (освоенный бюджет как прокси сделанной работы), требует базового плана по объёму (baseline) и работает на горизонте всего проекта с формальным контролем изменений. Agile-метрики измеряют прогресс в story points или задачах, пересчитываются каждый спринт и толерантны к изменению объёма. Отсюда типовые ниши: EVM — крупные контракты с фиксированным бюджетом и отчётностью заказчику; velocity/burn-up — продуктовая итеративная разработка. Гибрид возможен: earned value считают и по спринтам, если каждую завершённую историю оценивать в деньгах.

Lead Time и Cycle Time #

Самая частая путаница в метриках потока — пара Lead Time / Cycle Time. Разница — в точке отсчёта:

   момент        задача             задача
   запроса       взята в работу    завершена
     │               │                 │
     ├───────────────┼─────────────────┤
     │   ожидание    │     работа      │
     │   в очереди   │                 │
     │               │                 │
     │←──────── Lead Time ────────────→│
                     │←─ Cycle Time ──→│

• Lead Time — от момента, когда запрос поступил (клиент попросил, стейкхолдер завёл задачу), до момента поставки. Это время, которое испытывает заказчик; включает всё ожидание в очередях.
• Cycle Time — от момента, когда команда начала работу, до завершения. Это время, которое переживает команда; очередь в backlog в него не входит.

Разрыв между ними — время ожидания до старта: если lead = 20 дней, а cycle = 4, то 16 дней задача ждала в очереди (приоритизация, занятость команды, WIP-лимиты) — и это главный резерв улучшения. Путают метрики чаще всего потому, что обе измеряются в днях и обе «про одну и ту же задачу».

Control Chart #

Control Chart (контрольная карта) — график cycle time каждой завершённой задачи по оси X (в порядке завершения), с горизонталями среднего и контрольных границ (±2–3 сигмы). Читается так:

• точки внутри границ — нормальная вариация процесса; реагировать на каждую — вредно;
• точка за границами — особая причина (выброс): конкретная задача с аномалией, которую разбирают отдельно;
• устойчивый сдвиг среднего (8+ точек подряд по одну сторону) — процесс изменился системно.

Карта дисциплинирует различием «шум/сигнал»: не каждая долгая задача — проблема процесса, но систематический рост среднего — да.

Service Level Expectation (SLE) #

SLE (Service Level Expectation) — способ отвечать на вопрос «когда будет готово» в Kanban без оценок. Вместо обещания конкретной даты команда формулирует прогноз по процентилям распределения cycle time:

 доля задач,
 завершённых
 за ≤ N дней                85% ─ ─ ─ ─ ─ ─ ─ ─┐
 100 ┤                              ● SLE: «85% задач
     │                        ╱╱╱    за 8 дней или быстрее»
  50 ┤─ ─ ─ ─ ─ ─ ─ ─ ●╱╱╱╱
     │            ╱╱╱╱         медиана: 4 дня
   0 ┼────────┬────┬────┬────┬────┬──→
            2    4    8    14       cycle time, дни
                 ↑    ↑    ↑
                50-й 85-й 95-й перцентили

Формула ответа заказчику: «85% подобных задач мы закрываем за 8 дней или быстрее». Выбор процентиля — торговля риском: 50-й чаще нарушается, 95-й почти гарантирован, но выглядит медленным. SLE честнее точечной оценки: он опирается на историю, а не на оптимизм, и явно называет вероятность.

Антипаттерны и распространённые ошибки #

Закон Гудхарта #

Формулировка (в версии Мэрилин Стратерн): «показатель, ставший целью, перестаёт быть хорошим показателем». Как только velocity начинают использовать для оценки производительности («у соседей 60, а у вас 30»), команда оптимизирует не работу, а метрику: оценки надуваются, истории дробятся, качество приносится в жертву закрытию спринта. Цифра растёт; информативность падает до нуля. Метрики прогресса работают только в роли термометра; попытка «греть термометр» уничтожает и термометр, и управление.

Лечится дисциплиной использования: velocity публикуется команде для планирования, а не руководству для рейтинга; любые KPI на основе velocity между командами — конструктивная ошибка.

Сводная таблица ошибок #

Ошибки интерпретации, не связанные с gaming #

• Velocity ≠ производительность. Рост velocity может означать рост скорости, деградацию качества (мельче DoD) или инфляцию оценок — метрика не различает эти причины. Различает их связка с метриками качества и здоровья команды.
• Плоская линия — не всегда плохо. Стабильная velocity — признак предсказуемости, а не застоя; предсказуемость и есть то, ради чего метрика существует.
• Burn-down на календарных процентах. График «прошло 60% времени» рядом с «сгорело 40% работы» бессмыслен без объёма; сравнивать можно только работу с работой (против идеальной линии), а не время с работой.

Связанные материалы #

• Scrum — фреймворк, в котором velocity и burn-down являются штатными метриками спринта.
• Kanban — метод потока; CFD, Lead/Cycle Time и SLE — его канонические метрики.
• Story Points — единица измерения, в которой считаются velocity и burn-up.
• WIP-лимит — инструмент, удерживающий полосу In Progress на CFD от расширения.
• Диаграмма Ганта — классическая визуализация хода работ, к которой метрики прогресса добавляют пересчёт при изменении scope.
• Roadmap — план-график поставок, в окнах которого живёт release burn-up.
• Метрики команды — соседний набор: здоровье и производительность людей, а не ход работ.
• Scope Creep, Earned Value Management — статьи готовятся.

Заключение #

Пять тезисов статьи:

• Velocity — внутренняя метрика команды: калиброванная по её шкале оценок скорость прохождения scope; сравнивать между командами нельзя, назначать целью — вредно (закон Гудхарта).
• Burn-up лучше burn-down для релиза: scope line разделяет скорость команды и расползание объёма; на релизном горизонте, где scope меняется, это единственная честная картина.
• CFD — канон Kanban: наклон границы Done — throughput, ширина полосы In Progress — WIP (через закон Литтла — будущий cycle time), расширение полосы — узкое место, видное за недели.
• Lead Time ≠ Cycle Time: первая метрика — время ожидания заказчика (от запроса до поставки), вторая — время работы команды (от старта до завершения); их путают чаще всего.
• Метрика, ставшая целью, перестаёт быть метрикой: все метрики прогресса работают, пока остаются термометром для прогноза и сигналов — и ломаются, превращаясь в KPI.