После введения WIP-лимита (и, что не менее важно, согласия на его поддержание) дополнительные просьбы по-прежнему будут появляться, но теперь команда не обязана выполнять всю незапланированную работу. Вместо этого из новых задач формируется очередь. Давление на команду уменьшается, потому что объем работ будет ограничен и не будет накапливаться. Она может управлять потоком (возможно, используя CFD), так как знает, что WIP-лимит гарантирует необходимое время.

Именно поэтому многие канбан-команды вводят WIP-лимиты в каждом столбце канбан-доски.

Это помогает команде контролировать поток на каждом шаге разработки. Даже для столбца «Готово к выпуску» тоже есть WIP-лимит. Если выполненной работы накапливается слишком много, то команда может заниматься другими делами, чтобы подготовиться к следующему релизу, – и теперь она располагает большим объемом информации, чтобы отрегулировать ритмичность поставок в будущем за счет сокращения времени между релизами.

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

Рис. 9.17. Введение WIP-лимитов в каждом столбце канбан-доски помогает команде максимизировать поток на протяжении всего проекта

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

Сделайте правила явными, чтобы все понимали их одинаково

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