Все статьи
Канбан-команды в SAFe®
Дата: 09.02.2026
Командный Канбан в SAFe® (Scaled Agile Framework®) используется для управления потоком работы на уровне команды в масштабируемой Agile-среде. Он помогает сделать текущую работу видимой, ограничить количество незавершённых задач, выявить узкие места и опереться на фактические данные при улучшении процесса. В статье рассматривается, из каких элементов состоит Канбан в SAFe, как его применять на практике, какие метрики использовать и на что стоит обратить внимание при внедрении.
Говорят, совершенству нет предела. Те, кто работает в Канбане, должны постоянно совершенствовать его, творчески и изобретательно подходя к делу, не допуская застоя на каком-либо этапе.
Содержание
Канбан-команды в SAFe применяют потоковый процесс в ежедневной деятельности в соответствии с циклом итераций ART. Канбан представляет собой стратегию оптимизации потока создания ценности с помощью визуальной системы, основанной на принципе вытягивания, в отличие от подхода, при котором работа навязывается команде. Канбан включает в себя три взаимосвязанных практики:
- Определение и визуализация рабочего процесса.
- Активное управление элементами рабочего процесса.
- Совершенствование рабочего процесса.
Канбан-системы управляют бэклогами и потоком работы на всех уровнях фреймворка. Каждая система отражает уникальный процесс создания ценности, текущий рабочий процесс и возможности команды.
Подробнее
Большинство Agile-команд используют Скрам в качестве основного метода создания ценности. Однако, в некоторых командах работа поступает быстро и неравномерно, а приоритеты часто меняются, что снижает ценность временных затрат на планирование итераций. В таких случаях команды часто выбирают Канбан. Например, системные команды, а также команды, отвечающие за операционную деятельность, поддержку, аппаратное обеспечение и различные бизнес-подразделения, часто считают Канбан более подходящим решением для своих задач.
Кроме того, благодаря прозрачности и непрерывности процессов, которые обеспечивает Канбан, он может применяться в самых разных подразделениях организации. Сегодня многие компании внедряют Канбан, чтобы применять принципы бережливого (Lean-Agile) производства во всех аспектах бизнеса — от маркетинга до финансов, от управления персоналом до юриспруденции, от обеспечения безопасности до соблюдения нормативных требований, от операционной деятельности до Agile-команд и т.д.
Как и все Agile-команды, работающие по фреймворку SAFe, команды, работающие в Канбане, сами определяют, как они организуют свою работу. Они создают и дорабатывают элементы бэклога, обычно в виде историй с критериями приемки, чтобы определить и достичь своих PI-целей. Затем они создают, интегрируют, тестируют, проверяют и внедряют новые фичи, обеспечивая принципы встроенного качества.
Поскольку в командах, работающих в Канбане, как правило, есть все необходимые роли и навыки для разработки и доставки ценности, они работают с минимальным количеством ограничений и зависимостей от других команд. Самоуправляемая кросс-функциональная Канбан-команда создает более приятную, веселую и продуктивную рабочую среду с постоянным общением, конструктивными конфликтами и динамичным взаимодействием.
Канбан-доска
Канбан-система включает в себя Канбан-доску, которая используется для визуализации и управления работой, проходящей через систему. Стандартные элементы Канбан-доски показаны на рисунке 1.
WIP-лимиты – ограничения на максимальное количество элементов для каждого состояния рабочего процесса.
Колонки представляют собой последовательность шагов, каждый из которых соответствует подпроцессу, в совокупности определяющие рабочий процесс команды.
Карточки представляют собой рабочие элементы, такие как Истории и Энейблеры.
Дорожки группируют и выделяют связанные рабочие элементы, определяя рабочий процесс команды. Обычно дорожки используются для разделения работы разных рабочих процессов, межкомандных зависимостей, разных классов обслуживания, например ускоренный или с фиксированной датой исполнения и т.д.
На рисунке 4 показан пример более проработанной Канбан-доски с колонками, которую использует реальная команда.
Канбан-метод
Несмотря на то, что Канбан помогает управлять работой в системе, основанной на потоке, в нем нет четких указаний относительно ролей, обязанностей и событий. SAFe предлагает решение, отраженное на рисунке 2. Каждый элемент Канбан-метода в рамках SAFe описан в следующих разделах.
Бэклог команды
В Бэклоге команды содержится вся предстоящая работа, необходимая для реализации решения. Команды постоянно совершенствуют бэклог, чтобы в нем всегда были Истории, готовые к реализации без значительных рисков и неожиданностей.
Во время PI-планирования команды декомпозируют Фичи на Истории и определяют PI-цели. В бэклоге также содержатся локальные задачи команды (другой новый функционал, устранение дефектов, рефакторинг, технический долг и техническое обслуживание). Эти Истории пополняют бэклог команды для предстоящей итерации. Но поскольку PI-планирование осуществляется на высоком уровне, командам, скорее всего, придется корректировать свои планы по мере уточнения Историй, определения критериев приемки и появления новых фактов. Кроме того, обратная связь от предыдущих итераций, системных демонстраций и взаимодействия с другими командами, позволяют постепенно обновлять бэклог и ход работы.
Планирование
Несмотря на непрерывный поток работы, в Agile ценится планирование, и команды, использующие Канбан, не являются исключением. Многие команды, работающие в Канбане, планируют свою работу на неделю, чтобы координировать ее, пополнять бэклог Историями и устранять зависимости и обязательства, связанные с конкретными датами. Некоторым командам, работающим в Канбане, удобно согласовывать еженедельное планирование в соответствии с каденциями ART. После завершения планирования команда фиксирует запланированную работу на видном месте, например на физической Канбан-доске или в системе управления проектами, например Yandex Tracker. Обычно на еженедельное планирование отводится 60-90 минут.
В рамках планирования Канбан-команды иногда определяют цели итерации, которые дают командам, заинтересованным лицам ART и руководству общий язык для поддержания согласованности, управления зависимостями и внесения необходимых корректировок во время выполнения PI.
Канбан-команды постоянно пополняют бэклог и определяют Истории, которые необходимо завершить в конкретном временном интервале или в рамках ускоренного класса обслуживания. Они также обеспечивают наличие достаточного количества приоритетных элементов бэклога как минимум на одну-две итерации. Это их план и обязательство перед бизнесом.
Поставка
В рамках SAFe команды применяют Канбан в соответствии с каденциями разработки и синхронизации ART. Они, как и другие команды, выпускают релизы по требованию. Каденции и синхронизация способствуют согласованности, управлению зависимостями и быстрым циклам интегрированного обучения (принцип SAFe №4).
Канбан-система визуализирует всю активную и ожидающую выполнения работу, состояния рабочего процесса и WIP-лимиты. Рабочий элемент может быть переведен в определенное состояние только в том случае, если количество элементов, находящихся на данном этапе, меньше установленного WIP-лимита. Некоторые действия, как правило, Сделать и Готово, могут не иметь ограничений. WIP-лимиты определяются и корректируются командой, что позволяет ей быстро адаптироваться к изменениям в процессе разработки сложных систем.
Синхронизация команды
Помимо еженедельного планирования, Канбан-команды координируют свою работу в течение всей недели. Они сами решают, будут ли эти синхронизации основаны на каденциях ART или встречи будут собираться по запросу. Темп и сроки могут существенно различаться в зависимости от этапа разработки. Обычно команды проводят еженедельные синхронизации в середине недели. В это время Канбан-команды обычно обсуждают следующие вопросы:
- обзор хода работы и устранение препятствий;
- коллегиальная оценка и корректировка работ;
- приемка историй;
- обсуждение улучшений в работе команды;
- планирование системной демонстрации;
- отслеживание сроков выполнения обязательств и метрик работы.
В системе с потоковой организацией работы команда может передавать работу на последующие этапы без формальных согласований или утверждений, в соответствии с политиками команды. Поэтому использование методов парного программирования и совместной работы является обычной и неформальной практикой, чтобы лучше обеспечить принципы встроенного качества до развертывания в продуктивной среде.
Демонстрация системы
Как и все Agile-команды в SAFe, Канбан-команды участвуют в системных демонстрациях ART, что является еще одной формой синхронизации внутри команды и по всему ART. Эта синхронизация обеспечивает интеграцию работы команды в Решение и демонстрацию прогресса. Она также способствует сотрудничеству с другими командами и заинтересованными лицами для оценки решения и внесения необходимых корректировок по ходу работы.
Инкремент
Канбан-команды выпускают небольшие части ценности, инкремент на протяжении всего PI. Тем самым показывая, как развивается новая функциональность. Каждый инкремент добавляется к предыдущему и является работоспособным, протестированным и функциональным элементом Решения.
Ретроспектива
Канбан-команды периодически рефлексируют и ищут новые идеи для улучшения своих процессов. Эти улучшения часто приводят к обновлению Канбан-доски, чтобы отразить изменённый процесс. Ретроспективы помогают привить концепцию непрерывного улучшения — одной из ключевых ценностей SAFe, гарантируя, что команда постоянно совершенствуется. Хотя это необязательно, команды могут проводить ретроспективу на каждой итерации, согласованной с ART, или как минимум один раз за PI, обычно непосредственно перед мероприятием ART — Инспекция и Адаптация. Таким образом, знания, полученные на командной ретроспективе, могут помочь в решении проблем во время Инспекции и Адаптации.
Если вы дочитали до этого места, значит, вам интересен полезный контент о современных методах управления. Чтобы узнавать про новые статьи, видео и бесплатные мероприятия, вступайте в сообщество SAFe® Russia.
Роли в Канбан
Хотя Канбан обычно менее конкретен в отношении ролей в команде, SAFe применяет две специальные роли из Скрам — Владельца продукта и Коуча команды.
На практике эти роли оказались одинаково полезными для Agile-команд, которые используют Канбан.
Как и в Скраме, Владелец Продукта является членом Agile-команды, отвечающим за максимизацию ценности, которую команда доставляет и за то, чтобы бэклог команды соответствовал потребностям клиентов и заинтересованных лиц. В рамках расширенной функции управления продуктом Владелец Продукта выступает главным защитником интересов клиента и связующим звеном с бизнес- и технологической стратегией. Эта роль позволяет команде учитывать потребности различных стейкхолдеров и при этом постоянно развивать решение. Он также отвечает за процесс поступления задач в Канбане и расставляет приоритеты в бэклоге команды, чтобы команда создавалa то, что действительно нужно.
Коуч команды — это лидер-слуга и наставник для Agile-команды. Он помогает команде освоить Канбан, практики встроенного качества и Скрама, следя за тем, чтобы соблюдались согласованные Agile-процессы. Также он помогает устранять препятствия и создает условия для повышения эффективности работы команды, непрерывности потока и постоянного улучшения.
Применение Канбан
Эффективные Канбан-системы создаются исходя из потребностей каждой Agile-команды и типа выполняемой работы (например, разработка программного обеспечения, оборудование, маркетинг). В создании Канбан-системы участвует вся Agile-команда при поддержке и наставничестве опытного коуча. В расширенном руководстве SAFe «Применение Канбан в SAFe» рассказывается, как создать систему Канбан и как она интегрируется в SAFe. На рисунке 4 показан пример более проработанной Канбан-системы для команды.
Улучшение и измерение потока
Измерение потока
Канбан-системы предоставляют богатый набор данных, который помогает выявлять узкие места и улучшать поток работы. Существует несколько стандартных метрик для оценки разных аспектов потока. К ним относятся:
- распределение потока;
- скорость потока;
- время потока;
- загрузка потока;
- эффективность потока;
- предсказуемость потока.
Для информации о том, как измерять поток, см. статьи Измеряй и расти и «Поток команды».
Оптимизация потока
Доска Канбан-команды должна развиваться постепенно и постоянно адаптироваться под нужды команды. После того как определены начальный процесс и WIP-лимиты и система начала работать, узкие места станут видимыми, и их можно будет устранить. Другие изменения для оптимизации потока могут включать добавление, объединение или разделение шагов, добавление буферов или переопределение состояний рабочего процесса.
Оценка работы
Из-за быстро меняющегося характера рабочих задач в Канбан обычно меньше внимания уделяется оценке Историй, чем в Скрам. Вместо этого Канбан-команды смотрят на необходимую работу, декомпозируют крупные задачи на более мелкие, если нужно, и продвигают получившуюся работу через Канбан-систему до завершения.
Тем не менее, команды в SAFe всё равно оценивают нагрузку относительно своей ёмкости во время PI-планирования и помогают с оценкой задач из общего бэклога между командами, например, фич и эпиков.
