Время освоения: ~40 минут Цель : Научиться использовать метрики для измерения эффективности, прогнозирования и непрерывного улучшения процессов
Метрика Что измеряет Для чего Где применяется Velocity Story points за спринт Прогнозирование объёма Scrum Cycle Time Время "В работе" → "Готово" Оптимизация процесса Scrum + Kanban Lead Time Время запрос → доставка Скорость ценности Scrum + Kanban Throughput Задач завершено за период Прогнозирование в Kanban Kanban CFD Накопленный поток по состояниям Узкие места, прогноз Kanban
Lead Time = Время ожидания в бэклоге + Cycle Time
Velocity = Σ story points завершённых задач за спринт
Throughput = Кол-во задач ÷ Период
Закон Литтла = Cycle Time = WIP ÷ Throughput
Используй Не используй Velocity для прогнозирования спринта Velocity для сравнения команд Cycle time для поиска узких мест Velocity как KPI разработчика Lead time для оценки скорости доставки Количество задач без контекста CFD для визуализации потока Процент выполнения спринта как "успех"
# Как читать CFD (Cumulative Flow Diagram)Элемент Что означает Ширина полосы Объём работы в этом состоянии Сужение Узкое место (bottleneck) Наклон линий Скорость потока Расстояние между линиями Время ожидания
Метрики Agile — это инструменты для измерения эффективности работы команды, прогнозирования результатов и выявления областей для улучшения.
Ключевые принципы использования метрик :
Метрики должны служить улучшению процесса, а не оценке людей
Фокус на нескольких ключевых метриках вместо большого количества
Измерение должно быть простым и автоматизированным
Интерпретация важнее сбора данных
Основные категории метрик :
Прогнозирование : velocity, throughputЭффективность процесса : cycle time, lead timeВизуализация потока : CFD (Cumulative Flow Diagram)Качество : процент завершенных задач, технический долг
💡 Помните : Хорошая метрика помогает принимать лучшие решения. Плохая метрика искажает поведение и приводит к анти-паттернам.
# Основные метрики Agile (25 минут)Что это : Среднее количество story points, завершенных за спринт.
Сумма story points всех завершенных задач в спринте
Среднее значение за последние 3-5 спринтов
Не включать незавершенные задачи
Прогнозирование объема работы на следующий спринт
Планирование релизов и сроков
Анализ стабильности команды
Использовать только для внутреннего планирования
Не сравнивать velocity между командами
Стабильный velocity = предсказуемость процесса
Story points — относительная мера сложности (усилия + риски + неопределенность)
Использование velocity для оценки производительности разработчиков
Сравнение velocity разных команд
Изменение шкалы story points во время проекта
# 2. Cycle Time (Цикловое время)Что это : Время от начала работы над задачей до ее завершения.
От момента перехода задачи в "В работе" до "Готово"
Измеряется в днях или часах
Для точности — исключать выходные и праздники (опционально)
Оптимизация процесса и выявление узких мест
Прогнозирование времени выполнения новых задач
Анализ эффективности команды
Строить диаграммы распределения cycle time
Анализировать тренды во времени
Сравнивать с lead time для анализа эффективности
Пример : Если среднее cycle time = 3 дня, можно прогнозировать, что новая задача займет около 3 дней.
# 3. Lead Time (Время доставки)Что это : Время от появления запроса до его завершения и доставки пользователю.
От добавления задачи в бэклог до перехода в "Готово"
Включает: время ожидания в бэклоге + cycle time
Измерение скорости доставки ценности пользователю
Анализ эффективности всего процесса
Сравнение с cycle time для выявления проблем в очереди
Формула : Lead Time = Время ожидания в бэклоге + Cycle Time
Цель: сокращение lead time через оптимизацию всей цепочки
Анализировать, где теряется время — в ожидании или в процессе
Использовать для приоритизации улучшений
# 4. Throughput (Пропускная способность)Что это : Количество задач, завершенных за определенный период времени.
Количество задач (не story points) в спринте или неделю
Обычно используется в Kanban
Прогнозирование в Kanban
Управление потоком работы
Сравнение эффективности до и после изменений
Throughput — количество задач (абсолютное значение)
Velocity — story points (относительная мера сложности)
Throughput более объективен для команд без story points
Использовать для команд, использующих Kanban
Комбинировать с cycle time для полной картины
Анализировать распределение throughput по классам задач
# 5. CFD (Cumulative Flow Diagram)Что это : График, показывающий накопленное количество задач в каждом состоянии потока.
Ширина области : объем работы в системеСужения : узкие места (bottlenecks)Наклон линий : скорость потокаРасстояние между линиями : время ожидания
Визуализация потока работы
Выявление узких мест
Прогнозирование даты завершения
Анализ стабильности процесса
Обновлять ежедневно
Анализировать изменения во времени
Использовать для ретроспектив и планирования
# Анти-паттерны и адаптация (10 минут)# Основные анти-паттерны метрик# 1. Метрическое давление (Metric Pressure)
Проявление : Метрики используются для оценки производительности отдельных разработчиковПроблемы : Снижение качества, фокус на количестве вместо ценности, игнорирование техдолгаРешение : Использовать метрики только для улучшения процесса, а не для оценки людей
# 2. Метрический цирк (Metrics Circus)
Проявление : Метрики превращаются в показательные мероприятия для руководстваПример : Команда улучшает velocity за счет упрощения задач, а не увеличения ценностиРешение : Фокусироваться на качестве метрик, а не на их количестве; использовать для улучшения
# 3. Метрический барьер (Metrics Barrier)
Проявление : Метрики становятся препятствием для работы вместо помощиПример : Слишком много метрик, которые отнимают время на сбор и анализРешение : Ограничивать количество ключевых метрик, регулярно оценивать их ценность
# Адаптация для удаленной команды
Использовать те же метрики, но учитывать контекст удаленной работы
Учитывать временные зоны при интерпретации cycle time
Фокусироваться на качестве метрик, а не на их количестве
Использовать CFD для визуализации потока работы
Специфические рекомендации :
Для cycle time: учитывать асинхронную работу и время ожидания из-за разницы во времени
Для lead time: анализировать, где теряется время — в коммуникации или в процессе
Автоматизировать сбор метрик через инструменты (Jira, GitHub, etc.)
Регулярно обсуждать метрики на ретроспективах для совместной интерпретации
Ошибка Почему это плохо Как исправить Velocity = KPI разработчика или команды Команда накручивает numbers, берёт простые задачи, режет техдолг Velocity только для внутреннего прогнозирования, не показывается руководству как KPI Velocity двух разных команд сравнивают Шкалы story points уникальны, сравнение бессмысленно и демотивирует Сравнивать только динамику одной команды в разные периоды Слишком много метрик одновременно Время тратится на сбор данных, а не на их использование 3–4 ключевые метрики максимум, остальные — по необходимости Метрики собирают, но не анализируют Данные есть, но решений и улучшений нет Выделить 15 минут на ретро только для анализа метрик Cycle Time измеряют без исключения ожидания Метрика не показывает эффективность команды, только общее время Разделять: чистое Cycle Time и Lead Time, анализировать оба Падение velocity объясняют «ленью команды» Команда демотивирована, реальные причины не устранены Velocity — симптом. Искать причину: новые люди, техдолг, изменение масштаба задач
# Упражнение 1: Анализ текущих метрикОцените ваши текущие метрики по критериям:
Какие метрики вы измеряете?
Для чего они используются?
Как часто анализируются?
Есть ли анти-паттерны (метрическое давление, цирк)?
# Упражнение 2: План улучшенияВыберите одну метрику и разработайте план ее улучшения:
Какую метрику выберете?
Какие проблемы она выявляет?
Какие действия предпримете?
Как будете измерять успех?