Блог
Канбан команда в SAFe (SAFe Team Kanban)

Канбан команда в SAFe (SAFe Team Kanban)

8 ноября 2022

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

Taiichi Ohno

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

«Команда Канбан» (SAFe Team Kanban) – это Agile метод для организации работы, который используется командами внутри Релизного Поезда Agile (Agile Release Train, ART) для обеспечения непрерывной доставки ценности. Повседневная работа Канбан команд основана на потоке. Они выполняют свою работу в соответствии с каденцией итераций Поезда (ART).

Канбан Метод помогает оптимизировать поток ценности с помощью визуальной системы на основе «вытягивания» (pull) в противовес системы на основе «проталкивания» (push) работы в команды. «Канбан включает в себя следующие три практики, которые работают совместно и однонаправленно (в тандеме) [1]:

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

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

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

Здесь важно понимать разницу в названии методов организации и признаках 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 Team Kanban (рисунок 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] Kanban Guide 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 6.