Дэвид Андерсон - Канбан. Альтернативный путь в Agile

Взяв на вооружение этот двухъярусный подход, мы отделили создание ценности от вариативности размеров и усилий, затрачиваемых на ее создание.

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

Первые команды, использовавшие Канбан в работе над крупными проектами, имели дело с двухуровневыми стенами карточек (пример – на рис. 13.1).

Рис. 13.1. Фотография двухуровневой доски

На этой фотографии крупные требования обозначены зелеными карточками. Они движутся слева направо, переходят в различные состояния: «бэклог», «предложено» (анализ), «в работе» (проектирование и разработка), «устранено» (тестирование) и «закрыто».

Требования в работе показаны в верхней части центрального раздела стены. В свою очередь, они разбиваются на множество более мелких функций, которым соответствуют зеленые карточки. Функции проходят из одного состояния в другое: «предложена» (анализ), «в работе» (проектирование и кодирование), «устранено» (тестирование) и «закрыто».

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

Желтые карточки привязываются к породившим их зеленым: на желтые карточки наклеиваются ярлыки, где указаны ID зеленых.

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

Связь более детализированных желтых карточек с породившими их крупными требованиями очень важна. Кроме того, имеет смысл задать WIP-лимиты на более низком уровне в пределах конкретной кроссфункциональной команды. Чтобы облегчить реализацию этого подхода, некоторые команды внесли новшество в систему стены карточек и ввели «плавательные дорожки».

На рис. 13.2 высокоуровневые требования, которым соответствуют зеленые карточки, проходят через те же состояния – то есть бэклог, «предложено», «в работе», «устранено» и «закрыто». Однако средний раздел отличается по внешнему виду от рис. 13.1. Крупные требования, находящиеся в работе и представленные желтыми карточками, вертикально сгруппированы слева по центру. От каждой из этих зеленых карточек отходит «плавательная дорожка», разделенная на те же состояния, что и у более детализированных желтых функций. Количество «плавательных дорожек» и составляет WIP-лимит для крупных клиентских и рыночных требований, а WIP-лимит для низшего уровня теперь можно задать для каждой «плавательной дорожки» по желанию команд. Столбец справа от вертикальной колонки зеленых требований содержит имена постоянно прикрепленных к ним членов команды. На маленьких оранжевых карточках, прикрепленных к желтым, указаны имена специалистов, работающих сразу над несколькими проектами, например дизайнеров пользовательского интерфейса или архитекторов баз данных.

.

Рис. 13.2. Фотография двухуровневой доски с «плавательными дорожками»

Этот вариант стены карточек с «плавательными дорожками» означает, что клиентскими и рыночными WIP мы управляем вертикально, а WIP для низковариативных функций рассматриваются горизонтально. Такой формат оказался очень популярным и получил широкое распространение.