Канбан команда в SAFe

«Говорят, что улучшение – это постоянный и безграничный процесс. Те, кто работает с Канбаном, должны продолжать улучшать с помощью творческого подхода и находчивости, не позволяя процессу остановиться на каком-то этапе.»

Taiichi Ohno

Что такое «Команда Канбан» в SAFe?

«Команда Канбан» – это метод, который помогает командам фасилитировать поток ценности с помощью: визуализации потока работы, установления ограничений на незавершенную работу (Work in Process (WIP), измерения пропускной способности и постоянных улучшений своего процесса.

Как описывается в Канбан Гайде [1] (https://prokanban.org/the-kanban-guide/), “Канбан включает в себя следующие три практики, которые работают совместно и однонаправленно (в тандеме):

• Определять и визуализировать поток работ,
• Активно управлять элементами в потоке работ,
• Улучшать поток работ.”

В SAFe Канбан системы управляют беклогами и потоками работ на всех уровнях фреймворка. Каждая Канбан система при этом отражает уникальный процесс доставки ценности, текущий состав потока работ и ёмкость для этой команды.

Большинство Agile команд используют SAFe Scrum в качестве основного метода для выстраивания доставки ценности. Но существуют команды, работа в которые поступает в виде быстрого и неравномерного потока с быстро меняющимися приоритетами. В результате снижается ценность детального планирования, являющегося обязательной составляющей SAFe Scrum. В этом случае команды часто выбирают SAFe Team Kanban в качестве своей операционной модели (становятся Канбан командами). Такими командами часто становятся Команды Системы, команды эксплуатации, поддержки, аппаратного обеспечения и некоторые бизнес-команды (такие как маркетинг, продажи, HR).

Здесь важно понимать разницу в названии методов организации и признаках Agile команды. Все команды, работающие в SAFe, если это именно команда, а не разрозненные специалисты, должны быть Agile командами. Фреймворк четко определяет признаки, по которым можно определить, является команда Agile или нет. Далее, в зависимости от своего локального контекста, команда выбирает метод организации своей работы.

В SAFe этих методов два: SAFe Scrum и SAFe Team Kanban. Большинство команд на практике используют Scrum для своей организации, но далеко не для всех случаев этот метод является подходящим. Как сказано выше, как только в силу объективных причин мероприятия планирования по правилам Scrum становятся по большей части бесполезными – стоит задуматься о переходе на SAFe Team Kanban. При этом, если команда использует Scrum для своей организации, фреймворк все равно требует использование Канбан доски как важного инструмента повышения эффективности потока работ.

Таким образом, вне зависимости от выбранного основного метода работы, команда в SAFe всегда должна использовать Канбан доску, но организация взаимодействия вокруг этой доски будет существенно отличаться в зависимости от выбранного метода. Далее в этой статье рассматривается вариант построения работы Agile команды, которая не может использовать SAFe Scrum и использует SAFe Team Kanban.

Алексей Ионов, Executive Lean-Agile коуч, Ионов и Партнеры

Канбан обеспечивает видимость и поток. Это способствует его использованию во многих подразделениях организации. Сегодня многие организации внедряют Канбан, чтобы поддерживать использование принципов Lean-Agile в широком спектре бизнес-деятельности, включающем в себя маркетинг, финансы, HR, юридическую службу, безопасность, соответствие регуляторным требованиям, операционную деятельность, организацию Agile команд и многое другое.

Как и все Agile команды в SAFe, Канбан команды во многом сами определяют, как они управляют своей работой. Они создают и уточняют элементы беклога для определения и достижения целей команды на Инкремент Программы. Элементы беклога обычно представляют собой Истории с критериями приемки. Затем команды разрабатывают, интегрируют, тестируют, проверяют и развертывают новую функциональность, обеспечивая встроенное качество.

Канбан команды обычно имеют все роли и навыки, необходимые для разработки и доставки инкрементов ценности. Такой подход к дизайну команд позволяет им функционировать с минимально возможными ограничениями и минимальными зависимостями с другими командами. Самоуправляемая, кросс-функциональная Канбан команда создает приятную, позитивную и продуктивную рабочую среду с постоянным общением, конструктивным конфликтом и динамичным взаимодействием.

Доска Команды Канбан в SAFe

Для Канбан системы характерно наличие «Канбан доски», с помощью которой команды визуализируют и управляют работами, проходящими через систему. Стандартные элементы Канбан доски показаны на рисунке 1 ниже.

Рисунок 1. Элементы Канбан доски

Элементы Канбан доски для Канбан команды включают в себя:

• Ограничение незавершенной работы (НЗР, Work in Process, WIP) устанавливает максимальное количество элементов, которые могут находиться на определенном шаге (стадии, состоянии) потока работ.
• Столбец (Column) представляет собой шаг, требующий произвести определенные действия. Последовательность и состав столбцов отражает набор действий, составляющих поток работ команды.
• Карточки (Cards) являются отдельными элементами работ. Как правило карточка визуализирует Историю или Энейблер
• Дорожки (Swimlanes) группируют и выделяют связанные элементы работ для дополнительного уточнения особенностей потока работ команды. Некоторые варианты типичного использования дорожек: разделение элементов работ (карточек) для разных классов обслуживания, выделение карточек с межкомандными зависимостями, отношение карточек к фичам и многое другое.
• Политики (Policies) содержат правила управления работой. Политики часто содержат критерии выхода или входа для перемещения рабочего элемента из одного столбца в другой, установки для использования различных классов обслуживания (дорожек)

На рисунке 4 приведен пример более детально разработанной Канбан системы со столбцами (шагами), используемыми реальной командой.

Метод «SAFe Команда Канбан» (SAFe Team Kanban)

Канбан метод предоставляет руководство по управлению работой в системе, основанной на потоке. При этом он не дает точных формулировок в отношении ролей, обязанностей и событий, которые команды используют при применении Канбан (Kanban) в качестве своей основной Agile практики.

Рисунок 2 показывает, как SAFe решает эту проблему. Каждый элемент метода SAFe Команда Канбан описан в следующих разделах этой статьи.

Рисунок 2. Обзор метода SAFe Team Kanban

Беклог Команды

Беклог команды содержит всю входящую работу, которую команде необходимо выполнить для продолжения развития решения. Команды постоянно уточняют беклог, чтобы гарантировать, что в нем всегда есть истории, которые можно взять в разработку без значительного риска или сюрпризов.

В течение мероприятия «PI Планирование» команды декомпозируют Фичи на истории и размещают истории в своем беклоге, а также формулируют высокоуровневые ожидаемые результаты на Интервал Планирования (PI Цели, PI Objectives) для своей команды. Локальные потребности команды (прочая новая функциональность, дефекты, рефакторинг, технический долг и техническое обслуживание) также находятся в беклоге. Истории, обсуждаемые на PI Планировании, «загружаются» в беклог команды на предстоящий Интервал Планирования (PI).

PI Планирование – это высокоуровневое мероприятие, поэтому команды как правило в дальнейшем корректируют свои планы (состав и содержание историй) по мере уточнения историй, установления критериев приемки и появления других новых фактов. Кроме того, команды непрерывно, методом набегающей волны получают обратную связь по результатам предыдущих инкрементов, Демонстрации Системы и от других команд, с которыми они взаимодействуют. На основе всех этих данных команды вносят обновления в беклог и поток работы.

Планирование

Хотя поток работы является непрерывным, планирование играет важную роль в Agile, и команды Kanban не являются исключением. Многие Канбан команды планируют еженедельно, чтобы координировать свою работу, добавлять и обновлять истории в беклоге, устранять зависимости и выполнять обязательства с фиксированной датой. Также многие Канбан команды выравнивают свое еженедельное планирование с каденцией итераций Релизного Поезда (Agile Release Train). После завершения планирования команда фиксирует запланированную работу на видном месте, таком как физическая Канбан доска или онлайн Agile инструменты управления разработкой. Еженедельное планирование для Канбан команды обычно занимает 60-90 минут.

Доставка

В SAFe Канбан команды выполняют работу в соответствии с каденцией разработки и синхронизации Релизного Поезда (Agile Release Train, ART). Канбан команды, также как и другие команды, выпускают по требованию. Это облегчает выравнивание (согласованность понимания, планов и действий), управление зависимостями и обеспечивает быстрые интегрированные циклы обучения (принцип SAFe#4) в рамках всего Agile Release Train.

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

Синхронизация Команды

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

• Как работа «течет в потоке» и какие существуют препятствия и как их устранить
• Рассмотрение коллегами внутри команды незавершенной работы (WIP) и корректировка предстоящих планов
• Рассмотрение и принятие историй с отражением результата на доске
• Обсуждение улучшений процесса команды
• Планирование подготовки к демонстрациям системы, которые регулярно проходят в рамках Интервала Планирования (PI)
• Мониторинг работы (карточек) с фиксированной датой выполнения (находящихся в соответствующем классе обслуживания/дорожке – см. выше) и метрик потока

В системе, основанной на потоке, команда может выпустить работу на более поздних стадиях без формальных подписаний или согласований, в соответствии с политиками команды. Поэтому для встраивания качества сразу, еще до развертывания команды должны активно применять практики парной работы (pairing) и «роения» (swarming).

Демонстрации Системы

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

Инкремент

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

Ретроспектива

Канбан Команды регулярно обсуждают текущий процесс и выявляют новые идеи для его улучшения. Эти улучшения часто приводят к обновлению Канбан доски для отражения пересмотренного процесса. Ретроспективы помогает привить концепцию неустанных улучшений. Неустанные Улучшения — одна из ключевых ценностей SAFe, которая способствует постоянному совершенствованию команды. Команды проводят ретроспективы в конце каждой итерации, а в конце Интервала Планирования чаще всего это мероприятие проводится до мероприятия Инспект-Адапт всего поезда (ART Inspect & Adapt, I&A). В этом случае знания, полученные на ретроспективе, поступают в числе других на Мастерскую Решения Проблем (Problem Solving Workshop) в рамках Инспект-Адапт Релизного Поезда.

Роли в Канбане

В то время как Kanban менее четко определяет роли в команде, SAFe применяет две специальные роли Scrum команды. Это роли Владельца Продукта и Скрам Мастера / Коуча Команды. На практике эти две специальные роли оказались одинаково полезными и для Канбан команд в SAFe (рисунок 3).

Рисунок 3. Роли в методе «SAFe Команда Канбан»

Как и в случае со Scrum, Владелец Продукта является членом Agile команды, который отвечает за максимизацию ценности, доставляемой командой, и обеспечивает, что беклог команды соответствует потребностям клиентов и заинтересованных лиц организации. Владелец Продукта входит в расширенную команду по управлению продуктом. В своей команде он/она представляет интересы клиентов и связывает бизнес-и технологическую стратегии. Эта роль помогает команде уравновешивать потребности нескольких заинтересованных лиц в процессе непрерывного развития решения. Они выступают в качестве владельцев «поступления элементов» в Канбан процесс и расставляют приоритеты в беклоге команды, чтобы гарантировать, что команда создает правильный продукт/правильное решение.

SAFe Скрам Мастер / Коуч Команды является лидером-слугой и коучем для Agile команды. Они помогают обучать команду практикам Канбан, Встраивания Качества и SAFe Scrum, обеспечивая соблюдение принятых в организации Agile процессов. Скрам Мастера / Коучи Команд помогают устранять препятствия на пути создания решения и создают условия для высокопроизводительной командной динамики, непрерывного потока и неустанных улучшений.

Создание Канбан команды

Внедрение эффективной Канбан системы должно основываться на типе работы, выполняемой командой (например: разработка программного обеспечения, аппаратное обеспечение, маркетинг) и потребностях каждой конкретной Agile-команды. Для создания Канбан системы команды лучше всего привлекать всю Agile-команду, которую направляет и фасилитирует опытный коуч. В дополнительной, более подробной статье «Применение Kanban в SAFe» описывается, как создать Kanban систему, а также как Kanban системы связаны между собой в SAFe. Ниже на рисунке 4 показан вариант более детально проработанной Канбан системы команды.

Рисунок 4. Пример Канбан системы команды

Улучшение и измерение потока

Измерение Потока

Kanban системы предоставляют богатый набор данных, которые могут выявлять узкие места и улучшать поток. Существует несколько стандартных метрик, которые могут измерять различные аспекты потока. К ним относятся: распределение потока, скорость потока, время потока, загрузка потока, эффективность потока и предсказуемость потока (более подробно можно прочитать в соответствующей статье «Метрики в SAFe»).

Оптимизация потока

Kanban доска команды должна развиваться итеративно и постоянно адаптироваться в соответствии с потребностями команды. После определения текущего процесса, первоначальной установки ограничений количества незавершенной работы (WIP) и выполнения работы в течение какого-то времени узкие места выстроенной системы становятся видимыми для команды. Для оптимизации потока команды могут проводить и другие изменения системы, такие как слияние или разделение шагов (столбцов), добавление буферов или уточнение набора шагов рабочего процесса.

Измерение работы

Состав элементов работ для Канбан команд обычно достаточно быстро меняется, поэтому в Канбан командах как правило меньше внимания уделяется оценке, чем в Scrum командах. Вместо этого Kanban команды в первую очередь смотрят на то, какую работу нужно выполнять раньше, приводят элементы работ к нужному размеру, разделяя, где это необходимо, большие на более мелкие, и проводят получившиеся элементы через Канбан систему до их выполнения.

Тем не менее, SAFe команды измеряют соотношение потребностей и ёмкости для своих команд во время мероприятия «PI Планирование». Также Канбан команды вносят свой вклад в оценки с помощью сторипоинтов для более крупных элементов беклога, над которыми работают сразу несколько команд (Фичи и Эпики).

Подробнее:

[1] https://prokanban.org/the-kanban-guide/

[2] Anderson, David J. Kanban: Successful Evolutionary Change for Your Technology Business. Sequim, Washington: Blue Hole Press, 2010. Last update: 26 July 2022

Статья подготовлена по материалам Scaled Agile, Inc. и не является официальным переводом.

Дополнительно почитать:

Статья «Применение Канбан в SAFe»

Статья «Метрики в SAFe»

Статья «Мероприятия Scaled Agile Framework»

Статья «SAFe ScrumXP»