Друзья, всем привет!
Ниже вас ждёт перевод статьи Fernando Cuenca «How Agile We Are?». Статья будет полезна CTO, CIO, KMP и KCP, как направление мысли в поиске ответа на вопрос: «Какие метрики можно использовать для оценки эффективности разработки, как IT-сервиса?».
Помнится в 2018-м году Лёша Пименов уже делал перевод этой статьи. К сожалению (или счастью) диапазон проблем, который я решал в тот момент, как консультант, был другим. Поэтому и оригинал, и перевод прошли мимо меня.
Более внимательно я прислушался к этим идеям, когда сам автор – Алексей Жеглов – рассказал нам историю появления этого дешборда на мастер-классе Accredited Kanban Consultant.
Использовать же их на практике мне довелось только сейчас – при разработке сводного дешборда метрик оценки эффективности разработки S7 TechLab.
И хоть в нашем случае мы всё-таки выбрали другой набор метрик на уровне ТехЛаба, в сервисах внутри ТехЛаба, с которыми я работаю, как Канбан-кочу, я использую именно подход, описанный в статье Фернандо.
3 «типичные» метрики «Agile-трансформации»
Большинство организаций, осуществляющих переход к Agile, в конечном счете задаются вопросом «насколько мы Agile?» и хотят, чтобы ответ был подкреплен «объективной» формой измерений, которую можно использовать в различных целях, как то измерение прогресса перехода или даже обоснование его наличия.
Зачастую мы видим, что попытки ответить на этот вопрос сводятся к подсчету запущенных agile-команд, количеству людей, отправленных на agile-обучение, или получению определенных сертификатов. Среди других популярных метрик – акцент на инженерной деятельности (степень автоматизации, покрытие кода или время сборки) или какие-то показатели работы команды (story points или velocity.) Эти метрики очень привлекательны, т.к. их относительно просто фиксировать и отслеживать, но при этом (как я уже писал ранее здесь) они очень мало говорят нам о том, как повлияла на бизнес Agile-трансформация IT-сервиса, который обслуживает этот бизнес, и насколько эффективно он удовлетворяет его нужды?
Клиенто-ориентированный дешборд
Пару лет назад, работая с общим клиентом, Алексей Жеглов предложил альтернативную модель. Его идея была в том, чтобы сместить акцент с внутренних метрик, направленных на команду, на клиенто-ориентированную точку зрения и заменить внутренние метрики действительно важными для клиента показателями.
В то время в моде были «agility-дешборды», и вот однажды Алексей сделал такой набросок:
«Представьте, что у вас есть что-то такое», — сказал он.
Основное свойство этой доски в том, что она предназначена не для команды, а для «оказания сервиса». С точки зрения Потребителей, которых вы обслуживаете, важно то, что их потребности (а зачастую и явные запросы) удовлетворяются в полной мере. Чаще всего это требует участия различных команд и других отдельных лиц. Таким образом гибкость (agility) необходимо измерять именно на этом уровне, через более «системную» призму, охватывающую всех участников, вовлеченных в процесс удовлетворения нужд клиентов от начала до конца.
Второй момент перспективы «оказания сервиса» заключается в том, что единицей измерения для такой доски должна быть некая единица работы, заметная потребителю: такая единица работы, которая попадает в зону взаимодействия клиента и сервиса и которая становится единицей обязательства и предоставления результата. В некотором контексте это могут быть небольшие пользовательские истории, но чаще всего это более масштабный функционал, запросы на изменение или даже целые проекты.
Измерение того, что важно клиентам/заказчикам
«Цель клиента, какой бы они ни была, очень часто связана со сроком реализации и влиянием других событий или упущенной по времени возможности».
«Fit for Purpose», Дэвид Андерсон и Алексей Жеглов, стр. 84.
Когда речь заходит об ожиданиях, нам известно, что самое распространенное ожидание клиентов связано со сроками реализации. В связи с этим неудивительно, что срок реализации Lead Time (иногда часто называется Time to Market, период от начала разработки до выхода на рынок) занимает важное, центральное положение на дешборде.
Здесь важно показать, что ответ на вопрос «как долго это займет?» – не число, а вероятностное распределение: время, прошедшее с момента принятия обязательства до предоставления результата, по схожим типам работы может варьироваться в определенном диапазоне, когда некоторые значения наблюдаются чаще других. «Нам известны силы природы, влияющие на форму этой кривой,» — указал Алексей, «и здесь дело скорее в задержках, чем в прилагаемых усилиях».
Изображая Time to market в качестве кривой (или, скажем, гистограммы), мы можем ответить на вопрос не только «насколько быстро» мы предоставляем сервисы (в среднем), но и «насколько предсказуемо» мы предоставляем результат относительно этого среднего показателя (обозначается формой хвоста, уходящим направо).
Уже много было написано о том, что Agile необязательно значит более короткие сроки реализации. Agile значит более оперативное и ловкое реагирование на изменения в среде. С точки зрения клиента, это воспринимается как способность сервиса выполнять новые запросы при их возникновении и способность клиента чаще получать результаты. На дешборде эти два аспекта представлены циферблатами Replenishment Frequency (частота пополнения) и Release Frequency (частота выпуска версии), показывающими текущую возможность по шкале «ежегодно», «ежеквартально», «ежемесячно», «еженедельно», «ежедневно» и «почасово».
Насколько гибкими вам нужно быть?
Зачастую считают, что переход к Agile должен осуществляться в сторону использования всех технических практик из Agile-арсенала. Agility-дешборд, основанный на метрике «количество команд, занимающихся agility» или «количество «коммитов в мастер» в час», действительно может способствовать такому типу мышления, но реальность такова, что многие agile-практики встречаются очень редко и могут дорого стоить – в то время как agility-дешборд оказания сервиса может помочь перенаправить обсуждение в другое русло.
Основная сила, движущая стратегией перехода к Agile, должна быть связана с глубоким пониманием потребностей клиентов и тем, что заставляет сервис соответствовать целевому назначению. Это, в свою очередь, может направлять стратегию выхода на рынок (go to market), которую затем можно использовать для оценки степени, в которой текущая возможность соответствует нуждам клиентов.
Мы можем представить, что на доске есть «волшебные ползунки», контролирующие практики и существующий процесс, которые выдают показания на циферблатах и графиках выше. Красные отметки на схеме обозначают необходимое на каждом ползунке положение для выработки предполагаемой стратегии выхода на рынок. Затем мы можем видеть, какая регулировка нам нужна по каждому аспекту, двигая ползунки вверх или вниз и таким образом выбирая соответствующие agile-техники и практики для достижения необходимых результатов.
Дополнительная подсказка кроется в штриховке части циферблатов. Она указывает на практики, которыми можно воспользоваться для поддержания разной частоты. Если в данный момент сервис пополняется ежемесячно или ежеквартально, тогда организация может использовать практику “Big Design Up Front” (BDUF); при частоте пополнения на уровне «еженедельно» может быть достаточным внедрение обычной Agile-практики недельного (или два раза в неделю) планирования, но если потребность в частоте пополнения «ежедневная» или «почасовая», тогда могут потребоваться более агрессивные практики планирования “Just In Time” (Точно в срок ). Подобным образом можно поступить и с частотой релизного цикла продукта, при ежемесячном или более редком выпуске можно поддерживать эту скорость без использования практик Непрерывной Интеграции; более частые циклы поставки потребуют реализации CI/CD (практик непрерывной интеграции и непрерывной поставки).
Строим дешборд
Учитывая ее клиенто-ориентированный характер, для создания доски первым вопросом может быть «Кто ваш клиент?» с последующим вопросом «Что вы ему поставляете?». С этой информацией мы можем обратиться к нашему таск-трекеру и извлечь информацию об этих единицах работы для определения Lead Times, Replenishment и Release Frequencies.
Недавно, когда я проводил такой анализ для одного своего клиента, я обнаружил, что рабочей единицей, на которую мы давали обязательство по реализации перед заказчиком, был «Проект» (набор функциональных возможностей, объединенных вместе и реализуемых как одно целое), при этом рабочей единицей процесса разработки была «Фаза» (часть проекта, обычно направленная на логическое подмножество возможностей). Обязательства заключались примерно один раз в год (совпадая с началом финансового года), в результате чего частота пополнения для этого типа работы была ежегодной. Как правило, разработка фаз до готовности к выпуску занимала от 3 до 9 месяцев, но из-за параллельной разработки нескольких фаз, частота выпуска версии могла составлять 1 выпуск каждые 1-2 месяца.
Вопрос, соответствует ли все это целевому назначению для клиентов этой организации, остается открытым: приемлемо ли брать новую работу раз в год? Нормально ли для предприятия ждать 3-9 месяцев, что это обещание хоть частично выполнили? Приемлемо ли для них получать новый, доступный им функционал примерно каждый месяц? Учитывая это, ведение диалога в категориях данных трех метрик определенно более продуктивно, чем попытки получить те же сведения, анализируя количество agile-команд, отсортированных по покрытию кода и сгруппированных по числу отказов сборки в неделю.
Автор перевода: Татьяна К.
Редактор: Игорь Филипьев.
