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

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

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

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

Так, выходит, канбан не подскажет, как мне реализовать проект?

Не подскажет[83]. Канбан предлагает начать с понимания того, как вы в настоящее время реализуете свои проекты. Это может быть Scrum, XP, «лучше-чем-ничего», эффективный водопадный процесс, неэффективный водопадный процесс или даже беспорядочный метод научного тыка или кодирования «с наскока». Как только вы выясните, каким образом ваша команда создает программное обеспечение, Канбан предложит практики для улучшения.

Если у вас уже есть процесс разработки программного обеспечения, то зачем вам Канбан?

Большинству команд удается что-нибудь поставлять. Вы знаете, сколько усилий тратит команда? Какой ценностью обладает результат их работы? Или он вызывает проблемы и затрудняет поставку ценного программного продукта?

Если есть система – неважно какая, – то большинству такие вопросы могут даже не приходить в голову. Даже если вы используете Scrum или XP, вы можете терять впустую много времени, не подозревая об этом. Привычные проблемы очень трудно обнаружить. Каждый может следовать правилам и делать все верно. Но так же как поведение формируется самой системой, потери складываются из совместной работы многих людей.

Такой пример приведен в главе 8: команда невольно увеличивает производственный цикл, даже если все активно трудятся и никто намеренно не затягивает работу. Но несмотря на это, заказчику кажется, что проект сильно задерживается. Хотя в команде даже не заметили этого, потому что делают все возможное, чтобы выполнить задачу как можно скорее.