Интерпретация Agile-метрик без оценки личной продуктивности

Здравствуйте! В предыдущем уроке мы разобрали, как Sprint Goal связывает выбранные элементы Product Backlog в единый полезный результат. Команда не обязуется «закрыть максимум тикетов»; она делает реалистичный прогноз и ежедневно адаптирует план, чтобы достичь цели Sprint и создать качественный Increment.

Теперь добавим к этому количественную обратную связь. Burndown, burnup, velocity и cycle time помогают увидеть, как движется работа: укладывается ли Sprint в прогноз, меняется ли объём, насколько стабилен поток задач. Но эти метрики описывают систему работы команды, а не ценность или занятость отдельных людей.

К концу урока вы сможете выбирать подходящую метрику для управленческого вопроса, читать типичные сигналы на графиках и не превращать показатели в персональные KPI.

---

Сначала вопрос, затем метрика

Метрика полезна только тогда, когда помогает принять решение. Если регулярно собирать цифры «потому что Jira умеет строить отчёт», команда тратит время, а руководитель получает иллюзию контроля.

Для Scrum-команды метрики отвечают на разные вопросы:

Управленческий вопрос	Подходящая метрика	Чего она не показывает
Как меняется оставшаяся работа в текущем Sprint?	Burndown	Качество результата, ценность Sprint Goal, личный вклад
Сколько работы завершено и менялся ли общий объём?	Burnup	Причины изменения объёма и качество решений
На какой объём команда может ориентироваться в ближайших Sprint?	Velocity	Скорость или эффективность конкретных специалистов
Как долго элемент проходит путь от начала работы до Done?	Cycle time	Сложность, бизнес-ценность и личную продуктивность исполнителя

Главный принцип:

Метрика — это сигнал для совместной инспекции, а не вердикт о людях.

Например, рост cycle time может означать узкое место в тестировании, ожидание доступа к среде, слишком крупные истории, зависимость от внешнего банка или появление сложных требований безопасности. Если трактовать цифру как «разработчик стал работать медленнее», команда начнёт скрывать проблемы, дробить задачи формально или переводить карточки в Done преждевременно. Данные станут красивее, а поставка — менее надёжной.

В контексте предыдущего урока полезно помнить: метрики помогают управлять прогнозом и потоком работы, но не заменяют Sprint Goal. Можно «сжечь» все story points и всё же не создать нужной ценности, если выполненные элементы не образуют пригодный Increment.

---

Четыре метрики: краткая карта

Перед деталями посмотрите, как эти показатели связаны с повседневной работой команды.

Теперь разберём каждую метрику точнее — с оговорками, которые особенно важны для TPM.

---

Burndown: сколько работы осталось в Sprint

Burndown chart, или диаграмма сгорания, показывает оставшийся объём работы во времени.

• по горизонтали располагаются дни Sprint;
• по вертикали — оставшаяся работа: например, story points, количество задач или часов;
• линия факта показывает, какой объём ещё не соответствует Definition of Done;
• пунктирная линия часто показывает ориентир равномерного завершения работы.

Если команда в начале двухнедельного Sprint прогнозирует 30 story points, график начинается около 30 и в идеале приближается к нулю к концу Sprint. Важно: «сгоревшей» считается только работа, которая действительно достигла Done, включая тестирование, ревью, необходимые проверки безопасности, документацию и другие условия Definition of Done.

Как читать форму графика

Burndown не требует, чтобы линия каждый день идеально совпадала с ориентиром. В реальной разработке работа часто завершается неравномерно. Важна не отдельная точка, а наблюдаемый паттерн и разговор команды о нём.

Наблюдение	Возможные объяснения	Полезное действие
Линия долго почти горизонтальна	Слишком много незавершённой работы, ожидание тестирования, внешняя зависимость, слишком крупные элементы	Проверить блокеры и WIP; помочь закончить начатое, а не запускать новое
Резкий спад в конце Sprint	Тестирование и приёмка отложены, задачи слишком крупные, обновления статусов происходят пакетно	Разобрать причины на ретроспективе; раньше доводить вертикальные срезы до Done
Линия выше ориентира несколько дней	Фактический поток завершения ниже первоначального прогноза	Перепланировать работу вокруг Sprint Goal, снять препятствия, обсудить сокращение второстепенного объёма
Линия растёт	В Sprint добавили объём либо уточнили оценку уже выбранной работы	Сделать изменение прозрачным: это новый scope, ошибка первоначального понимания или экстренная работа?
Работа закончилась заметно раньше	Прогноз оказался консервативным или часть работы не была учтена	Не делать вывод «люди недостаточно загружены»; обсудить качество подготовки Sprint и следующий осмысленный шаг к Product Goal

Особенно опасен последний случай. Если организация начинает требовать, чтобы каждая команда всегда точно попадала в пунктир, сотрудники быстро научатся «рисовать» благоприятную картину: искусственно завышать оценки, оставлять запас незаявленной работы или переносить статус Done на момент, удобный для отчёта.

Burndown нужен не для достижения красивой диагонали. Он нужен, чтобы раньше заметить риск для Sprint Goal.

Что делать TPM при отклонении burndown

Допустим, на седьмой день из десяти оставшийся объём почти не уменьшился. Неправильная реакция — потребовать от каждого участника объяснить, «почему он не сжёг свои points».

Более профессиональная последовательность:

1. Уточнить факты: какие элементы находятся в работе, тестировании, ревью и ожидании внешних решений.
2. Проверить блокеры: доступ к тестовому контуру, контракт внешнего API, решение по безопасности, участие аналитика или QA.
3. Вернуться к Sprint Goal: какой минимальный вертикальный сценарий нужно завершить, чтобы цель была достигнута.
4. Помочь Developers изменить план: сократить второстепенную часть объёма, организовать совместную работу над критичным элементом, эскалировать внешнюю зависимость.
5. Зафиксировать системную причину для ретроспективы, если это повторяющийся паттерн.

Sprint не нужно искусственно продлевать, чтобы график «успел дойти до нуля». Его фиксированная длительность создаёт ритм инспекции и делает фактические ограничения команды видимыми.

---

Burnup: прогресс отдельно, объём отдельно

Burndown хорошо подходит для одного Sprint, но на горизонте эпика, релизной инициативы или крупной миграции у него есть недостаток: изменение объёма не всегда очевидно. Именно здесь полезен burnup chart.

На burnup обычно нанесены две линии:

• Completed — накопленный объём работы, который соответствует Done;
• Total scope — общий известный объём работы.

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

На правой части изображения особенно заметна ценность burnup: completed steadily растёт, но total scope тоже меняется. Один лишь вопрос «когда всё будет готово?» был бы неполным. Сначала нужно выяснить, стабилен ли объём и что именно менялось.

Burnup для разговора со стейкхолдерами

Представим эпик: «Показать клиенту прозрачный статус автокредитной заявки». В начале у команды есть оценённый набор в 120 points. За два Sprint завершено 40 points. Затем выясняется, что в scope необходимо включить обязательный аудит смены статусов, дополнительные сценарии ошибок партнёрского API и миграцию части данных. Общий scope становится 150 points.

Неверная интерпретация:

Команда выполнила только 40 из 150 и стала медленнее.

Корректная интерпретация:

Команда завершила 40 points, но наше понимание необходимого объёма выросло на 30 points. Нужно обсудить, обязательны ли новые элементы для целевого результата, как они влияют на прогноз и какие варианты есть у бизнеса.

Burnup позволяет вести содержательный разговор о трёх переменных:

• объём — что входит в инициативу;
• скорость поставки — какой объём команда фактически завершает;
• срок — когда реалистично может быть готов нужный результат.

Нельзя зафиксировать все три переменные без компромиссов. Если срок неизменен, обычно нужно обсуждать объём. Если объём обязателен, диапазон сроков должен оставаться честным. Если одновременно меняются scope, команда и технология, burnup не даст точную дату — но поможет показать диапазон и причины неопределённости.

---

Velocity: исторический ориентир, а не рейтинг команды

Velocity — объём работы, который одна и та же команда завершила за один Sprint, обычно в story points. В расчёт входят только элементы, достигшие Done.

Для конкретного Sprint:

$$\mathrm{Velocity}=\text{сумма points завершённых элементов}$$

Если команда взяла 32 points, но к концу Sprint только элементы на 24 points соответствуют Definition of Done, velocity этого Sprint равна 24, а не 32. Незавершённая работа не получает «частичного зачёта».

Это важно не из формализма. Частично готовая функциональность часто ещё не создаёт ценности: код может быть написан, но не протестирован; API реализован, но не согласован контракт; экран создан, но получает недостоверные данные. Подсчёт «почти готового» скрывает именно те препятствия, которые команда должна устранить.

Как применять velocity в планировании

Velocity становится полезной после нескольких Sprint в относительно стабильных условиях. Вместо того чтобы ориентироваться на один удачный или неудачный Sprint, берут скользящее среднее последних нескольких итераций.

Допустим, за четыре Sprint команда завершила 22, 26, 24 и 28 points. Средний исторический ориентир составляет:

$$\frac{22+26+24+28}{4}=25$$

Если на следующий Sprint запланированы отпуска, on-call смены или миграционные работы, нельзя механически взять 25 points. Velocity — не обязательство и не квота. Это вход для прогноза, который Developers корректируют с учётом реальной доступности и рисков.

На уровне инициативы тот же показатель позволяет оценить порядок сроков. Если в бэклоге эпика осталось 180 points, а наблюдаемый ориентир составляет около 24 points за Sprint, грубая оценка равна:

$$180/24\approx 7.5$$

Это не обещание «ровно восемь Sprint». В расчёте не учтены изменения scope, новые зависимости, праздники, работа над инцидентами, неизвестные в интеграции и возможные изменения состава команды. Поэтому для стейкхолдеров лучше сообщать диапазон и условия прогноза, а не одну календарную дату.

Почему velocity нельзя сравнивать

Velocity — локальная единица измерения, потому что story points локальны.

Одна команда может считать задачу на пять points умеренно сложной, а другая — оценить похожую работу в тринадцать points. Обе оценки могут быть согласованными и полезными внутри своих команд. Поэтому сравнение «у команды A velocity 45, а у команды B 30» не говорит, что первая работает в полтора раза эффективнее.

Не сравнивайте velocity:

• между разными командами;
• между командой до и после смены правил оценки;
• между продуктами с различным типом работы;
• между людьми внутри команды;
• как цель для премирования или оценки эффективности.

Если velocity становится KPI, команда получает стимул повышать points, а не улучшать поставку. Возникает инфляция оценок: вчерашняя задача на три points постепенно становится задачей на восемь, хотя реальная сложность не изменилась.

При этом снижение velocity не всегда плохо. Например, команда могла посвятить Sprint устранению критичной уязвимости, внедрению обязательного аудита, сложной миграции данных или помощи в инциденте production. Метрика должна стать поводом спросить: что изменилось в системе работы? — а не поводом назначить виноватого.

---

Cycle time: как быстро элементы проходят весь путь до Done

Cycle time — время, за которое один рабочий элемент проходит путь от согласованного начала активной работы до Done. Чаще всего момент старта — перевод карточки в статус «In Progress», а конец — её попадание в Done по правилам команды.

В отличие от velocity, который отвечает на вопрос об объёме, cycle time отвечает на вопрос о скорости прохождения одного элемента через систему.

Например:

• задача переведена в In Progress в понедельник;
• проходит разработку, code review, тестирование и приёмку;
• в следующий понедельник соответствует Done.

Её cycle time составляет пять рабочих дней.

Перед тем как анализировать метрику, команда должна явно договориться:

• какие статусы считаются началом и концом;
• включаются ли в Done приёмка Product Owner, выкладка и документация;
• считаются ли календарные или рабочие дни;
• какие типы элементов анализируются вместе, а какие отдельно.

Если эти правила меняются, график «до» и «после» становится несопоставимым. Например, перевод приёмки Product Owner за границу Done может искусственно сократить cycle time, но не ускорить реальную поставку.

Стабильность важнее рекорда

Хороший признак — не обязательно минимальное среднее значение, а относительно стабильное время прохождения схожих элементов. Тогда команда и Product Owner могут реалистичнее прогнозировать поставку.

Представьте две ситуации:

Команда	Cycle time задач	Практический смысл
Первая	от 1 до 18 дней	Прогноз по одной задаче ненадёжен; вероятны блокировки, крупные элементы или скачки WIP
Вторая	чаще от 3 до 6 дней	Процесс более предсказуем; можно увереннее планировать поток небольших элементов

Среднее значение полезно, но его недостаточно. Если средний cycle time равен пяти дням, а половина задач проходит за один день и несколько — за двадцать, реальный риск скрыт. Поэтому TPM стоит смотреть на распределение: типичное значение, разброс, долю «долгоживущих» задач и обстоятельства, которые сопровождали выбросы.

Что может увеличить cycle time

Рост времени цикла — это сигнал для диагностики. Возможные причины:

• истории стали крупнее или хуже декомпозированы;
• команда начала больше задач одновременно, и незавершённая работа накапливается;
• тестирование, ревью или согласование стали узким местом;
• появился внешний поставщик, регуляторная проверка или зависимость от другой команды;
• тестовая среда нестабильна;
• Definition of Done расширился, например добавились нагрузочные проверки или аудит.

Не все причины требуют «ускорения». Иногда увеличение cycle time — нормальная цена за более строгие требования качества и безопасности. Для FinTech-потока это может быть разумнее, чем быстро провести изменение без аудита и контроля ошибок.

Типовая реакция на плохой поток — уменьшить размер вертикальных срезов, ограничить количество параллельно начатой работы и помогать доводить начатые элементы до Done. Иногда эффективнее, чтобы несколько специалистов временно завершили критичный элемент вместе, чем чтобы каждый начал отдельную задачу.

---

Кейс: метрики в Sprint команды кредитной платформы

Вернёмся к Sprint Goal из прошлого урока:

Клиент, получивший предварительное решение, понимает текущий этап обработки заявки и следующий необходимый шаг.

Команда планирует десятидневный Sprint и выбирает работу примерно на 32 points. В ходе Sprint возникают следующие наблюдения:

• на шестой день burndown почти не меняется;
• в колонке «На тестировании» накопилось четыре элемента;
• два элемента ожидают уточнения статуса от внешнего скорингового сервиса;
• к концу Sprint достигли Done элементы на 24 points;
• средний cycle time похожих задач вырос с четырёх до восьми рабочих дней.

Плохая управленческая реакция:

У команды упала скорость; нужно требовать быстрее закрывать задачи.

Такая формулировка смешивает разные явления и игнорирует контекст. Здесь видны как минимум две гипотезы:

1. Тестирование стало bottleneck. Четыре элемента одновременно ждут одну функцию процесса. Возможно, команда взяла слишком много параллельной работы или тестовая среда недостаточно стабильна.
2. Внешняя интеграция увеличила неопределённость. Неясные статусы партнёра задерживают не только backend, но и тексты для клиента, ошибки обработки и критерии приёмки.

Более полезные действия TPM:

• сделать ожидание внешнего ответа видимым как риск и владелец зависимости;
• обсудить с командой, какие элементы можно завершить в первую очередь, чтобы сохранить Sprint Goal;
• помочь снять bottleneck в тестировании: выделить время специалистов, уменьшить WIP, обеспечить стенд или согласовать тестовые данные;
• на ретроспективе проверить, как изменилась декомпозиция историй и какие условия refinement не были выполнены;
• использовать 24 points как факт для будущего прогноза, но не как норму, которую нужно превзойти в следующем Sprint.

Если при этом основная часть сквозного сценария готова и клиент действительно получает достоверный статус, Sprint мог достигнуть своей цели, даже если часть первоначального объёма перенесена. Метрики не отменяют профессионального суждения о ценности результата.

---

Защита от «игры с метриками»

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

• velocity как KPI стимулирует завышать story points;
• cycle time как персональный KPI стимулирует дробить карточки формально или переводить их в Done до полного завершения;
• burndown как обязательный план стимулирует скрывать добавленный scope;
• сравнение команд по velocity стимулирует подгонять локальные шкалы оценки.

Чтобы метрики оставались инструментом улучшения, полезно закрепить несколько правил.

1. Обсуждайте тренды, а не один Sprint или одну задачу. Один период может быть искажён инцидентом, отпуском ключевого специалиста или разовой сложной интеграцией.

2. Сегментируйте несопоставимую работу. Отдельно смотрите, например, продуктовые истории, production-инциденты, инфраструктурные задачи и регуляторные изменения. Средний cycle time смешанной выборки часто вводит в заблуждение.

3. Аннотируйте значимые события. На графике velocity или burnup полезно отметить смену состава команды, релизную заморозку, крупный инцидент, изменение Definition of Done или подключение нового внешнего поставщика.

4. Оставляйте интерпретацию команде. TPM может принести данные и задать рамку обсуждения, но Developers лучше знают реальные причины движения карточек через процесс.

5. Связывайте вывод с конкретным экспериментом. Не «надо повысить velocity», а, например: «В следующих двух Sprint ограничим число одновременно начатых историй и проверим, сократилось ли число элементов, ожидающих тестирования».

6. Проверяйте ценность отдельно. Ни velocity, ни cycle time не покажут, снизилось ли число обращений клиентов в поддержку или стал ли процесс заявки понятнее. Для этого нужны продуктовые и пользовательские показатели.

---

Итоги

Burndown, burnup, velocity и cycle time освещают разные стороны системы поставки:

• Burndown показывает оставшуюся работу внутри Sprint и помогает раньше заметить риск для Sprint Goal.
• Burnup показывает завершённый объём рядом с общим scope, поэтому особенно полезен для эпиков, релизов и разговоров об изменении объёма.
• Velocity — исторический ориентир для прогноза конкретной стабильной команды; это не рейтинг и не персональный KPI.
• Cycle time показывает, как долго элемент проходит путь до Done, и помогает искать узкие места в потоке работы.

Во всех случаях сначала формулируйте управленческий вопрос, затем смотрите на динамику и контекст, а после этого вместе с командой выбирайте улучшение процесса. Метрика должна делать проблемы видимыми и безопасными для обсуждения, а не заставлять людей скрывать их.

В следующем уроке мы разберём типичные анти-паттерны Scrum: формальные церемонии, «мини-водопад» внутри Sprint, подмену ролей, перегруженный Sprint Backlog и другие ситуации, в которых внешние признаки Scrum есть, а эмпирическое управление работой исчезает.