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

До сих пор примеры и истории о внедрении Канбана, представленные в этой книге, касались исключительно поддержки программ – небольших системных изменений, выходивших в быстрых и частых релизах. Есть множество систем, которые нуждаются в поддержке, и многие читатели, занимающиеся разработкой ПО, найдут здесь полезные советы и планы действий. В сфере IT важную роль играют также обслуживание и эксплуатация, где тоже распространены системы заданий на краткосрочные работы. Канбан-подход очень полезен и в этом случае. Однако есть и другие отрасли, в которых нормой считается разработка проектов существенного масштаба. Если вы, читая эту книгу, задаетесь вопросом, зачем и как использовать Канбан в работе над крупными проектами и всем портфелем проектов, то надеюсь, глава 5убедила вас: Канбан приводит к значительным положительным культурным сдвигам. Преимущества, которых можно достичь благодаря Канбану, настолько желательны, что нельзя не задуматься над тем, как совместить его с большими проектами.

Крупные проекты сопровождаются заметными проблемами. Многие требования должны быть реализованы и выпущены одновременно. До первого релиза обычно проходит много времени – порой несколько месяцев. Возрастает и число участников команды. Параллельно ведутся работы в самых разных направлениях. Нужно объединить большие куски заданий, хотя не все они имеют отношение к разработке ПО. Например, документацию и дизайн программного пакета нередко требуется интегрировать в итоговую сборку программ до выхода релиза.

Как справиться с этими проблемами?

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

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

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

Вам понадобится также определить типы рабочих единиц для проекта. Во многих крупных проектах есть иерархические требования, нередко даже трех уровней. Требования могут также различаться по типам: пользовательские требования, поступающие со стороны бизнеса, и требования продукта, которые предъявляют команды техников, архитекторов или службы контроля качества. Впоследствии требования иногда делятся на функциональные и нефункциональные (связанные с качеством обслуживания). Даже в рамках гибкой разработки ПО клиент может оформить требования в виде эпиков, которые затем распадаются на пользовательские истории, а иногда и на более низкоуровневые задания или мелкие элементы, так называемые песчинки. Мне доводилось видеть, как эпики раскладывались на архитектурные истории, которые, в свою очередь, делились на пользовательские истории.

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

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

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

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

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

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