Читаем Постигая Agile полностью

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

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

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

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

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

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