Дальнейшая цель этой книги – помочь понять, как использовать канбан-системы в разработке ПО, и научить вас внедрять такие системы, чтобы достичь обещанных выгод вместе с вашей командой.

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

1. Визуализация рабочего потока.

2. Ограничение количества незавершенных задач.

3. Измерения и управление потоком.

4. Формальные политики процессов.

5. Использование моделей[5] для оценки возможностей совершенствования.

В реализациях Канбана мы ожидаем увидеть появление новых привычек и осознания некоторых правил, список которых постоянно растет. Некоторые из них (или даже все) есть в большинстве последних реализаций. Так, все они присутствовали в Corbis за 2007 год. Мы полагаем, что этот список будет расти, когда мы больше узнаем о влиянии Канбана на организации.

• Процессы уникальны для каждого проекта или потока создания ценности.

• Разделенные каденции (или разработка, не привязанная к единому итерационному циклу).

• Рабочее расписание определяется стоимостью задержки.

• Оптимизация поставки ценности с помощью классов обслуживания.

• Управление рисками основывается на емкости производственной системы.

• Терпимость к экспериментам в процессе.

• Управление на основании количественных показателей

• Вирусное распространение (Канбана) по организации.

• Слияние небольших команд для создания единых трудовых центров.

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

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

В ранние годы гибкой разработки ПО лидеры сообщества нередко не понимали, почему их методы работали. Мы говорили об «экосистемах»{10} и советовали новичкам внедрять все практики – иначе решение не сработает. Некоторые компании опубликовали модели agile-зрелости, где делались попытки оценки усвоения практик. В Scrum-сообществе существует опробованный на практике тест, который часто называют «тестом Nokia»{11}.

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