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.

Рисунок 1. Пример элементов Канбан системы

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

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

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

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

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

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

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

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

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

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

Рисунок 2. Пример текущего рабочего процесса команды разработчиков программного обеспечения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 4. Классы обслуживания на Канбан доске

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

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

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

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

Системы Канбан используются на всех уровнях SAFe: Портфель, Крупное Решение и Базовый (Поезд и Команда), как показано на рисунке 5.

Все эти Канбан системы обладают общими чертами, которые помогают улучшить поток доставки ценности. В частности, они:

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

Рисунок 5. Связанные Kanban системы в SAFe.

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

SAFe не является системой «сверху вниз»: не вся работа поступает из портфеля. Часто возникают локальные изменения, которые требуют лишь добавления новых историй, фич или капабилити (возможностей). В таких случаях локальные элементы сразу попадают в соответствующие беклоги — на уровне команды, ART или Solution Train.

В следующих разделах кратко описаны четыре Канбан системы 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). Команда LPM регулярно проводит мероприятия Стратегический обзор портфеля и Синхронизация портфеля для расстановки приоритетов, управления и координации потока стратегически важных работ.

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

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

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

Беклог Релизного Поезда и Поезда Решения

Беклог Портфеля

«Команда Канбан в SAFe»