metrics

Метрики Agile

Введение

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

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

“Когда мера становится целью, она перестаёт быть хорошей мерой.” Метрики нужны для диагностики и улучшения процессов, а не для оценки отдельных сотрудников или давления на команду. Как только метрика начинает использоваться как KPI для наказания - люди начинают оптимизировать метрику, а не процесс.

Vanity-метрики vs Actionable-метрики

Тип	Описание	Примеры
Vanity (тщеславные)	Красиво выглядят на дашборде, но не помогают принимать решения	Количество строк кода, общее число коммитов, “часы работы”
Actionable (действенные)	Дают ясный сигнал о проблеме и подсказывают, что нужно изменить	Cycle Time, Throughput, Change Failure Rate, Flow Efficiency

Принцип: Measure to improve, not to judge

Каждая метрика должна отвечать на вопрос: “Что мы будем делать иначе, если это число изменится?”

Принципы хороших метрик

1. Прозрачность - метрики доступны всей команде, не только менеджменту
2. Контекст - числа без контекста бесполезны (velocity 42 - это хорошо или плохо?)
3. Тренды важнее абсолютных значений - следите за динамикой, а не за конкретным числом
4. Минимализм - лучше 3-5 ключевых метрик, чем 30 неотслеживаемых
5. Командные, а не индивидуальные - метрики измеряют систему, а не людей

---

Метрики потока (Flow Metrics)

Метрики потока пришли из Lean и Kanban. Они измеряют, как работа проходит через систему от момента запроса до момента поставки.

Lead Time

Lead Time - время от момента поступления запроса (задача создана / попала в бэклог) до момента поставки ценности конечному пользователю.

Lead Time = Дата поставки - Дата поступления запроса

Lead Time включает в себя всё время ожидания: в бэклоге, в очереди на разработку, в разработке, на ревью, на тестировании, на деплое.

Что показывает: предсказуемость поставки для заказчика. Чем стабильнее Lead Time, тем точнее можно прогнозировать сроки.

Как улучшить:

• Уменьшить WIP (незавершённую работу)
• Ускорить ревью и тестирование
• Автоматизировать деплой
• Убрать этапы ожидания и согласования

Cycle Time

Cycle Time - время от начала активной работы над задачей до её завершения.

Cycle Time = Дата завершения - Дата начала работы

Cycle Time - это подмножество Lead Time. Он не включает время ожидания в бэклоге.

Соотношение:

Lead Time = Время ожидания в бэклоге + Cycle Time

Что показывает: эффективность самого рабочего процесса команды.

Lead Time - для заказчика, Cycle Time - для команды

Заказчику важно, когда его запрос будет выполнен (Lead Time). Команде важно понимать, сколько занимает непосредственная работа (Cycle Time).

Throughput (Пропускная способность)

Throughput - количество завершённых единиц работы за единицу времени.

Throughput = Количество завершённых задач / Период времени

Например: 12 задач в неделю, 48 задач в месяц.

Чем полезен:

• Позволяет прогнозировать, сколько задач команда может выполнить за спринт/месяц
• Помогает определить реалистичный объём работы на итерацию
• Тренд Throughput показывает, растёт или падает продуктивность команды

Throughput vs Velocity: Throughput считает количество задач, Velocity - сумму Story Points. Throughput проще и менее подвержен манипуляциям.

WIP (Work in Progress)

WIP - количество задач, находящихся в работе одновременно.

Закон Литтла

Фундаментальная связь между тремя метриками потока:

Cycle Time = WIP / Throughput

Или эквивалентно:

WIP = Throughput x Cycle Time

Следствие закона Литтла

При постоянном Throughput, уменьшение WIP напрямую уменьшает Cycle Time. Это математическое обоснование WIP-лимитов в Kanban.

WIP-лимиты

WIP-лимит - это максимальное количество задач, допустимых на определённом этапе работы (колонке на канбан-доске).

Эффекты WIP-лимитов:

Эффект	Описание
Уменьшение Cycle Time	Меньше переключений контекста, задачи быстрее проходят через систему
Выявление узких мест	Когда колонка “забита” до лимита, видно, где тормозит процесс
Повышение качества	Команда фокусируется на меньшем количестве задач одновременно
Снижение стресса	Меньше параллельных потоков работы для каждого участника

Как определить начальный WIP-лимит:

• Формула-ориентир: WIP-лимит = количество участников x 1.5 (округлить до целого)
• Затем корректировать эмпирически: если лимит слишком высок - задачи стоят; если слишком низок - люди простаивают

Flow Efficiency (Эффективность потока)

Flow Efficiency - отношение времени активной работы к общему Lead Time.

Flow Efficiency = (Время активной работы / Lead Time) x 100%

Типичные значения:

• Большинство организаций: 5-15% (шокирующе низко!)
• Хорошие команды: 15-40%
• Отличные команды: 40%+

Это значит, что в среднем задача 85-95% времени ждёт, а не обрабатывается.

Как улучшить:

• Уменьшить WIP
• Устранить этапы согласования и ручного одобрения
• Автоматизировать тестирование и деплой
• Улучшить кросс-функциональность команды

Cumulative Flow Diagram (CFD)

CFD (Накопительная диаграмма потока) - визуализация количества задач на каждом этапе работы в динамике времени.

CFD - один из самых мощных аналитических инструментов Kanban. По одной диаграмме можно определить Lead Time, WIP, Throughput и выявить проблемы.

Как читать CFD

На графике по оси X - время, по оси Y - количество задач. Каждая цветная полоса соответствует этапу работы (бэклог, в работе, ревью, тестирование, готово).

Ключевые паттерны:

Паттерн	Что видно на CFD	Что означает
Параллельные полосы	Ширина каждой полосы постоянна	Стабильный поток, процесс предсказуем
Расширяющаяся полоса	Определённый этап растёт	Узкое место: задачи застревают на этом этапе
”Лестница” на линии Done	Задачи завершаются партиями	Батчинг вместо непрерывного потока
Схождение полос	Работа не поступает, но завершается	Истощение входного потока
Расхождение полос	Поступает больше, чем завершается	Перегрузка: WIP растёт бесконтрольно

Как извлечь метрики из CFD:

• Lead Time = горизонтальное расстояние между линией поступления и линией завершения
• WIP = вертикальное расстояние между линиями поступления и завершения
• Throughput = наклон линии завершения (чем круче, тем выше пропускная способность)

---

Velocity и планирование

Velocity (Скорость команды)

Velocity - суммарное количество Story Points завершённых задач за спринт.

Velocity = SUM(Story Points завершённых задач за спринт)

Расчёт средней Velocity:

Берётся среднее арифметическое за последние 3-5 спринтов:

Средняя Velocity = (V(Sprint N-2) + V(Sprint N-1) + V(Sprint N)) / 3

Пример: команда за 3 спринта завершила задачи на 99, 101, 100 SP. Средняя Velocity = 100 SP. Это означает, что на следующий спринт команда может взять примерно 100 SP.

Velocity - не мера продуктивности!

Velocity - это инструмент планирования, а не оценки эффективности. Нельзя сравнивать Velocity разных команд. Нельзя требовать “повышения Velocity”. Это приведёт к инфляции оценок (Story Points начнут искусственно завышаться).

Pitfalls использования Velocity:

• Сравнение Velocity между командами (разные шкалы оценки)
• Использование как KPI (инфляция Story Points)
• Принуждение к увеличению Velocity (жертвование качеством)
• Планирование по Velocity новой/неустоявшейся команды (нет истории)

Sprint Goal Completion Rate

Sprint Goal Completion Rate - процент спринтов, в которых была достигнута поставленная цель спринта.

Sprint Goal Completion Rate = (Спринты с достигнутой целью / Общее количество спринтов) x 100%

Целевое значение: >= 80%

Эта метрика важнее, чем процент выполненных задач, потому что цель спринта - это то, что реально несёт ценность. Можно выполнить 95% задач, но не достичь цели.

Burndown Chart (Диаграмма сгорания)

Burndown-диаграмма показывает количество оставшейся работы в спринте по дням.

Ось X - дни спринта, Ось Y - оставшиеся Story Points (или количество задач).

Идеальная линия - прямая от общего объёма работы до нуля.

Паттерны:

Паттерн	Описание	Что делать
Линия выше идеальной	Отставание от плана	Пересмотреть скоуп, убрать задачи
Линия ниже идеальной	Команда опережает план	Можно взять дополнительные задачи
”Плато” в начале	Задачи не начинают завершаться	Возможно, задачи слишком крупные - декомпозировать
Резкое падение в конце	Задачи закрываются пачкой в конце спринта	Проблема: вероятно, задачи не завершены качественно
Линия идёт вверх	Добавляются новые задачи в спринт	Нарушение Sprint Commitment - обсудить на ретро

Burnup Chart (Диаграмма нарастания)

Burnup показывает два графика одновременно:

1. Общий объём запланированной работы (scope)
2. Завершённая работа

Преимущество перед Burndown: видно, когда объём работы менялся (scope creep). На Burndown это скрыто.

Capacity (Ёмкость команды)

Capacity - реальное количество рабочих часов команды на спринт с учётом отпусков, больничных, встреч и технического долга.

Capacity = Количество участников x Рабочие дни x Фокус-фактор

Фокус-фактор (обычно 0.6-0.8) учитывает время, потерянное на встречи, переключения контекста и прочее.

Capacity != Velocity:

• Capacity - это входные данные (сколько времени есть)
• Velocity - это выходные данные (сколько работы получается сделать)

---

DORA метрики

DORA (DevOps Research and Assessment) - набор из четырёх метрик, разработанных командой Google Cloud на основе исследований более 30 000 специалистов за 6 лет. Описаны в книге "Accelerate" (Nicole Forsgren, Jez Humble, Gene Kim).

DORA-метрики измеряют эффективность поставки ПО и являются золотым стандартом для оценки DevOps-зрелости.

Четыре метрики DORA

1. Deployment Frequency (Частота деплоев)

Определение: Как часто код успешно деплоится в прод.

Уровень	Частота
Elite	Несколько раз в день (on-demand)
High	От раза в день до раза в неделю
Medium	От раза в неделю до раза в месяц
Low	Реже, чем раз в месяц

Как улучшить:

• CI/CD-пайплайн с автоматическим деплоем
• Feature flags для разделения деплоя и релиза
• Trunk-based development вместо долгоживущих веток
• Уменьшение размера изменений (small batches)

2. Lead Time for Changes (Время от коммита до прода)

Определение: Время от момента коммита кода до его успешного запуска в продакшене.

Уровень	Время
Elite	Менее одного дня
High	От одного дня до одной недели
Medium	От одной недели до одного месяца
Low	Более одного месяца

Это не тот же Lead Time, что в Kanban

DORA Lead Time for Changes измеряет только техническую часть: от коммита до прода. Kanban Lead Time - от появления запроса до поставки.

Как улучшить:

• Автоматизация тестирования (unit, integration, E2E)
• Параллельное выполнение этапов CI/CD
• Автоматизированное code review (линтеры, SAST)
• Уменьшение ручных gate-ов

3. Mean Time to Recovery - MTTR (Среднее время восстановления)

Определение: Среднее время от обнаружения сбоя в продакшене до полного восстановления работоспособности.

Уровень	Время
Elite	Менее одного часа
High	Менее одного дня
Medium	От одного дня до одной недели
Low	Более одной недели

Как улучшить:

• Мониторинг и алертинг (Prometheus, Grafana, PagerDuty)
• Автоматический rollback
• Feature flags для быстрого отключения проблемных фич
• Runbook-и для типичных инцидентов
• Chaos Engineering (тренировка реакции на сбои)

4. Change Failure Rate (Доля неудачных изменений)

Определение: Процент деплоев, которые приводят к сбоям в продакшене и требуют hotfix, rollback или patch.

Уровень	Процент
Elite	0-5%
High	6-10%
Medium	11-15%
Low	16-30%+

Как улучшить:

• Расширение автоматического тестирования
• Canary-деплой и blue-green деплой
• Peer code review с чеклистами
• Smoke-тесты после деплоя
• Feature flags и постепенное раскатывание

Взаимосвязь DORA-метрик

Ключевой вывод из исследований DORA

Команды с высокими показателями Deployment Frequency и Lead Time for Changes одновременно демонстрируют низкий Change Failure Rate и быстрый MTTR. Скорость и качество не противоречат друг другу - они взаимоусиливаются.

Рекомендуемая литература:

• “Accelerate: The Science of Lean Software and DevOps” - Nicole Forsgren, Jez Humble, Gene Kim (2018)
• Ежегодные отчёты DORA (State of DevOps Report): https://dora.dev

---

Метрики качества

Defect Density (Плотность дефектов)

Defect Density - количество дефектов на единицу объёма кода или на единицу работы.

Defect Density = Количество дефектов / (Тысячи строк кода)  [дефекты/KLOC]

Или в контексте Agile:

Defect Density = Количество дефектов / Количество Story Points

Типичные значения (промышленный стандарт):

• Среднее ПО: 15-50 дефектов на KLOC
• Качественное ПО: 2-10 дефектов на KLOC
• Критическое ПО (NASA, авиация): < 1 дефект на KLOC

Escaped Defects (Дефекты, прошедшие в продакшен)

Escaped Defects - дефекты, обнаруженные пользователями в продакшене, а не на этапах тестирования.

Escaped Defect Rate = (Дефекты в проде / Общее количество дефектов) x 100%

Это критическая метрика, потому что стоимость исправления дефекта в продакшене в 10-100 раз выше, чем на этапе разработки (по данным IBM Systems Sciences Institute).

Целевое значение: < 10%

Как снизить:

• Shift-left testing (тестирование на ранних этапах)
• Code review с чеклистами
• Автоматизированное регрессионное тестирование
• Качественные AC (Acceptance Criteria) и DoD

Technical Debt (Технический долг)

Technical Debt - объём "быстрых" решений в коде, которые потребуют переделки в будущем.

Измерить технический долг можно несколькими способами:

1. Technical Debt Ratio (TDR):

TDR = (Стоимость устранения долга / Стоимость разработки с нуля) x 100%

2. Процент спринта на техдолг:

Рекомендуется: 15-20% ёмкости спринта на работу с техдолгом

3. Инструментальные метрики: SonarQube, Code Climate предоставляют оценку техдолга в человеко-днях.

Code Coverage (Покрытие кода тестами)

Code Coverage = (Строки кода, покрытые тестами / Общие строки кода) x 100%

Ловушки Code Coverage

• 100% покрытие не гарантирует отсутствие багов
• Покрытие можно накручивать тестами без assertions
• Важнее покрытие критических путей и граничных условий, чем общий процент
• Хорошее покрытие: 70-85% для бизнес-логики, 50-70% для инфраструктурного кода

Mean Time Between Failures (MTBF)

MTBF - среднее время безотказной работы системы между сбоями.

MTBF = Общее время работы / Количество сбоев

Чем выше MTBF, тем надёжнее система. Связана с MTTR - обе нужны для оценки доступности:

Availability = MTBF / (MTBF + MTTR)

---

Метрики команды и организации

Team Health Check (Spotify модель)

Разработан в Spotify для оценки “здоровья” команды по множеству параметров. Не числовая метрика, а качественная оценка с использованием цветовой шкалы.

Параметры (примеры):

Параметр	Зелёный (хорошо)	Жёлтый (есть проблемы)	Красный (плохо)
Delivering Value	Поставляем ценность регулярно	Иногда пропускаем	Заказчик недоволен
Speed	Работаем быстро, нет блокеров	Иногда тормозим	Постоянные задержки
Fun	Работать интересно	Бывает скучно	Хочется уволиться
Learning	Постоянно учимся	Нет времени на обучение	Стагнация
Teamwork	Команда - единое целое	Есть изоляция	Каждый сам по себе
Support	Помощь всегда доступна	Иногда не получается	Нет поддержки
Mission	Понимаем, зачем работаем	Частично непонятно	Не понимаем миссию
Codebase Health	Код чистый и поддерживаемый	Есть проблемные зоны	Legacy-хаос

Проведение: команда голосует карточками (зелёный/жёлтый/красный) по каждому параметру. Важно обсудить красные и жёлтые зоны, зафиксировать action items.

Периодичность: раз в квартал или после каждого PI.

eNPS (Employee Net Promoter Score)

eNPS - индекс лояльности сотрудников, адаптированный из маркетинга (NPS).

Вопрос: “С какой вероятностью от 0 до 10 вы порекомендуете работу в вашей компании/команде знакомому?”

Категория	Оценка
Промоутеры	9-10
Нейтральные	7-8
Критики	0-6

eNPS = % Промоутеров - % Критиков

Диапазон: от -100 до +100. Хороший eNPS: > +10. Отличный eNPS: > +50.

Bus Factor

Bus Factor - минимальное количество людей, уход которых из команды критически затруднит работу.

Bus Factor = 1 означает, что один ушедший сотрудник парализует работу. Это серьёзный риск.

Целевое значение: >= 3

Как улучшить:

• Парное программирование
• Code review всего кода
• Ротация задач между участниками
• Документирование знаний
• Карты компетенций (Star Map)

Star Map / Карта компетенций

Инструмент для визуализации компетенций каждого члена команды.

Компетенция	Сотрудник A	Сотрудник B	Сотрудник C
Backend	4 (эксперт)	2 (средний)	1 (базовый)
Frontend	1	4	3
DevOps	2	1	4
QA	3	3	2
Архитектура	4	2	3

Шкала: 0 - нет знаний, 1 - базовые, 2 - средний, 3 - продвинутый, 4 - эксперт.

Применение:

• Определение Bus Factor по каждому направлению
• Планирование развития сотрудников
• Распределение задач для наращивания кросс-функциональности
• Подробнее: Сторипоинты

Team Happiness Index

Простая метрика: каждый участник команды на ежедневной встрече или еженедельно оценивает своё настроение/удовлетворённость по шкале от 1 до 5.

Team Happiness = Среднее значение оценок команды

Целевое значение: >= 3.5

Тренд вниз - сигнал для ретроспективы и обсуждения причин.

---

Операционные метрики

Cost of Delay (Стоимость задержки)

Cost of Delay - финансовые потери от задержки в поставке фичи.

Cost of Delay = Упущенная выгода в неделю/месяц задержки

Это метрика, которая позволяет приоритизировать задачи не по субъективной важности, а по экономическому влиянию.

Формула WSJF (Weighted Shortest Job First):

WSJF = Cost of Delay / Job Duration

Задачи с высоким WSJF выполняются первыми (максимальная ценность за минимальное время).

Используется в SAFe для приоритизации бэклога.

Value Delivered per Sprint

Качественная оценка ценности, поставленной за спринт:

• Количество завершённых пользовательских историй
• Процент достижения Sprint Goal
• Бизнес-метрики: конверсия, retention, revenue от выпущенных фич

ROI фич

ROI = (Прибыль от фичи - Стоимость разработки) / Стоимость разработки x 100%

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

Операционные метрики команды

Метрика	Описание	Периодичность
Задач завершено	Количество закрытых задач	Ежедневно/еженедельно
Задач в бэклоге	Размер бэклога	Еженедельно
Время на встречи	% рабочего времени на meetings	Еженедельно
Время на техдолг	% спринта на техдолг	За спринт
Блокеры	Количество и длительность блокеров	Ежедневно
Rework rate	% задач, возвращённых на доработку	За спринт

---

Визуализация и инструменты

Дашборд команды

Рекомендуемый минимальный набор метрик на дашборде:

+-------------------+-------------------+-------------------+
|    Throughput      |    Cycle Time     |    WIP            |
|    (тренд)        |    (медиана)      |    (текущий)      |
+-------------------+-------------------+-------------------+
|    CFD             |   Sprint Burndown |   Sprint Goal     |
|    (накопительная) |   (текущий)       |   Completion %    |
+-------------------+-------------------+-------------------+
|    DORA: Deploy    |   DORA: Lead Time |   DORA: CFR       |
|    Frequency       |   for Changes     |   & MTTR          |
+-------------------+-------------------+-------------------+

Burndown: паттерны и анти-паттерны

Паттерн	Визуально	Причина	Решение
Идеальный	Ровная линия вниз	Хороший баланс скоупа и ёмкости	Поддерживать
”Утёс”	Всё внизу в последний день	Задачи закрываются формально	Декомпозировать задачи мельче
”Плато”	Горизонтальная линия	Блокеры или слишком крупные задачи	Разбить задачи, устранить блокеры
”Гора”	Линия идёт вверх	Scope creep	Защитить Sprint Scope

Инструменты

Инструмент	Встроенная аналитика	Сильные стороны
Jira	Velocity, Burndown, CFD, Control Chart	Глубокая настройка, экосистема Atlassian
Kaiten	CFD, Cycle Time, Lead Time, Throughput	Канбан-ориентированный, удобный CFD, русский UI
YouTrack	Burndown, Time Tracking, Custom reports	Гибкие workflows, бесплатен для малых команд
Azure DevOps	Velocity, Burndown, CFD, DORA	Интеграция с Azure CI/CD
LinearB	DORA, Cycle Time, Review Time	Автоматический сбор из Git и CI/CD
Jellyfish	Engineering metrics, Allocation	Для engineering leadership
Grafana + Prometheus	Любые кастомные метрики	Для технических метрик и DORA

---

Практическое внедрение

Алгоритм внедрения метрик

Шаг 1: Начните с малого

Не пытайтесь внедрить все метрики сразу. Начните с 2-3 метрик:

Уровень зрелости	Рекомендуемые метрики
Начинающая команда	Throughput + Cycle Time
Практикующая команда	+ CFD + Sprint Goal Completion Rate
Зрелая команда	+ DORA метрики + Flow Efficiency
Продвинутая команда	+ Quality метрики + Team Health

Шаг 2: Настройте автоматический сбор

Метрики должны собираться автоматически из существующих инструментов:

• Трекер задач (Jira, Kaiten) - Throughput, Cycle Time, Lead Time, CFD
• CI/CD (GitHub Actions, GitLab CI) - DORA метрики
• Мониторинг (Grafana) - MTBF, MTTR

Ручной сбор метрик - это анти-паттерн

Если для метрики нужен ручной ввод, она перестанет собираться через 2 недели. Автоматизируйте.

Шаг 3: Визуализируйте и обсуждайте

• Разместите дашборд на видном месте (телевизор в офисе или ссылка в канале)
• Обсуждайте тренды на ретроспективах
• Выявляйте корневые причины отклонений

Шаг 4: Действуйте на основе данных

Метрика → Гипотеза → Эксперимент → Измерение результата:

1. Cycle Time вырос → Гипотеза: слишком большой WIP
2. Эксперимент: ввести WIP-лимит = 3 на колонку “В работе”
3. Через 2 спринта: проверить, снизился ли Cycle Time

Анти-паттерны внедрения метрик

Анти-паттерн	Описание	Последствие
Метрики как кнут	Использование для наказания	Фальсификация данных, демотивация
Метрическая перегрузка	20+ метрик одновременно	Ни одна не отслеживается реально
Vanity dashboard	Красивые графики без action items	Самообман
Сравнение команд	Velocity команды A vs команды B	Разрушение доверия, гонка показателей
Игнорирование контекста	”Cycle Time вырос - команда ленится”	Неверные выводы (может быть техдолг, отпуска)
Ручной ввод	Люди вводят метрики руками	Данные быстро устаревают или фальсифицируются

Чеклист для старта

• Определить 2-3 метрики для начала
• Настроить автоматический сбор из трекера задач
• Создать дашборд (Jira Board, Kaiten analytics, Grafana)
• Провести вводную встречу с командой: зачем метрики, как будем использовать
• Договориться: метрики - для процесса, не для оценки людей
• Включить обсуждение метрик в повестку ретроспективы
• Через месяц: ревью - помогают ли метрики? Нужно ли что-то изменить?

---

Рекомендуемая литература

1. “Accelerate” - Nicole Forsgren, Jez Humble, Gene Kim. Научное обоснование DORA-метрик.
2. “Actionable Agile Metrics for Predictability” - Daniel Vacanti. Глубокое погружение в Flow Metrics.
3. “When Will It Be Done?” - Daniel Vacanti. Прогнозирование с помощью метрик потока.
4. “Kanban from the Inside” - Mike Burrows. Практическое применение Kanban и метрик.
5. “Measuring and Managing Performance in Organizations” - Robert Austin. Почему метрики опасны и как их правильно использовать.
6. DORA Reports - https://dora.dev - ежегодные исследования DevOps-практик.