Насколько мы Agile?
3 показателя гибкости сервиса поставки
Большинство организаций, переходящих на Agile, в конечном итоге спросят: «А насколько мы Agile?». А также захотят, чтобы ответ был подкреплён какой-то «объективной» формой измерений, и мог быть использован для различных целей, таких как оценка прогресса усилий по трансформации или даже оправдание её существования.
Часто мы видим попытки ответить на этот вопрос путём подсчёта количества запущенных Agile-команд или количества людей, отправленных на Agile-обучение или получивших определённые сертификаты. Другие популярные метрики сосредоточены на инженерной деятельности (такой как степень автоматизации, покрытие кода или время сборки) или на показателях результатов работы команды (таких как стори поинты или скорость). Эти метрики соблазнительны, потому что их относительно просто зафиксировать, но (как я уже писал здесь ранее) они также очень мало говорят нам о влиянии Agile-трансформации на бизнес, который обслуживает IT-организация, или о том, насколько хорошо она удовлетворяет его потребности.
Клиентоориентированный дашборд
Пару лет назад, когда мы работали с общим клиентом, Алексей Жеглов предложил альтернативную модель, чтобы переосмыслить разговор с точки зрения, ориентированности на клиента, избегая внутренних, ориентированных на команду метрик. Заменить их на индикаторы того, что действительно волнует клиентов сервиса поставки.
Метафора «дашборда гибкости» была модной в то время, поэтому однажды Алексей подошёл к доске и нарисовал следующий эскиз:
«Представьте, что у вас может быть что-то подобное», — сказал он.
Первая характеристика этого дашборда заключается в том, что она предназначена не для команды, а для «сервиса поставки»: с точки зрения клиентов, которых вы обслуживаете, важно то, что их потребности (а часто и явные запросы) достаточно удовлетворяются. Чаще всего для этого требуется участие нескольких команд и других лиц, и, следовательно, гибкость необходимо измерять на этом уровне через более «системную» призму, которая охватывает всех участников, задействованных в непрерывном удовлетворении запросов клиентов.
Второй смысл принятия такой точки зрения на «сервис поставки» заключается в том, что единицей измерения для этого дашборда должен быть какой-то «распознаваемый клиентом» рабочий элемент: вид рабочей единицы, которая пересекает границу клиент/сервис и становится единицей обязательства и поставки. В некоторых контекстах это могут быть небольшие истории пользователей, но чаще это будут более крупные функции, запросы на изменения или даже целые проекты.
Измеряем то, что волнует клиентов
«Цель клиентов, какой бы она ни была, очень часто связана с их временной шкалой и воздействием, которое другие события или упущенные возможности оказывают в течении времени» («Fit for Purpose», Дэвид Дж. Андерсон и Алексей Жеглов, стр. 84.)
Когда дело доходит до ожиданий от поставки, мы знаем, что наиболее распространённые ожидания клиентов связаны с её сроками. Поэтому неудивительно, что «Время выполнения заказа» (также называемое во многих контекстах «Time 2 Market») занимает видное, центральное место на дашборде.
Важный аспект, это ответ на вопрос «сколько времени это займет?» — это не число, а распределение вероятностей. То есть время, прошедшее от принятия обязательств до завершения похожих типов работ, будет варьироваться в определённом диапазоне, причём некоторые значения будут наблюдаться чаще, чем другие. «Мы знаем силы природы, которые вносят свой вклад в форму этой кривой», — отметил Алексей, и всё дело в задержках, а не в приложенных усилиях.
Показывая время выхода на рынок в виде кривой (или, возможно, гистограммы), мы можем помочь ответить на вопрос о том, «насколько быстро» мы предоставляем услуги (в среднем), а также «насколько предсказуемо» мы их предоставим около этого среднего значения (определяется формой хвоста распределения справа).
Много было написано о том, что Agile не обязательно означает более быстрые сроки доставки, но способность быстрее и изящнее реагировать на изменения в окружающей среде. С точки зрения клиента, это будет восприниматься как способность сервиса принимать новые запросы, когда они возникают, и способность клиента более часто получать результаты. На дашборде эти два аспекта представлены циферблатами частоты пополнения и выпуска, которые показывают текущие возможности в масштабе времени «Ежегодно», «Ежеквартально», «Ежемесячно», «Еженедельно», «Ежедневно» и «Ежечасно».
Насколько вам нужно быть Agile?
Очень часто предполагается, что «Agile-трансформация» должна двигаться в направлении принятия всех технических практик в инструментарии Agile. «Дашборд гибкости», основанный на таких показателях, как «количество команд, практикующих Agile» или «количество коммитов в мастер в течении часа», действительно может способствовать такому мышлению. Но реальность такова, что многие Agile-подходы не являются тривиальными и для своей реализации могут потребовать значительных затрат. Вместо этого Дашборд гибкости поставки сервиса может помочь направить разговор в другое русло.
Основное усилие, определяющее стратегию перехода на Agile, следует направить на глубокое понимание потребностей клиентов и на то, что делает сервис соответствующим их целям. Это, в свою очередь, может изменять стратегию «выхода на рынок», которая затем может быть использована для оценки степени соответствия текущих возможностей потребностям клиентов.
Мы можем представить себе дашборд с этими «волшебными ползунками», которые управляют инструментами и процессом на месте и производят показания на циферблатах и диаграммах выше. Красные маркеры на рисунке показывают позицию, которая нам нужна на каждом слайдере для выполнения предполагаемой стратегии «выхода на рынок». Так мы можем увидеть, какая корректировка нам нужна по каждому аспекту, перемещая ползунки вверх или вниз и, таким образом, метафорически выбирая соответствующие Agile-подходы и практики для достижения желаемых результатов.
Дополнительная подсказка заключается в заштрихованных областях на циферблатах, которые дают некоторые рекомендации относительно методов, которые можно использовать для поддержки различных частот. Если пополнение заказов в настоящее время происходит, скажем, ежемесячно или ежеквартально, то организация может без последствий обойтись практикой «Масштабное проектирование прежде всего» (Big Design Up Front — BDUF). Для частоты пополнения около отметки «еженедельно» может быть достаточно внедрения общей Agile-практики еженедельного (или двухнедельного) планирования спринта. Но если этот показатель становится «ежедневным» и приближается к «ежечасному», то потребуются более агрессивные методы планирования и пополнения «точно в срок» («Just In Time»). Аналогично и для завершения цикла: когда релизы происходят ежемесячно или реже, то можно поддерживать эту скорость без Непрерывной Интеграции (Continuous Integration — CI); более частые циклы поставки сделают CI/CD необходимостью.
Построение дашборда
Учитывая его клиентоориентированный характер, первым вопросом, который нужно задать, чтобы начать создавать дашборд — «Кто ваш клиент?». А затем «Что вы ему предоставляете?». С этой информацией мы можем обратиться к нашей системе учёта и получить информацию об этих рабочих элементах, чтобы помочь нам определить Сроки выполнения, Частоту Пополнения и Частоту Выпуска.
Недавно, проводя такой анализ для одного из моих клиентов, я обнаружил, что единицей обязательств перед их заказчиками был «Проект» (набор функциональных возможностей, объединённых вместе), но единицей разработки и выпуска была «Этап» (часть проекта, обычно означающая логичные суб-наборы возможностей). Обязательства принимались примерно раз в год для совпадения с началом фискального года, что привело к «ежегодной периодичности пополнения» для этого вида работ. Этап, как правило, имеют срок выполнения от 3 до 9 месяцев, но, запуская несколько из них параллельно, организация может поддерживать частоту в 1 релиз каждые 1−2 месяца.
Жюри все еще не определилось, подходит ли все это для клиентов этой организации: достаточно ли брать новую работу один раз в год? Нормально ли для бизнеса ждать от 3 до 9 месяцев, чтобы получить часть этого обещания? Достаточно ли для них, чтобы новая функциональность была доступна им примерно каждый месяц?
Тем не менее, такой разговор в терминах этих трёх показателей, безусловно, более продуктивен, чем попытка получить такое же понимание, проанализировав количество Agile-команд, отсортированных по охвату кода и сгруппированных по количеству сбоев сборки в неделю. 😉
Перевод статьи Fernando Cuenca, опубликованной на medium.com
Оригинал можно прочитать здесь. Перевод Артур Нек