Kanban в SAFe

«Канбан – это когда вы строите карту своей работы. Изображенный на карте ландшафт – отражение вашего потока ценности. Поток ценности визуализирует выполнение вашей работы от начала до её завершения.»

Jim Benson, Personal Kanban: Mapping Work Navigating Life

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

Kanban – это система, основанная на потоке. «Поскольку большинство рабочих процессов направлены на оптимизацию способа создания и доставки ценности, стратегия Kanban заключается в том, чтобы оптимизировать эту ценность через улучшение потока. Оптимизация при этом необязательно подразумевает максимизацию. Речь идет о нахождении правильного баланса между эффективностью, результативностью и предсказуемостью в выполнении работы.» — https://kanbanguides.org/english/

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

Канбан Система (Kanban System)

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

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

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

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

Внедрение эффективной Kanban системы, адаптированной под потребности определенной Agile команды, зависит от типа выполняемой работы (например, разработка программного обеспечения, проектирование аппаратного обеспечения, маркетинг), навыках членов команды и роли команды на предприятии.

Лучше всего создавать Канбан систему совместно со всей командой при поддержке опытного коуча, который мог бы фасилитировать процесс со своей стороны.

Принципы внедрения Канбан системы:

• Начните с того, что вы уже делаете сейчас
• Согласитесь на инкрементальные и эволюционные изменения
• Уважайте текущие процессы, роли, обязанности и полномочия
• Поощряйте проявление лидерства на всех уровнях в вашей организации

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

Учитывая эти принципы, начальный этап создания канбан-системы обычно включает шесть ключевых шагов, описанных ниже.

1. Отразите рабочий процесс команды

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

2. Организуйте шаги рабочего процесса

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

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

3. Определите буферные состояния

Добавьте буферные состояния, чтобы лучше справляться с вариативностью в рабочем процессе команды. Такие буферы помогают выявлять узкие места и задержки. Поскольку каждый дополнительный элемент незавершённой работ (WIP) увеличивает общее время выполнения (lead time), начните с небольшого объёма буфера и далее корректируйте лимит в большую или меньшую сторону на основе наблюдений.

Если удастся уменьшить вариативность в размере элементов работы, возможно, получится уменьшить и размер буферов.

4. Определите Политики

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

Ниже приведены некоторые примеры явно задаваемых политик:

• Определение Выполненности (Definition of Done, DoD) для рабочего элемента
• Кто имеет право добавлять, изменять и расставлять приоритеты в беклоге?
• Как обрабатываются срочные запросы?
• Что делать, когда члены команды оказываются заблокированными для выполнения своей работы?
• Кто может переместить элемент на следующую стадию?

Эти примеры не являются исчерпывающими. Тем не менее, они могут помочь командам сформировать свои собственные политики. Регулярно проводите встречи с командой после ключевых этапов (вех), чтобы пересматривать и при необходимости обновлять эти политики.

Просматривая Канбан доску, команда и её заинтересованные лица получают общее понимание рабочего потока, политик и статус НЗР (WIP).

5. Установите исходные ограничения незавершенной работы (WIP limits)

Когда базовая структура Канбан доски готова, следующим шагом будет определение начальных ограничений для незавершенной работы (WIP). Эти ограничения устанавливаются на основе опыта работы команды с текущим процессом и служат первым шагом к управлению объёмом одновременно выполняемой работы. Как правило, WIP-лимиты помогают ускорить поток. Некоторые состояния (например, «Воронка» и «Выполнено») не требуют ограничения по количеству работ.

На рисунке 3 показан пример Канбан доски команды после картирования их рабочего процесса, выстраивания шагов, добавления буферов и установки лимитов незавершённой работы (WIP).

6. Определите классы обслуживания

Классы обслуживания в Kanban выполняют две основные функции:

1. Помогают классифицировать рабочие элементы  по приоритету
2. Позволяют установить отдельные политики для разных типов рабочих элементов.

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

Часто команды начинают с простого набора классов обслуживания, как показано на рисунке 4.

• Стандартный класс. Базовый класс обслуживания, применимый к рабочим элементам, которые не являются срочными, не имеют фиксированных сроков. Такие элементы не должны нарушать ограничения незавершенной работы (НЗР/WIP).
• Ускоренный класс («Срочно»). Этот класс используется для незапланированной, но срочной работы, при задержке которой возможны значительные потери. Эти задачи требуют немедленного внимания, поэтому допускается их взятие в работу вне установленных WIP-ограничений. Чтобы избежать хаоса, команда должна установить политики, ограничивающие использование этого класса — например, не более одного элемента ускоренного класса в системе одновременно. Также может быть введена политика «массированной группировки, роения (swarming)» вокруг срочных элементов, чтобы обеспечить их быстрое перемещение по системе.
• Класс с фиксированной датой. Этот класс применяется к элементам работы, которые необходимо доставить в определенную дату или до неё. Такие элементы должны быть явно обозначены и находиться под активным управлением, чтобы снизить риски срыва сроков. Этот класс обслуживания также помогает гарантировать, что Kanban команды, работающие на основе потока, выполняют свои обязательства по зависимостям с другими командами.

Kanban доска должна развиваться итеративно и постоянно адаптироваться под потребности команды. После того, как исходный процесс и WIP-лимиты определены, команда следует установленным правилам на практике. Через некоторое время команда начинает замечать узкие места. Если проблемные участки не видны — это сигнал к тому, что процесс нужно уточнить или сократить некоторые лимиты WIP, чтобы стало понятно, где именно возникает перегрузка или, наоборот, простой.

Другие изменения для оптимизации потока могут включать слияние или разделение шагов, добавление буферов или пересмотр стадий рабочего процесса.

Связанные Kanban Системы в SAFe

Системы Kanban используются на всех уровнях SAFe, включая конфигурации Портфель (Portfolio), Крупное Решение (Large Solution) и Базовый (Essential) SAFe (Поезд и Команда), как показано на рисунке 5.

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

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

На рисунке 5 показано, как новая работа проходит через различные системы Kanban и беклоги, которые управляют рабочим потоком. Канбан системы помогают быстро перемещать изменения стратегии по потокам создания ценности для команд, которые занимаются разработкой. Таким образом, выполнение выравнивается — и постоянно перестраивается («пере-выравнивается») в соответствии с эволюцией бизнес-стратегии.

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

4 Канбан Системы в SAFe:

Канбан Команды (Team Kanban)

Канбан система Команды содержит пользовательские истории и энейблер истории из Беклога Поезда (ART), а также истории, которые возникают локально из контекста команды. Система Kanban также может включать в себя другие рабочие элементы, представляющие все, что команда должна сделать, чтобы обеспечить развитие своей части системы. Владелец продукта (Product Owner, PO) или другая аналогичная роль управляет и расставляет приоритеты в Канбане Команды и Беклоге Команды.

Канбан Релизного Поезда и Поезда Решения (ART and Solution Train Kanban Systems)

Kanban системы Релизного Поезда (ART) и Поезда Решения (Solution Train, ST) облегчают поток Бизнес Фич, Энейблер Фич и Капабилити (Возможностей) через Конвейер Непрерывной Доставки (Continuous Delivery Pipeline, CDP).

Менеджмент Продукта и Менеджмент Решения определяет приоритеты и управляет Канбан системами Релизных Поездов Agile (Agile Release Train, ART) и Поезда Решения (Solution Train). Фичи существуют в модели Lean UX (процесс бережливого управления созданием UX), включая определение минимальной рыночной фичи (MMF), гипотезы выгоды и критериев приемки. Использование MMF помогает ограничить объем работы и инвестиции, повышает гибкость и обеспечивает быструю обратную связь. Капабилити (возможности) ведут себя так же, как и Фичи. Однако они находятся на более высоком уровне абстракции и поддерживают определение и разработку крупных Решений.

Канбан Портфеля (Portfolio Kanban System)

Канбан Портфеля особенно важен, потому что он помогает выравнивать (согласовывать) стратегию и выполнение, определяя, коммуницируя и управляя выбором крупнейших и наиболее стратегически важных инициатив (эпиков) для Портфеля SAFe. Бережливое Управление Портфелем (Lean Portfolio Management, LPM) использует Канбан систему Портфеля, определяя приоритеты, управляя и проводя мониторинг рабочего потока с помощью мероприятий Стратегического обзора портфеля и Синхронизации портфеля.

Статья подготовлена по материалам Scaled Agile, Inc. и является неофициальным переводом «Applying Kanban in SAFe». Статья обновлена в соответствии с последней версией статьи вендора от 01.03.2023.

Прочитать по теме дополнительно:

Статья «Команда Канбан в SAFe»