Как только менеджеры выполняют свое обещание, проводят обзор и расчищают «завалы», работа движется вперед. WIP-лимит заставляет их давать обратную связь гораздо раньше, поэтому команда может немедленно внести необходимые изменения. Если рабочий элемент натыкается на препятствия, то менеджеры узнают об этом в начале проекта, а не в конце. Это наносит меньший вред команде, потому что ей не приходится выполнять много ненужной работы, которая затем может оказаться в колонке «На доработку». Сделанная работа немедленно приобретает ценность, в отличие от той, что находится в колонке «На доработку» до тех пор, пока ею не заинтересуется компания (или пока разозленные клиенты не уйдут к конкуренту).

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

Добавление WIP-лимита устраняет причины перегрузки, среднее время рабочего элемента в системе получается намного короче. Теперь в течение проекта менеджеры несколько раз проведут приемку, что позволит команде раньше внести коррективы. И менеджеры смогут использовать эту информацию для более раннего изменения приоритетов, поэтому ценная работа не пойдет в потери.

Более того, теперь команда и менеджеры могут контролировать длину петли обратной связи. Например, если руководители считают, что информация является ценной, и они могут согласиться уменьшить WIP-лимит до шести элементов, это приведет к более частым встречам и даст команде более раннюю обратную связь.

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

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

Нужно избегать при этом многократной отправки одних и тех же элементов через цикл обратной связи, потому что это засоряет систему. Но Канбан помогает заметить и это. Например, когда менеджеры дают обратную связь команде и просят переделать, работа отправляется назад в бэклог. Члену команды приходится перемещать стикер с задачей в колонку с более ранним этапом. Команда может отслеживать стикеры, которые были смещены назад, если поставит на них точку или любой другой знак – явный показатель того, что петля обратной связи для этой функции будет повторяться. Когда функция возвращается через рабочий процесс, она в итоге снова окажется в столбце «Приемка руководством» и заполнит собой одно место среди WIP-лимитов. Это приводит к эффекту засорения петли обратной связи.

Рис. 9.8. Добавление дополнительных столбцов на канбан-доску – и предотвращение попадания множества стикеров обратно в предыдущие колонки из-за их пробуксовки – дает команде больший контроль над процессом

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

Этот процесс на канбан-доске выглядит длиннее. Но поскольку мы использовали объективные данные, полученные в результате измерения времени на освоение новой продукции и экспериментальные данные с WIP-лимитами, чтобы развивать рабочий процесс, как в нашем примере, то мы можем с уверенностью утверждать, что так действительно быстрее. И мы продолжим проводить измерение времени на освоение новой продукции и визуализировать рабочий процесс, чтобы доказать команде и менеджерам: несмотря на добавление нескольких этапов, производство каждой функции и включение ее в релиз протекают быстрее. Но эти измерения полезны для дальнейшего усовершенствования проекта и убеждения менеджеров в том, что он улучшается, а команде все это, скорее всего, не потребуется. Ее убедят результаты, потому что после устранения неравномерной работы и перегрузок проект явно станет продвигаться быстрее.

Ключевые моменты

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

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

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

Канбан-доска – это способ визуализации рабочего процесса команды.

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

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