Выводы

• Крупные проекты должны выполняться в соответствии с ключевыми принципами Канбана.

• WIP-лимиты, каденция приоритетов, каденция релизов и классы обслуживания остаются полезными и в крупных проектах.

• Крупные проекты обычно имеют иерархические требования, эти уровни иерархии следует моделировать при помощи типов единиц работы.

• Обычно команды отслеживают два верхних уровня иерархии требований на стене карточек и задают WIP-лимиты на одном или обоих уровнях.

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

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

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

• Чтобы визуализировать оба отслеживаемых уровня требований, потребуется двухуровневая стена карточек.

• Популярный метод демонстрации иерархии и облегчения задания WIP-лимитов – так называемые плавательные дорожки.

• Крупные WIP ограничиваются количеством «плавательных дорожек».

• Детализированные WIP при желании можно ограничить на каждой «плавательной дорожке».

• Как правило, на каждую «плавательную дорожку» назначаются небольшие межфункциональные команды.

• Спрос на общие ресурсы можно визуализировать при помощи небольших стикеров, прикрепляемых к обычным рабочим элементам.

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

• Общие ресурсы должны разработать собственные канбан-системы.

• Сеть канбан-систем для общих ресурсов в портфеле проектов можно считать архитектурой для обслуживания запросов на разработку ПО.