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

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

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

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

Рис. 9.16. Когда вы находите удачное значение для WIP-лимита, в столбце больше не хранится работа, а полоски WIP-области на диаграмме не накапливают работу со временем. Как это выглядит на диаграмме? Как вы думаете, будет ли диаграмма CFD визуализировать эту конкретную проблему лучше, чем WIP-область на диаграмме?

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