Все статьи
От задумки до результата с помощью Kanban Программы Agile Release Train
Дата: 14.02.2019
Типовой шаблон Kanban Программы, позволяющий оптимизировать полный жизненный цикл крупных инициатив, от известного эксперта SAFe® (Scaled Agile Framework®) Марка Ричардса.
Введение
Для постоянных читателей этого блога не новость, что я глубоко уверен в полезности Kanban-визуализации на всех уровнях внедрения SAFe® (Scaled Agile Framework®). И если вы читали мой Сериал про Метрики, то у вас, возможно, возник вопрос, как же собирать все эти Метрики Скорости.
Фича — это основная единица «потока небольших порций ценности» в SAFe®, поэтому эффективное применение инструментов Kanban к жизненному циклу фичи исключительно важно для поддержки изучения и улучшения потока ценности Agile Release Train (ART).
Первый шаг для большинства ART — это организация потока определения и подготовки Фич для PI-планирования. Многие ART выходят со своего первого PI-планирования с обещаниями, что в следующий раз точно начнут выявлять и готовить фичи к PI (Program Increment) заранее, но затем внезапно впадают в панику за две недели до начала PI 2. Использование Kanban для визуализации этого процесса исключительно ценно, поскольку помогает создать прозрачность и импульс для решения проблем.
Я отчетливо помню наши дебаты, которые мы вместе с коллегой Эм Кэмпбелл-Прэтти (Em Campbell-Pretty) вели с Дином Леффингвеллом (Dean Leffingwell) и Алексом Якима (Alex Yakyma), про рекомендуемый ими Kanban Программы SAFe®. Это было после нескольких бокалов на SAFe® Leadership Retreat в Шотландии в 2015 году. Изначально они видели задачу Kanban для программы в «доставке фич к PI-планированию», в то время как мы оба чувствовали, что жизненный цикл необходимо расширить вплоть до получения ценности. Отчасти к этому подтолкнуло наше общее убеждение, что Kanban здорово помог в визуализации Scrum-of-Scrums для обеспечения исполнения PI, но больше наше желание оптимизировать полный жизненный цикл «от Идеи до Ценности». Дин согласился с идеей и изменил визуализацию этого во фреймворке (картинку, изображающую бэклог как нечто промежуточное, а не конечное, на самом деле нарисовала Эм на ее iPad прямо в ходе нашего обсуждения).
Хороший Kanban требует определенного уровня детализации, позволяющей вскрывать узкие места, очереди и закономерности по всему жизненному циклу. Модель, представленная в SAFe®, описывает общие этапы жизненного цикла, больше применимые в Kanban Портфеля, а более детальную реализацию необходимо разработать самостоятельно.
За годы работы коучем я спроектировал (и перепроектировал) множество Kanban Программ, поэтому выработал типовой шаблон для старта (см. на картинке ниже). В этой статье я опишу цель и применение каждого столбца в этом шаблоне.
Размышления на тему
Фундаментальным принципом Lean является общая оптимизация потока от идеи до ценности. Поэтому любой по-настоящему ценный Kanban Фич должен покрывать их полный жизненный цикл. В реальности многие ART не контролируют полный цикл, но я считаю, что это не мешает визуализировать и отслеживать весь поток. Короче говоря, не пускайте что-то на самотек просто потому, что вы это не контролируете. Если вы не отслеживаете весь путь фичи до промышленного использования и распространения на рынке, вы упускаете жизненно важную обратную связь.
Этапы Kanban
Воронка (Funnel)
Это входная точка для всех идей новых фич. Они могут приходить сюда как фичи, полученные в ходе декомпозиции на уровне Kanban Эпиков, декомпозиции Возможностей (Capabilities) Value Stream (прим. ред. — начиная с версии SAFe® 4.5 этот уровень называется Large Solution или Solution Train) или просто как независимо выявленные фичи. Или, как говорят в SAFe®: «Все фичи приветствуются в Воронку Фич».
На этом этапе не требуется никаких действий, это просто очередь, в которой (обычно) даже отсутствуют правила исключения из нее.
Описание Фичи (Feature Summary)
На этом этапе мы готовим фичу к приоритизации. Обычно я рекомендую ART использовать Шаблон Описания Фичи на полстраницы или страницу (пример обязательно приведу в одной из будущих статей).
Критерии Перехода (Exit Policies) на следующий этап обычно требуют, чтобы для последующего расчета Стоимости Задержки (Cost of Delay) и расчета WSJF (Weighted Shortest Job First) из описания фичи было понятно следующее:
- Мотивация (корневая проблема или возможность).
- Ожидаемые результаты.
- Ключевые заинтересованные лица или пользователи, которых это затронет.
- Предполагаемые выгоды (согласованные с индикаторами Стоимости Задержки).
- Ключевые зависимости (архитектурные и прочие).
- Грубая оценка размера.
Приоритизация (Prioritization)
Далее в ходе специальной сессии фичи проходят оценку Стоимости Задержки, по ним рассчитывается WSJF, и далее они или отклоняются, или утверждаются для помещения в бэклог.
Критерии Перехода на следующий шаг:
- Согласована изначальная Стоимость Задержки.
- Рассчитан WSJF.
- Решено продолжить работу над фичей.
Бэклог (Backlog)
Это просто очередь. У нас есть описание фичи и рассчитанный WSJF. Фичи упорядочены в бэклоге в соответствии с WSJF, что позволяет исключить чрезмерные затраты на анализ конкретной фичи, пока не подойдет ее очередь. Если применить к этому этапу WIP-ограничение (прим. ред. — Work In Progress limit, ограничение на количество одновременно выполняемой работы), то оно, скорее всего, будет основано на пропускной способности ART и иметь максимальное значение — 2-3 пропускные способности PI.
Критерием Перехода обычно является подтверждение, что Фича выбрана в качестве кандидата на следующий PI, причем был проведен достаточный анализ ключевых зависимостей. По моему опыту большинство команд Продуктового Менеджмента на этом этапе принимают решение осознанно, а не на уровне «давайте вытянем из бэклога то, что готово к реализации».
Кандидат для Следующего PI (Next PI Candidate)
И снова, этот этап — просто очередь. Перемещение из Бэклога на этот этап означает, что Фича может быть вытянута далее в Подготовку.
Здесь обычно нет критериев перехода, но мне нравится ставить общее WIP-ограничение на этот и следующий этап (Подготовка). Логика в том, что обычно WIP-ограничение основано больше на пропускной способности, чем на числе фич, и должно примерно соответствовать пропускной способности ART на один PI.
Подготовка (Preparing)
Здесь мы добавляем Фиче необходимые детали, чтобы ее можно было успешно запланировать. Критерий Перехода по сути — это Критерии Готовности Фичи (Feature Definition of Ready). Обычно они включают в себя:
- Полностью определены Критерии Приемки.
- Команды Разработки определены и в курсе, что они будут задействованы.
- Определены зависимости и достигнуты необходимые внешние согласования.
- Готов верхнеуровневый Архитектурный Анализ.
- Готов верхнеуровневый UX.
- Завершены необходимые технические Spike.
Это такой этап Kanban Фич, который очень вероятно будет разбит на более конкретные стадии при внедрении. Реальность состоит в том, что подготовка фичи требует набора различных действий, и подход очень сильно зависит от контекста. Декомпозиция, которая мне часто помогала, выглядит следующим образом:
- Вовлечение Владельцев Продуктов (Продуктовый Менеджмент вкратце рассказывает о Фиче Владельцам Продуктов, которых она затрагивает, после чего они проводят первичный анализ, уделяя особое вниманием ожидаемым выгодам).
- Продуктовые Сессии (проводятся Владельцами Продуктов с участием команд, которых затрагивает Фича, архитекторов, UX и необходимых экспертов, чтобы исследовать фичу и сформировать предварительные критерии приемки и верхнеуровневые варианты решения).
- Финализация (выполнение требуемых технических spike, оценка архитектурных решений, финализация критериев приемки, корректировка оценок размера фичи и ее выгод).
Запланировано (Planned)
Kanban не подразумевает события по планированию как такового, но по результатам PI-планирования все фичи, которые были включены в план, переносятся из Подготовка в Запланировано.
Этот шаг представляет собой очередь. Присутствие фичи в плане PI не означает, что работа над ней будет вестись с первого дня PI. Мы намеренно вводим его, чтобы добавить точности (особенно учитывая время цикла) следующим этапам. Критериев перехода на следующий этап также обычно нет.
Выполнение (Executing)
Фича переводится на этот этап в тот момент, когда первая команда берет первую историю в Спринт, а завершением работы является реализация/тестирование фичи.
Критерии перехода обычно основываются на завершении всех активностей по реализации/тестированию на уровне историй и готовности к оценке на уровне фич. Понимание подходящих стратегий WIP-ограничения для этого этапа приходит со временем и с опытом. Значение WIP, которые вы первоначально наблюдаете, дает классные инсайты о стратегии согласованности команд и эффективности соблюдения ими стратегии WIP Фич в ходе PI-планирования.
Оценка Фич (Feature Validation)
Зрелые ART могут пропускать этот этап (подразумевая, что зрелость включает также и эффективный DevOps). Однако, пока ART еще не достиг зрелости, действия, выполняемые на этом этапе, выглядят так:
- Сквозное (end-to-end) тестирование на уровне фичи.
- Приемочное тестирование фичи (User Acceptance Test, UAT).
- Проверка соответствия нефункциональным требованиям (NFR, Non-Functional Requirements) на уровне фичи.
Критерии Перехода на следующий этап совпадают с Критериями Готовности Фичи (Feature Definition of Done). Они обычно строятся вокруг готовности фичи к сборке и упаковке на уровне Релиза. Число фич, которые копятся в очередь в переход в статус Готово, может дать инсайты о подходе к выбору размеров пакета для развертывания (время задержки на этапе выявит реальные данные о стоимости задержки, вызванной таким подходом).
Оценка Релиза (Release Validation)
Опять же, зрелые ART могут пропускать этот этап. На пути роста зрелости мы выявляем целый набор действий, сопровождающих финализацию перед развертыванием.
Критерии Перехода совпадают с Критериями Готовности Релиза и могут включать:
- Завершение регрессионного тестирования.
- Завершение оценки NFR на уровне релиза (например, тестирование на проникновение, стресс-тестирование и тестирование на больших объемах).
- Завершение интеграционного тестирования на уровне предприятия.
- Финализация документации о развертывании.
- Получены необходимые разрешения на развертывание и согласовано окно по времени на развертывание.
Группа фич, запланированных к включению в релиз, берется с этапа Оценка Фич, и фичи, которые будут развернуты (в идеале это тот же набор) вместе перейдут в Готово, как только будут выполнены Критерии Перехода.
Развертывание (Deployment)
И еще один этап, подлежащий исключению в будущем. Когда DevOps для ART достигнет зрелости, этот этап будет занимать секунды, но на текущий момент он часто занимает несколько дней. Группа фич, находящихся в Оценке Релиза, одновременно будут вытянуты на этот этап вместе с началом активностей по промышленному развертыванию, и переведены в Готово после завершения проверки после развертывания.
Критерии Перехода на следующий этап основываются на политике компании в части управления развертыванием. У многих моих клиентов они привязаны к успешному завершению Business Verification Testing (BVT) — активности, в которой несколько ключевых экспертов вручную проверяют критические сценарии прежде, чем подтвердить успешное развертывание.
Операционная Готовность (Operational Readiness)
Этот этап покрывает финализацию активностей по операционной готовности. Для достаточно зрелых ART бизнес-подразделения к моменту развертывания уже проведут немалый объем работы, но нас здесь интересует разница между «Фича доступна» и «Фича приносит ценность». Типовые активности на этом этапе во многом зависят от того, является ли контекст решения внешним или внутренним, но могут включать:
- Подготовку и ввод новых регламентов.
- Подготовку и проведение обучения конечных пользователей.
- Подготовку и выполнение маркетинговых активностей.
- Развитие канала продаж.
Критерии Перехода на следующий этап должны должны ориентироваться на первое полноценное промышленное использование в реальном (не смоделированном) контексте.
Оценка Результата (Impact Validation)
Некоторое время назад (надеюсь, не слишком давно) у нашей фичи были определены предполагаемые выгоды. Самое время посмотреть, насколько гипотеза была корректна (это стадии Измерения и Обучения цикла Lean Startup). Я обычно рекомендую ограничить этот этап 3 месяцами. В течение этого времени необходимо отслеживать операционные метрики, которые покажут корреляцию между ожидаемыми и реальными выгодами.
На этом этапе необходимо собирать и регулярно оценивать весь полученный опыт с участием, как минимум Продуктового Менеджмента и Владельцев Продуктов, но также желательно и экспертов (Subject Matter Experts, SME), Release Train Engineer (RTE) и представителей команд. Полученные в ходе него инсайты необходимо документировать и возвращать в качестве обратной связи в Дорожную Карту Программы.
Критерии Перехода на следующий этап должны основываться на завершении сессии оценки того, чему мы научились, и внедрении полученных инсайтов в Дорожную Карту Программы.
Готово (Done)
Чтобы было, за что себя похвалить!
Заключение
Внедренный однажды, Kanban принесет немало пользы. Среди прочего, он может поддерживать:
- Визуализацию и обслуживание Дорожной Карты Программы.
- Управление потоком фич в рамках PI.
- Визуализацию текущего состояния PI для поддержки Scrum-of-Scrums, PO Sync, Гемба для топ-менеджеров и других управленческих активностей.
- Визуализацию и управление (или, как минимум, мониторинг) развертыванием, операционным запуском и этапом оценки результатов в рамках жизненного цикла фичи.
- Организацию общего потока и оценку множества метрик Lead и Cycle time на уровне Фичи.
