Дэвид Андерсон - Канбан. Альтернативный путь в Agile
Первые команды, использовавшие Канбан в работе над крупными проектами, имели дело с двухуровневыми стенами карточек (пример – на рис. 13.1).
Рис. 13.1. Фотография двухуровневой доски
На этой фотографии крупные требования обозначены зелеными карточками. Они движутся слева направо, переходят в различные состояния: «бэклог», «предложено» (анализ), «в работе» (проектирование и разработка), «устранено» (тестирование) и «закрыто».
Требования в работе показаны в верхней части центрального раздела стены. В свою очередь, они разбиваются на множество более мелких функций, которым соответствуют зеленые карточки. Функции проходят из одного состояния в другое: «предложена» (анализ), «в работе» (проектирование и кодирование), «устранено» (тестирование) и «закрыто».
Состояния, которые проходят функции, напоминают состояния высокоуровневых требований, но это не обязательно: вы можете распределять их как вам удобно. Удобнее всего придерживаться текущего положения дел: не стоит менять процесс, если этого можно избежать.
Желтые карточки привязываются к породившим их зеленым: на желтые карточки наклеиваются ярлыки, где указаны ID зеленых.
В подобных случаях возможно ограничить WIP на обоих иерархических уровнях, но все желтые карточки группируются в один пул. У меня пока не хватает данных по отрасли, чтобы определить, насколько успешна эта стратегия, но в данном случае она не сработала.
Введение «плавательных дорожек»
Связь более детализированных желтых карточек с породившими их крупными требованиями очень важна. Кроме того, имеет смысл задать WIP-лимиты на более низком уровне в пределах конкретной кроссфункциональной команды. Чтобы облегчить реализацию этого подхода, некоторые команды внесли новшество в систему стены карточек и ввели «плавательные дорожки».
На рис. 13.2 высокоуровневые требования, которым соответствуют зеленые карточки, проходят через те же состояния – то есть бэклог, «предложено», «в работе», «устранено» и «закрыто». Однако средний раздел отличается по внешнему виду от рис. 13.1. Крупные требования, находящиеся в работе и представленные желтыми карточками, вертикально сгруппированы слева по центру. От каждой из этих зеленых карточек отходит «плавательная дорожка», разделенная на те же состояния, что и у более детализированных желтых функций. Количество «плавательных дорожек» и составляет WIP-лимит для крупных клиентских и рыночных требований, а WIP-лимит для низшего уровня теперь можно задать для каждой «плавательной дорожки» по желанию команд. Столбец справа от вертикальной колонки зеленых требований содержит имена постоянно прикрепленных к ним членов команды. На маленьких оранжевых карточках, прикрепленных к желтым, указаны имена специалистов, работающих сразу над несколькими проектами, например дизайнеров пользовательского интерфейса или архитекторов баз данных.
.
Рис. 13.2. Фотография двухуровневой доски с «плавательными дорожками»
Этот вариант стены карточек с «плавательными дорожками» означает, что клиентскими и рыночными WIP мы управляем вертикально, а WIP для низковариативных функций рассматриваются горизонтально. Такой формат оказался очень популярным и получил широкое распространение.
Альтернативный подход к борьбе с вариативностью трудозатрат
Еще один подход нейтрализации вариативности трудозатрат – это создание разных типов рабочих единиц для разного размера единиц. Для этого можно задать «плавательные дорожки» для единиц каждого размера (типа). WIP-лимиты в этом случае должны задаваться для каждого столбца в каждой дорожке, то есть для каждой ячейки на стене карточек. Поскольку вариативность по каждой дорожке мала (ведь все единицы имеют примерно одинаковый размер), дорожки должны проходить по потоку относительно гладко. Это способ борьбы с вариативностью без применения двухъярусной системы.
Введение классов обслуживания
Два наиболее очевидных метода визуальной дифференциации карточек на стене – это использование разных цветов и «плавательных дорожек». Однако в крупных проектах у каждой карточки есть три атрибута, о которых необходимо сообщить: это тип единицы работы, уровень иерархии и класс обслуживания. Стоит заметить, что в нашем примере (рис. 13.2) было принято решение завести разные типы единиц работы для различных иерархических уровней, а также применить и цвета, и «плавательные дорожки» для обозначения самих уровней. То есть для иерархии фактически использовались два метода визуализации, а это обычно приводит к перегрузке.
Когда помимо типа и уровня в иерархии требований нужно показывать еще и класс обслуживания, имеет смысл применить разные цвета для различных классов обслуживания. Если типы используются не для привязки к иерархическому уровню, а, например, для отображения ошибок и дефектов или для того, чтобы отнести ценность к критической нагрузке, тогда, возможно, стоит попробовать другой подход – ввести для обозначения типа иконку или стикер, прикрепляемый к карточке, воспользоваться цветом для типа и иконкой либо стикером для класса обслуживания (например, серебряной звездочкой для ускоренного запроса).
Еще проще назначить цвета для различных целей – иерархического уровня, типа и класса обслуживания. Этот подход, при котором цвет не привязан к строго определенному атрибуту, оказался приемлемым для пользователей канбан-системы и очень эффективен с точки зрения доступных вариантов визуализации.
Системная интеграция
В некоторых крупных проектах над разными компонентами системы работает несколько команд, и результаты их деятельности впоследствии требуют интеграции. Часть этих компонентов нуждается в специфическом оборудовании или прошивке либо не поддается современным методикам непрерывной интеграции. Когда появляются компоненты, которые должны быть интегрированы, следует определить интеграционную точку на основании планирования крупных высокоуровневых требований. Такая точка и будет фиксированной датой поставки для сдачи этих взаимозависимых компонентов. Это позволяет каждой команде независимо друг от друга продвигаться вперед по канбан-системе, но при необходимости координировать свои действия в работе над взаимозависимыми элементами. Опоздание со сдачей одного элемента может привести к серьезным отсрочкам в рамках всего проекта. Высокие издержки из-за отсрочки дают основание рассматривать такие случаи как элементы с фиксированной датой поставки.
Управление общими ресурсами
Для крупных проектов и портфелей проектов характерно использование общих ресурсов узких специалистов в таких областях, как, например, архитектура программ и баз данных, управление базами данных, тестирование взаимодействия с пользователем, дизайн пользовательского интерфейса и аудит безопасности программного обеспечения. В Канбане установилось три метода работы с общими ресурсами.
При использовании первого метода к некоторым единицам работы прикрепляются дополнительные, более мелкие оранжевые карточки. На них пишется имя специалиста – например, «Сэнди, архитектор корпоративных данных». Даже при самом низком уровне вмешательства такой простой визуализации работы специалиста, не выделенного специально для этого проекта, достаточно, чтобы скоординировать его деятельность. Если одно и то же имя появляется на нескольких карточках, может возникнуть вопрос, как этот человек собирается одновременно справляться с множеством заданий. Возникает дискуссия, после которой возможна смена тактики (нужно ли, чтобы вся работа проходила через одного человека?) или переход на следующий уровень.
Следующий уровень предполагает понимание того, что общие ресурсы не будут доступны по первому требованию. Визуализируется это так: элементы, требующие внимания специалиста (оранжевые карточки), помечаются как блокированные, пока он не начнет активно над ними работать. Это ведет к началу работы над проблемой, которая приводит к высвобождению специалиста, участвующего сразу в нескольких проектах. Кроме того, это сигнал руководству, что доступность данного ресурса может оказаться проблематичной и стать потенциальным бутылочным горлышком.
Высший уровень управления общими ресурсами – это создание собственной канбан-системы для данного ресурса. Например, собственную канбан-систему может получить архитектура корпоративных данных, тестирование взаимодействия с пользователем, безопасность программ и т. д. Каждая команда или специалист независимо друг от друга анализирует спрос на свою работу и устанавливает типы рабочих единиц на основе источника запроса, а также классы обслуживания на основе приоритетности и требуемого ответа. После анализа спроса устанавливаются правила распределения мощности.
