Основные метрики ART на старте

Перевод статьи Em Campbell-Pretty Baseline Metrics Before You Start выполнен с разрешения автора.

Вы можете ничего не сделать перед запуском своего Agile Release Train (ART), но нельзя не определить метрики! В какой-то момент в не столь отдаленном будущем вас спросят: почему вы считаете, что ваш Agile Release Train успешен? Для вас ответ может быть очевиден – стало точно лучше. Так было и у меня с моим первым ART. Метрики не были главными индикаторами того, что дела идут лучше, главным было изменение в поведении.

Когда я впервые возглавила отдел разработки программного обеспечения для корпоративных хранилищ данных, каждый день уходил на тушение пожаров, попытки стимулировать свои команды и остановить волну увольнений сотрудников. Я осознала, что SAFe это исправил, когда прекратился вал звонков с жалобами о срыве сроков, а также все больше людей хотели присоединиться к команде, а не покинуть ее! Другим действительно показательным изменением поведения стало то, что наши спонсоры потеряли интерес к проведению ежемесячных управленческих совещаний. Очевидно, если вы выполняете свои обязательства, совещания теряют ценность для руководителей! Помню, самое очевидное заметное изменение, которое вселило уверенность в том, что мы становимся лучше – это поставка работающего программного обеспечения! В контексте моего первого поезда это было не что иное, как чудо!

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

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

Ниже я собрала некоторые метрики, которые мне нравится использовать при запуске Agile Release Train, некоторые из них также описаны как рекомендуемые в статье про метрики от Scaled Agile Inc. (прим. ред. — Метрики в SAFe).

Индекс лояльности сотрудников (eNPS)

NPS (Net Promoter Score) — это измерение лояльности клиента, придуманное Фредом Райхельдом и его коллегами из Bain. Понимая драйверы лояльности клиентов, они определили следующее:

«Очень немногие компании могут достичь или поддерживать высокую лояльность клиентов без лояльных и вовлеченных сотрудников».

Чтобы измерить eNPS (Employee Net Promoter Score) нужно задать вопрос:

“По шкале от 0 до 10 оцените, насколько вероятно, что вы порекомендуете работу в [название ART] своим друзьям? 0 — совсем невероятно, а 10 — очень вероятно”.

Те, кто отвечает 9 или 10, классифицируются как сторонники, те, кто отвечает 7 или 8, классифицируются как нейтральные потребители, а те, кто отвечает 6 или ниже, классифицируются как критики. Оценка eNPS рассчитывается путем вычитания процента критиков из процента сторонников. Ожидается, что eNPS увеличится через некоторое время после запуска вашего ART.

Индекс лояльности заинтересованных лиц (Stakeholder NPS)

Мы используем тот же подход, что и в описании eNPS, но на этот раз вопрос звучит так:

“По шкале от 0 до 10, где 0 — совсем невероятно, а 10 — чрезвычайно вероятно, насколько вероятно, что вы порекомендуете услуги [название ART] своему другу или коллеге?”

Вы также должны отслеживать, что со временем и эта начнет расти.

Время цикла (Cycle Time)

После запуска ART вы сможете посчитать Cycle Time для фичей. Время цикла рассчитывается как общее время нахождения фичи от начала до конца внутри вашего процесса. Когда мы запускаем ART, мы обычно создаем Kanban Программы, чтобы визуализировать поток фичей через ART. Если вы отслеживаете движение объектов через Kanban-систему, значит, у вас есть данные о Cycle Time. Через некоторое время после запуска ART, вы должны заметить снижение метрики Cycle Time.

Определение Cycle Time может быть осложнено, если у вас нет эпиков или фичей во время старта ART. В этом случае я бы посоветовала измерить время цикла проектов или вашего текущего эквивалента проектов. Еще один способ, который я видела — это визуализация потока создания ценности. Это можно сделать очень неформально, взяв карандаш и лист бумаги формата А3 и пройдя процесс, отмечая шаги, время, которое они занимают для выполнения, и время ожидания между каждым шагом. Затем вы можете вернуться к этой карте, периодически обновляя ее. Тренинг SAFe DevOps включается в себя тренировку этого упражнения. В книге Карена Мартина Value Stream Mapping подробно описывается руководство по проведению воркшопа визуализации потока создания ценности.

Частота релизов

Эта метрика показывает, как часто ваш ART доставляет ценность до своих клиентов. Частота релизов определяется как количество в определенный период, 1 раз в год, 2 раза в квартал и т.д. Для большинства традиционных организаций частота релизов продиктована релизными циклами всей компании. Данная метрика со временем должна расти.

Количество дефектов

Это количество дефектов, которые доходят до клиента. Наиболее распространенные подходы — это подсчет количества дефектов за выбранный период времени или приходящихся на один релиз. Со временем эта метрика должна снижаться.

В кодовой базе с большим техническим долгом вы можете обнаружить, что в первых Инкрементах Программы (Program Increment, PI) команды находят больше дефектов, чем обычно. Это обусловлено тем, что команды становятся более дисциплинированными в отношении фиксации дефектов, которые они находят во время работы над новыми фичами. В идеале эти дефекты должны быть немедленно исправлены, но мы считаем, что если дефект требует на устранение значительные усилия, что повлияет на конкретную фичу или цель спринта, над которыми в данный момент работает команда, то командам следует зафиксировать дефект и положить в Бэклог Продукта для приоритизации в будущем. Таким образом, вся команда может увидеть дефект, а Владелец Продукта может принять ответственное решение о его приоритете, сохраняя при этом баланс для установленных PI-целей.

Автоматизация тестирования

Если ваш Agile Release Train производит программное обеспечение, вам стоит определить уровень автоматизации тестирования. Это общее количество автоматизированных тестов в процентах от общего количества тестов (ручных и автоматических). Некоторые организации начинают с нуля, и может потребоваться некоторое время, чтобы начать автоматизацию тестирования, но если оставить метрику в списке показателей, это поможет акцентировать на ней внимание. Конечно, со временем, процент автоматических тестов должен расти.

Процент, кто делает работу и остальных

Еще одна интересная метрика, которую нужно определить и отслеживать — это процент сотрудников, выполняющих работу, по отношению к общему количеству сотрудников в отделе. К первым обычно относят сотрудников, которые исследуют, разрабатывают, тестируют, развертывают (например, члены Agile-команд). Вам стоит ориентироваться, что по мере взросления вашего ART доля специалистов должна расти.

Показатели рынка

Если ваш ART разрабатывает продукт или услугу, которую продает ваша компания, вам стоит определить текущие рыночные показатели этого продукта или услуги. Это может быть объем продаж или доля рынка. На конференции Agile2014 cотрудники TomTom использовали цену акций, чтобы продемонстрировать ценность SAFe: Adopting Scaled Agile Framework (SAFe): The Good, the Bad, and the Ugly.

Некоторые показатели вы не сможете определить до начала работы, но вы можете начать отслеживать, как только начнете выполнять свой первый Инкремент Программы.

Стоимость Story Point

Если не использовать подход SAFe по нормализации оценок перед запуском ART, скорее всего, не получится на старте оценить эту метрику. Но вы можете воспользоваться нормализованной оценкой и после старта, когда уже знаете затраты на ART (прим. ред. — подробнее в статье Стоимость в мире SAFe®).

Практически любую метрику, основанную на затратах, будет сложно доказать, и вас почти наверняка спросят, как вы ее рассчитали. Один из способов, которым я подтвердила свои утверждения относительно снижения стоимости на один Стори Поинт — это триангуляция этих данных, чтобы увидеть, дают ли другие подходы к расчету снижения затрат аналогичные результаты. Один из таких «тестов» состоит в том, чтобы взять «проект» или Эпик, который изначально оценивался с использованием традиционного метода или метода водопада, и посмотреть на фактические затраты после его реализации с использованием SAFe. Хотя это и не идеально, но может помочь подтвердить ваш аргумент о сокращении затрат.

Предсказуемость поставки

В дополнение к метрикам на основе самооценки (прим. ред. — самооценка ART) SAFe предлагает Program Predictability Measure (прим. ред. — метрика предсказуемости программы) как способ измерения гибкости. Лично я рассматриваю это скорее как меру предсказуемости, а не гибкости, но опять же я не верю в попытки измерить гибкость.

Это одна из наиболее часто упускаемых частей SAFe. Чтобы иметь возможность рассчитать метрику предсказуемости поставки, вам нужно зафиксировать бизнес-ценность PI-целей во время PI-планирования. Иногда это пропускается из-за нехватки времени, а иногда организация намеренно пропускает, поскольку это воспринимается как «слишком субъективно». Конечно, это субъективно, но я полагаю, что это смягчается тем, что люди, которые обеспечивают ценность бизнеса на PI-планировании, являются теми же людьми, которые обеспечивают фактическую ценность в рамках Inspect & Adapt (прим. ред. — подробнее в 9-минутном видео: Прогноз и оценка бизнес-ценности в SAFe®).

Другая ловушка, в которую попадают организации, — это изменение целей во время Инкремента Программы, поскольку команда не виновата в том, что «бизнес» изменил свое мнение. Верно! В том, что система непредсказуема, тоже не вина команд! Если вы будете придерживаться целей с PI-планирования, показатели предсказуемости PI будут отражать состояние всей системы: как выполнение командами обязательств, так и приверженность бизнеса процессу. Если вы измените цели, у вас предсказуемость снижается.

Вооружившись всеми вышеперечисленными показателями, я надеюсь, что вы сможете избежать страшных метрик Agile Maturity.

Agility (или Agile-зрелость)

На мой взгляд единственная ценная оценка гибкости команды — это самооценка. Если результаты самооценки станут мерой зрелости, обучающая ценность самооценки будет потеряна. В конце концов, как гласит популярная пословица: «Что измеряется, то и делается». Поэтому, пожалуйста, что бы вы ни делали, не пытайтесь измерить Agile Maturity, оценивая команды. Вместо этого сосредоточьтесь на NPS, Cycle Time, дефектах и автоматизации тестирования. Изменение этих цифр — знак того, что вы движетесь в правильном направлении.