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

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

Taiichi Ohno

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Доставка

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

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

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

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

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

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

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

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

Инкремент

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

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

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

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

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

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

Владелец продукта (чаще всего с полной занятостью) понимает потребности и ожидания клиентов и помогает выбирать и определять порядок выполнения элементов работ, над которыми команда будет работать. Они выступают в качестве владельцев «поступления элементов» в Канбан процесс и расставляют приоритеты в беклоге команды, чтобы гарантировать, что команда создает правильный продукт/правильное решение.

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

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

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

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

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

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

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

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

Kanban доска команды должна развиваться итеративно и постоянно адаптироваться в соответствии с потребностями команды. После определения текущего процесса, первоначальной установки ограничений количества незавершенной работы (WIP) и выполнения работы в течение какого-то времени узкие места выстроенной системы становятся видимыми для команды. Если их нет, команда должна продолжить совершенствовать свой процесс и/или уменьшать имеющиеся ограничения незавершенной работы (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»