Канбан предполагает иной тип сделки

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

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

Agile‑управление проектами, однако, не дает таких смелых и четких обещаний. Дата окончания работы – примерно через несколько месяцев – может быть определена, но общий объем никогда не устанавливается. Он может определяться приблизительно, но детали никогда не фиксируются.

Нередко заранее оговаривают бюджет (среднемесячные зарплаты), чтобы привлечь к работе фиксированные ресурсы. Agile‑команда действует итеративно, предоставляя обновления функциональности за время коротких, ограниченных по времени итераций (или спринтов). Обычно они занимают от одной до четырех недель. В начале каждой из этих итераций проводят оценку и планирование, после чего берут обязательства. Часто обозначают и объем, но если команда не может выполнить обязательство в срок, то жертвуют именно объемом, а дата окончания остается неизменной. На итерационном уровне гибкая разработка похожа на традиционное управление проектами. Ключевая разница состоит в договоренности о том, что в случае форс‑мажорных обстоятельств объем будет сокращен. Менеджер проекта традиционного типа имеет в этом случае возможность выбрать, чем пожертвовать – объемом или расписанием, добавить ресурсы или принять смешанное решение.

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

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

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

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

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

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

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

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