Agile в цифрах. Можно ли измерить философию?
Философия Agile говорит, что гарант успешности разработки – это коллективная ответственность. Но как крупный бизнес может положиться на философию, принимать решения и видеть результаты?
Как измерить эффективность внедрения agile и что делать с цифрами, KOTELOV спросили у Влада Лазарева – лидера по Agile трансформации в крупном банке. В этой статье собрали метрики, которые реально используют на практике.
Наводим порядок
На сегодняшний день даже в крупных компаниях редко существует единая входная точка для просмотра отчетности по проектам, где высший менеджмент мог бы видеть все показатели эффективности и понять, задан ли правильный вектор развития компании. Да, даже в крупных компаниях бывает такое, что топ-менеджмент изучает десятки экселевских таблиц.
90% руководителей разных звеньев и направлений собирают свои отчеты вручную с помощью выгрузок из нескольких систем и сведения в единый отчет. Это отнимает много времени.
Для быстрого сбора отчетности можно использовать таск-менеджеры, сервис дески, но лучшее решение – это BI-системы, которые формируют отчеты из различных внешних систем посредством запросов. В большинстве случаев – это SQL-источники: RDBMS, DWH и т.п.
Сейчас с рынка ушли основные международные системы, поэтому мы промониторили российские BI-системы и выделили для себя: Visiology, Luxms BI, Форсайт. Хочется отметить, что они неожиданно достойные.
Метрики
Аджайл не только про философию. В нем есть конкретные цифры, на которые можно опираться, проводя трансформацию в компании. Эти метрики есть во фреймворках Scrum, SAFe, LeSS, и также в Kanban-методе.
Выделим 4 блока метрик. Для каждого фреймворка и для каждого бизнеса они разные. Первым делом измеряют командные(процессные) метрики и Time to Market. Ниже написали определения, которые могут показаться слишком академическими, но в аджайле важно правильно определять суть процессов.
Time to Market
Time to Market – Определяется контекстом организации. Обычно это время от момента регистрации запроса в бэклоге до его выполнения.
Те компании, у которых меньше T2M (Time to Market), побеждают.
T2M не рандомная величина, например, был 10 месяцев, а хотим 3. Чтобы понять, до какого значения мы можем его сократить, нужно сделать декомпозицию процессов и посмотреть, на каком этапе есть задержка реализации. Например, разработка может идти хорошо, но процесс сборки релиза занимает очень много времени, и команда не может его выпустить. Когда процесс будет налажен, станет видно, сколько времени высвобождается и насколько можно сократить Time to Market.
По оси Y – количество выполненных работ
По оси X – за какой период времени были разработаны
Уточняющие показатели T2M (из Kanban-метода).
Cycle Time – Определяется контекстом. Локальное время между двумя выбранными этапами разработки.
Customer Lead Time – Время выполнения запроса клиента. Считается от точки принятия обязательств по поставке до завершения всех работ по запросу.
System Lead Time – Системное время производства. Считается от точки принятия обязательств по поставке до выполнения работ командой сервиса.
Wasted Time – время, которое задача проводит в различных очередях, а не непосредственно в работе.
Effectiveness – процент времени, которое тратиться непосредственно на работу с задачей, а не на ожидания в различных очередях.
Throughput – количество задач, которое может выполнять команда в единицу времени (день, неделя, месяц).
Командные метрики (опросы)
Индекс счастья команд. Помогает понимать настроение команды, чтобы можно было вовремя среагировать на настроение и не потерять эффективность работы и сотрудников.
Для того чтобы люди искренне и честно рассказывали о своем настроении, нужна безопасная среда для высказывания. В опросах не должен присутствовать менеджмент. Если руководитель захочет поучаствовать в процессе, будьте уверены, половина команды точно не скажет все, как есть. Тут важно обещание анонимности для опрашиваемых.
В реальности компании зачастую отслеживают участников опроса. Эта не совсем честная игра приносит позитивный эффект: убирает барьер для свободного высказывания и в то же время помогает компаниям выйти на людей, которые нуждаются в поддержке или имеют проблемы.
Один из методов eNPS. Опрос, который проводят раз в спринт или раз в месяц. Его суть в проставлении по десятибалльной шкале уровня удовлетворенности команды. Им тоже нельзя злоупотреблять, но и проводить раз в три месяца рискованно, т.к. можно не успеть среагировать.
Результаты опроса собираются в сводной таблице, где можно увидеть количество детракторов (оценка меньше 6 баллов), нейтралов (7-8 баллов) и промоутеров (9-10 баллов). Оценки ниже 6 говорят о проблемах в команде. Если не проводить работу с этими участниками, то, как правило, они либо начинают демотивировать команду, либо уходят из компании.
Результаты можно вынести на ретроспективу или тет-а-тет с конкретным участником.
В компаниях этим занимаются коучи или ресурсные менеджеры. При общении с участниками команды можно использовать техники обратной связи, например, модель сэндвича.
Календарь niko-niko. Заполняется в разрезе спринта ежедневно. Его суть в проставлении одного из трех смайликов: веселый, нейтральный, грустный. Опрос не анонимный, поэтому важна безопасность.
По динамике можно выявить проблемы команды, например, если команда счастлива, но в разработке есть слабые места, то скорее всего тут проблема с доверием.
Как и в случае с другими мероприятиями, такими как ретроспективы, где членов команды просят сообщать о проблемах с процессами внутри, субъективных чувствах, самоцензура всегда сопряжена с риском. Например, когда члены команды, которые сообщают о плохих днях, обвиняются в “нытье” руководством или товарищами по команде.
Этот метод не рекомендуется применять к командам, которые работают в режиме постоянной нехватки времени, они будут негативно реагировать на ежедневное заполнение календаря.
Командные метрики (процессные)
Процессные метрики показывают, как сейчас у вас выстроены процессы по Agile внутри команды.
При работе в спринтах используют показатель Burndown chart – это диаграмма сгорания задач. По оси Y – оценка сложности задачи, по оси Х – дни недели.
Этот график показывает сгорание(выполнение) работ в рамках спринта. Если график идет вверх, то произошло изменение скоупа спринта. Вброс нового элемента может означать нарушение договоренности или недозагруженность команды. В идеале такого не должно быть. О проблемах в планировании могут говорить изменения в спринте. Этот график в Jira создается автоматически.
Velocity chart – диаграмма производительности. Показывает отношение запланированных сторипоинтов к фактически выполненным. Помогает видеть, насколько команда предсказуема с течением спринтов, насколько она выполняет взятые обязательства.
Со временем показывает, сколько можем запланировать сторипоинтов в спринт. Помогает спрогнозировать емкость спринта для команды.
Стабильность спринтов
Показывает, происходят ли изменения скоупа работ в рамках спринта. Нарушаются ли первичные договоренности (цель спринта).
Категоризация работ
Показывает, какие элементы разрабатываются: новый функционал или исправляются ошибки. Показывает, есть ли тех. долг или рефакторинг.
Влад Лазарев: В моей практике был случай, когда бизнес надавливал на постоянный ввод новых функций, не уделяя время рефакторингу. В итоге упали серверы, и за сутки организация получила убытки в несколько сотен миллионов рублей.
Команда реанимировала систему за 24 часа, еще 3 месяца занималась оптимизацией кода и в итоге снизила нагрузку на ЦП только на 7%.
Оптимальное соотношение в спринте технических и бизнес задач такое:
60% бизнес-задачи (разработка новой функциональности)
20% рефакторинг кода
20% исправление ошибок с прода
Даже если компания не такая огромная, несоблюдение этого соотношения ведет к снижению быстродействия, а в итоге – к ухудшению быстродействия и потере клиентов.
Продуктовые метрики
Чтобы понять, не разрабатываете ли вы бесполезный продукт, используйте продуктовые метрики. Они покажут, пройдено ли MVP, в нужном ли направлении движется разработка и есть ли конечные пользователи. На практике бывает, что команды разрабатывают продукт просто потому, что стоит такая задача, не задаваясь целью сделать полезный продукт для пользователей.
NSM (north star metric, метрика «полярной звезды») – показывает основную ценность продукта для пользователей. Определяют целевое значение до внедрения продукта и в течение разработки измеряют прогресс достижения к целевому значению. Если в течение 3-6 месяцев нет изменений, можно сделать выводы, что продукт развивается в неверном направлении. Рекомендуется снимать показатели раз в месяц.
MAU (Monthly Active Users) – количество уникальных пользователей в месяц. Показывает, есть ли у системы живые пользователи и, как следствие, дает косвенное понимание прохождения MVP. Отслеживается ежемесячно.
Плохие показатели этих метрик сигнализируют, что в разрабатываемом продукте есть проблемы. Не всегда product owner самостоятельно может выявить проблему и первым ее озвучить. Стейкхолдерам важно вовремя выявлять отклонения от курса.
Devops показатели
Понять, насколько эффективно происходит релиз, можно посмотрев девопс показатели.
Автор: Сергей Баранов (ScrumTrek)
Выделим значимые метрики:
Частота поставок. Непрерывность поставок – один из принципов Agile-манифеста.
От частоты поставок зависит количество фич, поставляемых конечному потребителю и напрямую влияет на доходы компании.
Количество ошибок с промышленной среды по итогам релиза. Точечные ошибки могут быть, и скорее всего они будут, это нормально. Проблема в появлении критических и блокирующих ошибок, из-за которых функционал не только не работает, но и блокирует доходы компании. Почему на тесте не отловили ошибку? Не все тестовые сценарии могли покрыть. Не у всех есть автотесты, чтобы при прохождении автоматизированных основных сценариев сработал “датчик”. Не все используют юнит-тесты. В процессе сборки релиза не весь функционал могли отправить в прод, при слиянии веток вовремя не отловить ошибку либо вовсе после релиза затронуть чужой функционал. Решать проблему нужно с максимальным приоритетом, отложив развитие продукта. Благодаря квотированию работ и выделению на работу с ошибками 20% емкости команды, развитие продукта не пострадает. При изначальной экономии времени на исправление ошибок будет гораздо больше проблем.
Заключение: Agile не только про философию. Есть метрики, которые помогают менеджменту крупного бизнеса отслеживать эффективность команд разработки, сокращать Time to Market и выходить на первые позиции на рынке. Метрики подсвечивают проблемные зоны или зоны роста, с помощью них можно понять культуру ведения задач в таск менеджере и выровнять ее. Создается мотивация и команда фокусируется на коллективную ответственность и достижение цели.
