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

Разработка на основе функционала тоже имеет три типа требований: для функций, наборов функций (или заданий) и тематических областей.

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

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

Если есть третий, самый низкий уровень (например, задачи в agile-проектах), то такие задачи обычно не отслеживаются на стене карточек проекта или в канбан-системе, используемой командой. Однако индивидуальные разработчики предпочитают их отслеживать. Так поступают небольшие межфункциональные команды в своей локальной системе. Но не стоит выносить это на общую доску проекта или демонстрировать менеджерам и партнерам по цепочке создания ценности. Причина в том, что самый низкий уровень малоинтересен с точки зрения цепочки создания ценности и общей производительности. Самый низкий уровень обычно сосредоточен на деятельности как таковой, а не на создании пользовательской ценности и функционала.

Сейчас получил распространение вариант Канбана для личного использования, который отстаивают Джим Бенсон и другие эксперты. Личный Канбан используется дома и – на индивидуальном уровне – в офисе или в небольших группах по два-три человека, которые вместе трудятся над одним и тем же набором рабочих единиц. Пока трудно сказать, встроится ли личный Канбан в более широкую отрасль знаний или станет самостоятельной дисциплиной.

Поскольку большая часть Канбан-команд отслеживает только два верхних уровня требований, появилась идея о том, что верхний, наименее детализированный уровень требований обычно описывает какую-либо неделимую единицу ценности, создаваемую для рынка или клиента. Эти эпики, или пользовательские требования, часто писали так, чтобы после реализации их можно было вывести на рынок. Если же продукт уже обслуживался, то запросы можно было обрабатывать и выпускать в индивидуальном порядке. Иногда этот уровень требований в Канбан-сообществе именуется «минимальной коммерчески ценной функцией» (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-лимиты на обоих уровнях. На основании нескольких проектов мы сделали вывод, что оптимальнее всего приставить небольшие межфункциональные команды к каждому высокоуровневому требованию. Эти команды вытягивают все более мелкие и детализированные элементы, относящиеся к крупному требованию, и без задержек проводят их по всей доске, пока требование не закончено и не готово для интеграции или релиза. Затем команда берется за другое крупное требование. При этом всегда остается возможность в зависимости от размера следующего элемента, над которым предстоит работа, добавить людей в команду либо, наоборот, убрать лишних специалистов.

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