Kanban в SAFe

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

Jim Benson, Personal Kanban: Mapping Work Navigating Life

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

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

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

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

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

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

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

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

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

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

Следующие принципы помогут командам организовать и наладить работу Канбан (https://kanbanguides.org/english/):

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

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

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

Вначале фасилитатор помогает команде смоделировать текущий рабочий процесс. Важно фиксировать места, где работа передается другим командам, так как здесь может потребоваться создание буферов (буферных состояний) для сглаживания процесса. На рисунке 2 показан типичный поток для команды разработчиков программного обеспечения. Технические и бизнес-команды могут следовать аналогичному процессу. Тем не менее, шаги их процессов должны учитывать тип выполняемой ими работы.

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

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

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

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

4. Создать Политики

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

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

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

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

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

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

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

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

Классы обслуживания в Kanban имеют две основные цели: категоризация рабочих элементов в соответствии с их приоритетом и описание отдельных политик для групп рабочих элементов. Команда соглашается установить и следовать определенной политике выполнения для каждого класса с целью оптимизации потока и ценности. Часто команды начинают с простой группы классов обслуживания, как показано на рисунке 4:

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

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

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

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

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

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

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

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

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

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

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

Поток пользовательских историй и энейблеров обычно функционирует в более широком контексте, создавая решение, которое требует работы нескольких Agile команд и, возможно, совместной работы Релизных Поездов Agile (Agile Release Train, ART) в рамках Поезда Решения (Solution Train).

Канбан Программы и Решения (Program and Solution Kanban Systems)

Kanban системы Программы и Решения облегчают поток Бизнес Фич, Энейблер Фич и Капабилити (Возможностей) через Конвейер Непрерывной Доставки (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»

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

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