Применение Канбан в SAFe®
Дата: 09.02.2026
Практическое руководство по применению Канбан в SAFe® (Scaled Agile Framework®): от понимания потока создания ценности до выстраивания Канбан-систем на всех уровнях фреймворка — от командного до портфельного. В статье объясняется, как с помощью визуализации, ограничений незавершённой работы и чётких политик можно улучшить поток работ и выровнять стратегию с исполнением.
Канбан — это построение карты вашей работы. Изображённый ландшафт — это ваш поток создания ценности. Поток создания ценности наглядно показывает движение работы от её начала до завершения.
Джим Бенсон, Персональный Канбан. Карта работы. Навигатор по жизни
Содержание
Канбан — это Lean-метод управления рабочим процессом, который Agile-команды используют для определения, управления и непрерывного улучшения продуктов и сервисов, создаваемых для клиентов. Этот метод помогает командам визуализировать и лучше понимать свой рабочий процесс, повышать эффективность и непрерывно улучшаться.
Канбан — это система, основанная на потоке. Поскольку большинство рабочих процессов существует для создания и оптимизации ценности, стратегия Канбан заключается в оптимизации ценности через оптимизацию потока. Оптимизация не обязательно означает максимизацию. Оптимизация ценности — это поиск правильного баланса между результативностью, эффективностью и предсказуемостью того, как выполняется работа.
Беспрецедентный уровень прозрачности, который обеспечивает Канбан, приводит к его распространению на разные части организации. Сегодня многие организации внедряют Канбан, чтобы поддержать применение принципов Lean-Agile во всех аспектах бизнеса: от маркетинга до финансов, от управления персоналом до юридической функции, от безопасности и соответствия требованиям до операционной деятельности и Agile-команд — и за их пределами.
В SAFe Канбан-системы управляют бэклогом и потоком работы на каждом уровне фреймворка. Каждая из них отражает уникальный процесс команды по поставке ценности, а также её текущий рабочий процесс и доступную пропускную способность.
Канбан-система
Канбан-система, как правило, характеризуется Канбан-доской, которая включает в себя или ссылается на элементы, показанные на рисунке 1.
WIP-лимиты – ограничения на максимальное количество элементов для каждого состояния рабочего процесса.
Колонки представляют собой последовательность шагов, каждый из которых соответствует подпроцессу, в совокупности определяющие рабочий процесс команды.
Карточки представляют собой рабочие элементы, такие как Истории и Энейблеры.
Дорожки группируют и выделяют связанные рабочие элементы, определяя рабочий процесс команды. Обычно дорожки используются для разделения работы разных рабочих процессов, межкомандных зависимостей, разных классов обслуживания, например ускоренный или с фиксированной датой исполнения и т.д.
Политики определяют, как именно управляется работа: например, критерии входа и выхода при перемещении элемента работы из одного состояния в другое или правила для классов обслуживания.
Если вы дочитали до этого места, значит, вам интересен полезный контент о современных методах управления. Чтобы узнавать про новые статьи, видео и бесплатные мероприятия, вступайте в сообщество SAFe® Russia.
Создание Канбан-системы
Внедрение эффективной Канбан-системы, адаптированной под потребности конкретной Agile-команды, основывается на типе выполняемой работы (например, разработка программного обеспечения, проектирование аппаратных решений, маркетинг), навыках участников команды и роли команды в масштабах предприятия.
Лучше всего выстраивать Канбан-систему с участием всей команды при поддержке и фасилитации опытного коуча. Следующие принципы помогут командам принять Канбан:
- Начните с того, как вы работаете сейчас.
- Договоритесь о движении через постепенные, эволюционные изменения.
- Уважайте текущие процессы, роли, зоны ответственности и должности.
- Поощряйте проявления лидерства на всех уровнях организации.
Первый шаг критически важен для выстраивания Канбан-системы и требует дополнительного пояснения. Метод Канбан не требует изменения существующего рабочего процесса. Такой подход упрощает внедрение, поскольку нет необходимости сразу перестраивать текущие процессы. Канбан опирается на постепенные, эволюционные изменения, основанные на эмпиризме. Команда поэтапно вносит улучшения в процесс.
С учётом этих принципов первоначальный дизайн Канбан-системы, как правило, включает шесть видов деятельности, описанных ниже.
1. Отобразить рабочий процесс команды
Фасилитатор помогает команде отобразить её текущий рабочий процесс как отправную точку. Важно зафиксировать места передачи работы, поскольку они могут стать кандидатами на создание буферных состояний для сглаживания потока работы. На рисунке 2 показан типовой поток работы для команды разработки программного обеспечения. Технические и бизнес-команды могут использовать схожий процесс, однако, шаги процесса должны быть адаптированы с учётом типа выполняемой работы.
2. Упорядочить шаги рабочего процесса
Текущий рабочий процесс задаёт те шаги, которые команда хочет отслеживать в процессе своей работы. После того как команда договорилась о существующем процессе, она может расположить эти шаги на Канбан-доске, при этом они не обязаны полностью совпадать с текущим потоком работы. Например, отдельные шаги могут быть объединены или, наоборот, разделены; также могут быть добавлены буферные или ревью-состояния.
После обзора первоначальной Канбан-доски команда может решить упростить её или, наоборот, добавить дополнительные шаги. Канбан с избыточным количеством шагов становится чрезмерно сложным, тогда как слишком малое их число может скрывать узкие места и этапы, не создающие ценность.
3. Определить буферные состояния
Вводите буферные состояния, чтобы управлять вариативностью рабочего процесса команды. Буферы помогают выявлять узкие места и задержки в системе. Поскольку каждый дополнительный элемент незавершённой работы (Work In Process, WIP) увеличивает сквозной срок поставки, имеет смысл начинать с небольших лимитов и корректировать их в большую или меньшую сторону на основе наблюдений. Снижение вариативности размера элементов работы может позволить уменьшить размер буферов.
4. Сформировать политики
Канбан-доска делает процессы и политики команды явными. Например, политики входа и выхода для каждого состояния проясняют, что именно команда должна выполнить, прежде чем элемент работы (Истории) может быть вытянут в следующее состояние.
Ниже приведены примеры явных политик:
- Критерии готовности (Definition of Done, DoD) для элемента работы.
- Кто может добавлять элементы в бэклог, изменять их и приоритизировать.
- Как обрабатывать срочные, экстренные запросы.
- Что делать, если участники команды заблокированы в выполнении работы.
- Кто имеет право переводить элемент работы в следующие состояния.
Этот список не является исчерпывающим, но даёт примеры политик, на основе которых команды могут сформировать собственные. Важно регулярно возвращаться к этим политикам на встречах команды после ключевых вех, пересматривая и развивая их по мере накопления опыта.
Просматривая Канбан-доску, команда и её заинтересованные лица получают общее понимание рабочего процесса, действующих политик и текущего состояния незавершённой работы (WIP).
5. Назначить начальные WIP-лимиты
На этом этапе базовая структура доски уже готова, и можно определить начальные лимиты незавершённой работы (далее — WIP-лимиты). Эти лимиты основываются на опыте команды работы с текущим процессом и часто становятся первой попыткой ограничить незавершенную работу на каждом шаге для ускорения потока работы. Для некоторых состояний, например, «Воронка» и «Готово» WIP-лимиты, как правило, не требуются.
На рисунке 3 приведён пример рабочего процесса команды, представленного в виде Канбан-доски после отображения процесса, упорядочивания шагов, уточнения потока с помощью буферов и установки WIP-лимитов.
6. Определить классы обслуживания
Классы обслуживания в Канбане имеют две основные цели:
- Классификацию элементов работы в зависимости от их приоритета.
- Возможность задать различные индивидуальные политики для отдельных типов элементов работы.
Команда договаривается установить и соблюдать определённую политику выполнения для каждого класса обслуживания, чтобы оптимизировать поток и создаваемую ценность. Как правило, команды начинают с простого набора классов обслуживания, как показано на рисунке 4.
- Стандартный (Standard). Базовый класс обслуживания, применимый к элементам работы, которые не являются ускоренными и не имеют фиксированной даты поставки. Для таких элементов не допускается нарушение WIP-лимитов.
- Ускоренный (Expedite). Класс обслуживания для неожиданных, но срочных работ с высокой стоимостью задержки, которые требуют немедленного внимания. В результате элементы этого класса могут быть вытянуты в разработку даже с нарушением текущих WIP-лимитов. Поэтому для ускоренных работ у команд должны быть явные ограничивающие политики, например, в системе может находиться только один ускоренный элемент одновременно. Кроме того, команда может установить политику «swarm» — коллективной фокусировки на ускоренном элементе, чтобы обеспечить его максимально быстрое прохождение через систему.
- С фиксированной датой (Fixed Date). Описывает элементы работы, которые должны быть поставлены к определённой дате или не позднее неё. Такие элементы необходимо явно выделять и активно управлять ими для снижения рисков срыва сроков. В частности, этот класс обслуживания помогает Канбан-командам, выполняющим потоковую работу, выполнять обязательства по зависимостям.
Канбан-доска должна развиваться итеративно и постоянно адаптироваться под потребности команды. После определения начального процесса и WIP-лимитов и некоторого времени работы по ним узкие места должны стать заметными. Если этого не происходит, команда уточняет процесс или дополнительно снижает отдельные WIP-лимиты до тех пор, пока не станет очевидно, что какое-либо состояние рабочего процесса перегружено или, наоборот, испытывает дефицит работы. Другие изменения для оптимизации потока могут включать объединение или разделение шагов, добавление буферов или переопределение состояний рабочего процесса.
Связанные Канбан-системы в SAFe
Канбан-системы используются на всех уровнях SAFe, включая портфельный, уровень крупных решений и базовый уровень (ART и команда), как показано на рисунке 5. Каждая Канбан-система имеет ряд общих характеристик, которые помогают улучшать поток создания ценности. В частности, они:
- помогают соотносить спрос с доступной мощностью за счёт использования WIP-лимитов;
- помогают выявлять возможности для непрерывного улучшения за счёт визуализации узких мест на каждом состоянии процесса;
- способствуют поддержанию потока за счёт политик, регулирующих вход и выход элементов работы в каждом состоянии.
На рисунке 5 показано, как новая работа проходит через различные Канбан-системы и бэклоги, которые управляют рабочим процессом. Канбан-системы помогают изменениям стратегии быстро распространяться по потокам создания ценности вплоть до команд, занимающихся реализацией. Таким образом, исполнение выравнивается — и постоянно перевыравнивается — в соответствии с развивающейся бизнес-стратегией.
При этом не вся работа инициируется на портфельном уровне. Часто требуются небольшие локальные изменения, для которых достаточно создания новых Историй, Фичили Энейблеров. Такие локальные инициативы напрямую попадают в соответствующие бэклоги команд, ART или Solution Train.
Канбан-команды
Канбан-система командного бэклога содержит пользовательские истории и истории-энейблеры из бэклога ART, а также истории, возникающие локально в контексте работы команды. Кроме того, она может включать и другие элементы работы, отражающие всё, что команде необходимо выполнить для продвижения своей части системы.
Владелец продукта управляет бэклогом и отвечает за приоритизацию всех этих элементов.
Канбан-системы ART и Solution Train
Канбан-системы ART и Solution Train обеспечивают прохождение бизнес-фич и энейблер-фич, а также Возможностей через непрерывный Конвейер Непрерывной Поставки.
Продуктовый менеджмент и Менеджмент Решения отвечают за приоритизацию и управление Канбан-системами ART и Solution Train. Фичи хорошо вписываются в процессную модель Lean UX, включая определение минимально продаваемой фичи (Minimum Marketable Feature, MMF), гипотезы ценности и критериев приёмки. MMF помогает ограничивать объём работ и инвестиции, повышает гибкость и обеспечивает быстрое получение обратной связи.
Возможности ведут себя аналогично Фичам, но находятся на более высоком уровне абстракции и поддерживают определение и разработку крупных решений.
Канбан-система портфеля
Канбан портфеля имеет критическое значение, поскольку он помогает выровнять стратегию и исполнение за счёт выявления, коммуникации и управления выбором наиболее крупных и стратегически значимых инициатив (Эпиков) для портфеля SAFe.
Lean-управление портфелем (Lean Portfolio Management, LPM) отвечает за работу Канбан-системы портфеля. В рамках этого процесса используются события стратегического обзора портфеля и синхронизации портфеля для приоритизации, управления и мониторинга стратегического потока работ.
