Метрики в SAFe

Ниже представлен вольный перевод статьи Metrics — Scaled Agile Framework.

“Самые важные вещи не могут быть измерены. То, что важно в долгосрочной перспективе, не может быть измерено заранее” (c) Эдвардс Деминг

“Работающий продукт — основной показатель прогресса” (c)  Agile-манифеcт

Метрики

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

Благодаря Kanban-методу, фиксированным временным интервалам и быстрой обратной связи Agile гораздо более измерим, чем предшествующая ему водопадная модель разработки. Более того, в Agile-подходе система постоянно изменяется, поэтому наиболее подходящий способ оценки — это демонстрация работающей системы. Непрерывная поставка (Continuous Delivery) и DevOps-практики обогащают Agile полезными процессными метриками. Однако, все метрики, которые описаны ниже, вторичны по отношению к ключевой цели — фокусировке на быстрой поставке ценного продукта.

Метрики важны в контексте всего предприятия, поэтому SAFe предлагает метрики для каждого уровня фреймворка: от уровня всей компании до уровня команды.

Метрики уровня компании

Оценка бизнес-гибкости всей компании

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

На рисунке 1 представлены 15 секторов для оценки.

Рисунок 1. Оценка бизнес-гибкости всей компании

Таблица для оценки построена по 5 ключевым компетенциям SAFe, внутри каждой есть 3 подраздела. Сектор оценивается по шкале от 1 до 10, где каждый диапазон цифр имеет свою метафору: Сидим (1-2), Ползем (3-4), Идем (5-6), Бежим (7-8), Летим (9-10).

Построение этого радара позволяет понять, в каком состоянии компания сейчас и выявить точки роста. Для проработки надо брать топ 2-3 секторов, нуждающихся в улучшении. Также важно понимать взаимосвязь между ними: часто работа в одном секторе может вытянуть и улучшить остальные.

Метрики уровня портфеля

Метрики Lean-портфеля

Краткий набор метрик, приведенный ниже, может быть использован для оценки внутреннего и внешнего прогресса всего портфеля. Следуя принципу простоты из Agile-манифеста таблица 1 предоставляет минимальный список метрик, который может оказаться достаточным для оценки Agile-трансформации.

Таблица 1. Метрики Lean-портфеля

Самооценка команды Lean-управления портфелем

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

Рисунок 2. Радар самооценки портфеля

Откройте таблицу для проведения опроса и построения радара.

Метрики уровня крупных решений

Метрика предсказуемости Solution Train

Метрики предсказуемости (Predictability Measure) поездов (Agile Release Trains, ARTs), участвующих в решении, агрегируются в общую метрику Solution Train Predictability Measure как показано на Рисунке 3.

Рисунок 3. Метрика предсказуемости Solution Train

Метрики результативности Solution Train

Метрики результативности поездов, участвующих в решении, агрегируются в метрики Solution Train, как показано на Рисунке 4.

Рисунок 4. Метрики результативности Solution Train

Метрики уровня программы

Отчет «Прогресс по фичам»

Данный отчет показывает статус по каждой фиче и Enabler в течение PI-интервала.

Он показывает, насколько фича в плане или отстает от него.

График имеет 2 столбца:

• План — показывает общее количество запланированных пользовательских историй внутри фичи.
• Факт — показывает общее количество завершенных пользовательских историй внутри фичи. Цвет сигнализирует о том, успеваем ли мы. Зеленый означает, что текущее состояние фичи находится в 15% допуске относительно плана, красный означает превышение порога 15%.

На Рисунке 5 представлен пример отчета.

Рисунок 5. Отчет о прогрессе фичей: сравнивает план с фактом по каждой фиче внутри PI

График должен подталкивать к обсуждению: как необходимо изменить план, чтобы PI был успешен.

Метрика предсказуемости программы

Это одна из ключевых метрик SAFe.

Метрика предсказуемости команд поезда усредняется по всем командам для того, чтобы определить метрику предсказуемости программы (Program Predictability Measure).

Рисунок 6. Метрика предсказуемости программы показывает точность планирования 2 команд в разрезе PI (пунктирные красная и синяя линии), а также всего поезда/программы (жирная оранжевая линия).

График отображает процент фактически доставленной бизнес-ценности командами и поездом (по оценке представителей бизнеса) от планируемых показателей. Дополнительные цели (stretch goals) не входят в плановую часть расчета (знаменатель), но входят в фактическую часть (числитель).

Для детального изучения данного подхода, смотрите раздел 15 книги Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise.

Метрики продуктивности программы

Конец каждого PI — это наиболее подходящая точка самых важных измерений.

Таблица 2 показывает набор метрик продуктивности программы.

Таблица 2. Метрики поезда

Кумулятивная диаграмма потока

Кумулятивная диаграмма потока (Cumulative Flow Diagram, CFD) показывает количество задач, находившихся в определенном этапе процесса в заданный интервал времени.

Рассмотрим пример типичного процесса уровня программы:

• Воронка (Funnel).
• Анализ (Analyzing).
• Бэклог (Backlog).
• Реализация (Implementing).
• Проверка на тестовом окружении (Validating on Staging).
• Развертывание в промышленной среде (Deploying to Production).
• Выпуск (Releasing).
• Сделано (Done).

Рисунок 7 показывает количество фич в каждом шаге процесса для каждой итерации на интервале трех PI.

Толстые области сигнализируют об узких горлышках потока.

Рисунок 7. Пример кумулятивной диаграммы уровня программы

Самооценка ART

Достижение целей программы — это ключевая ценность SAFe. Agile Release Train (ART) постоянно прикладывает усилия для улучшения своей результативности. Release Train Engineer (RTE) заполняет форму самооценки поезда на границах PI или в любой момент, когда есть возможность остановиться и подумать о точках роста его поезда.

Рисунок 8. Пример радара самооценки поезда ART

Открыть таблицу для проведения опроса и визуализации.

Эффективность конвейера непрерывной поставки

Метрика «Эффективность конвейера непрерывной поставки» сравнивает количество времени, проведенного над реальной работой по процессу (touch time), и количество времени ожидания в процессе (wait time). Часть информации может быть получена из инструментов непрерывной интеграции (Continuous Integration) и непрерывной поставки (Continuous Delivery), другая — должна быть внесена в таблицу вручную.

Часто используется техника создания карты потока создания ценности (Value Stream Mapping) для анализа проблем, обнаруженных сбором данной метрики. С помощью этой техники визуализируется шаги процесса и анализируется потери в потоке, можно быстро выявить точки ускорения вашего потока доставки ценности.

Примечание: время реальной работы (touch time) — это время, когда команды добавляет ценность к своему продукту или услуге. Обычно это время составляет небольшой процент (10-20%) от общего времени производства (cycle time), потому что бОльшая часть времени теряется в очередях (ожиданиях) и тратится на перемещения работы из одного состояния в другое.

Рисунок 9. Пример графика эффективности конвейера непрерывной поставки

Количество развертываний и релизов за интервал времени

Эта метрика демонстрирует, насколько программа продвигается к более частым развертываниям и релизам. Обычно интервалом времени является PI (Program Increment).

Рисунок 10. Количество развертываний и релизов в течение PI

По клику на PI мы можем увеличить график и посмотреть, что происходило внутри PI в разрезе итераций.

Рисунок 11. Количество развертываний и релизов в разрезе итераций

Восстановление в течение времени

Этот отчет показывает количество откатов (как откатов программного кода, так и выключения фичи через механизм feature toggling). Даты развертываний и релизов отображаются на графике в виде вертикальных линий, чтобы видеть их корреляцию с откатами.

Рисунок 12. Восстановление в течение времени

Учет инноваций и опережающие метрики

Одной из целей процесса непрерывной поставки является обеспечение организации возможностью проводить быстрые эксперименты для проверки гипотез. В результате, как минимальная фича, ценная для потребителей (Minimum Marketable Feature, MMF), так и минимально-жизнеспособный продукт (Minimal Viable Product, MVP) должны иметь опережающие метрики, по которым можно оценить прогресс достижения гипотезы.

Таблица 3 показывает метрики сайта SAFe, которые являются опережающими для разработки фреймворка.

Таблица 3. Опережающие метрики учета инноваций с сайта SAFe

Радар DevOps-здоровья

Рисунок показывает 16 секторов для оценки программой своей зрелости. Сектор оценивается по шкале от 1 до 10, где каждый диапазон цифр имеет свою метафору: Сидим (1-2), Ползем (3-4), Идем (5-6), Бежим (7-8), Летим (9-10):

Рисунок 13. Радар DevOps-здоровья

Откройте таблицу для оценки и построения радара.

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

Метрики итерации

Каждая команда собирает метрики, необходимые ей оценки результативности, а также  для оценки улучшений с течением времени. Это происходит во время ретроспективы в конце итерации. Пример метрик итерации представлен в таблице ниже.

PI-отчет о производительности команды

В течение системной демонстрации представители бизнеса оценивают актуальное количество бизнес-ценности, доставленной командой по каждой PI-цели.

Рисунок 14. Фактическая оценка бизнес-ценности в разрезе PI-целей команды

Заслуживающий доверия поезд должен работать на уровне 80-100%. Это позволяет представителям бизнеса опираться на план PI.

Примечания от том, как строится график:

• Плановая бизнес-ценность не включает дополнительные (stretch) цели.
• Фактическая бизнес-ценность включает дополнительные цели.
• Процент достижения = Фактическая бизнес-ценность / Плановая бизнес-ценность.
• Команда может выполнить план по целями больше чем на 100% (если основные и дополнительные цели выполнены).

Сумма данной метрики по всем командам поезда называется метрикой предсказуемости программы (Program Predictability measure).

Самооценка команды

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

Рисунок 15. Радар самооценки команды.

Откройте таблицу для оценки и построения радара.