Метрики в 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. Радар самооценки команды.

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