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

Бессмысленно считать MMR единым элементом, проходящим через канбан-систему. MMR состоит из множества рабочих единиц. Это понятие оправданно с точки зрения операционных издержек релиза, а не организации рабочего потока. В некоторых случаях небольшая, но очень ценная новая функция, вносящая существенные изменения, имеет достаточный экономический смысл, чтобы выпустить ее отдельным релизом. В то же время опыт подсказывает, что «первая MMR всегда большая», поскольку в первый релиз новой системы должны быть включены все необходимые функции для выхода на рынок и вся инфраструктура для их поддержки. Размер MMF (или MMR) может различаться на два-три порядка. Тип рабочей единицы, составные части которой отличаются в тысячу раз, сложно реализовать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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