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

Еще один подход нейтрализации вариативности трудозатрат – это создание разных типов рабочих единиц для разного размера единиц. Для этого можно задать «плавательные дорожки» для единиц каждого размера (типа). WIP-лимиты в этом случае должны задаваться для каждого столбца в каждой дорожке, то есть для каждой ячейки на стене карточек. Поскольку вариативность по каждой дорожке мала (ведь все единицы имеют примерно одинаковый размер), дорожки должны проходить по потоку относительно гладко. Это способ борьбы с вариативностью без применения двухъярусной системы.

Два наиболее очевидных метода визуальной дифференциации карточек на стене – это использование разных цветов и «плавательных дорожек». Однако в крупных проектах у каждой карточки есть три атрибута, о которых необходимо сообщить: это тип единицы работы, уровень иерархии и класс обслуживания. Стоит заметить, что в нашем примере ( рис. 13.2) было принято решение завести разные типы единиц работы для различных иерархических уровней, а также применить и цвета, и «плавательные дорожки» для обозначения самих уровней. То есть для иерархии фактически использовались два метода визуализации, а это обычно приводит к перегрузке.

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

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

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

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

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

Следующий уровень предполагает понимание того, что общие ресурсы не будут доступны по первому требованию. Визуализируется это так: элементы, требующие внимания специалиста (оранжевые карточки), помечаются как блокированные, пока он не начнет активно над ними работать. Это ведет к началу работы над проблемой, которая приводит к высвобождению специалиста, участвующего сразу в нескольких проектах. Кроме того, это сигнал руководству, что доступность данного ресурса может оказаться проблематичной и стать потенциальным бутылочным горлышком.