Канбан. Альтернативный путь в Agile - [56]

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

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

В одном крупном проекте каждый крупный рабочий элемент под названием «требование», отслеживаемый при помощи зеленых карточек, распадался в среднем на 21 более мелкую «функцию», которым присваивались желтые карточки. Хотя функции описывались в основном с точки зрения клиентской ценности, анализ показал, что они имеют небольшие и почти одинаковые размеры. Если бы это был agile-проект, его уровни соответствовали бы эпикам (зеленого цвета) и пользовательским историям (желтого цвета).

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

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

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

Двухуровневые стены карточек

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

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

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

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

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

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

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

Введение «плавательных дорожек»

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

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