Команда будет использовать канбан-доску, так же как Scrum-команды – доски задач. Канбан-команда проводит встречи (обычно ежедневные), которые называются «прогулка вдоль канбан-доски» (walking the board). На них обсуждается состояние каждого элемента на доске. Она должна отражать текущее состояние системы: каждый элемент, завершающий текущий этап, должен быть перемещен в следующую колонку. Но если этого еще не сделано, то команда знает, что во время встречи доска будет обновлена.

Важно понимать, что канбан-доска визуализирует основной рабочий процесс и процесс использования. Любые примеры, приведенные здесь и в других текстах (в книге «Канбан. Альтернативный путь в Agile» Дэвида Андерсона), – это лишь примеры из реальных контекстов. Вообще не стоит копировать канбан-доску, лучше разработать свою, изучая собственный рабочий процесс и визуализируя его. Копирование существующего процесса без привязки к конкретному контексту противоречит эволюционному подходу Канбана. Если метод требует начать с того, что сейчас делаете именно вы, то не стоит копировать действия других людей[85].

Вернемся к примеру из главы 8, в котором команда пыталась справиться с очень длительными сроками и разочарованными клиентами. Если вернуться к изначальному описанию команды, то изложение их рабочего процесса, которое менеджер проекта показывал руководству, будет таким:

1. Команда получает запрос от пользователя.

2. Руководитель проекта намечает функционал для следующего релиза.

3. Команда разрабатывает функционал.

4. Команда тестирует функционал.

5. Менеджер проекта проводит приемку.

6. Функционал реализован и включен в следующий релиз.

Пункты в главе 8 – это один из способов поддержания связи в рабочем процессе. И этот пронумерованный список тоже, но визуализация более эффективный инструмент для выполнения этой задачи.

Рисунок 9.2 показывает, что вариант рабочего процесса менеджера проекта, который можно назвать «счастливый путь», выглядит так, как показано на канбан-доске.

Рис. 9.2. Здесь показано, как люди воспринимают Канбан в ходе работы над проектом

Но это не то, что происходит в реальной жизни. В главе 8 команда использовала пять «почему», чтобы узнать больше о рабочих процессах. В дальнейшем список выглядел так:

1. Команда получает запрос от пользователя.

2. Менеджер проекта намечает функции на следующий трехмесячный релиз.

3. Команда собирает функцию.

4. Команда тестирует функцию.

5. Менеджер проекта проверяет прохождение тестирования.

6. Менеджер проекта планирует показ демоверсии высшему руководству.

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