Разделение поставки ценности и вариативности рабочих единиц

Поскольку б о льшая часть Канбан‑команд отслеживает только два верхних уровня требований, появилась идея о том, что верхний, наименее детализированный уровень требований обычно описывает какую‑либо неделимую единицу ценности, создаваемую для рынка или клиента. Эти эпики, или пользовательские требования, часто писали так, чтобы после реализации их можно было вывести на рынок. Если же продукт уже обслуживался, то запросы можно было обрабатывать и выпускать в индивидуальном порядке. Иногда этот уровень требований в Канбан‑сообществе именуется «минимальной коммерчески ценной функцией» (Minimal Marketable Feature, MMF). Небольшая терминологическая путаница связана с тем, что MMF была определена Денном и Клиланд‑Хуань в книге Software by Numbers, причем их определение не вполне соответствует используемому на практике. Поэтому я использую понятие «минимальный коммерчески ценный релиз» (Minimal Marketable Release, MMR), которым обозначаю ряд функций, воспринимаемых клиентом как единый набор и достаточно полезных, чтобы оправдать издержки релиза.

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

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

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

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

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

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

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

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