Постигая Agile

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

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

Именно поэтому многие люди с удивлением реагируют на то, что их руководитель согласился на WIP-лимит: они испытывают облегчение.

До введения WIP-лимита всем казалось, что дополнительная работа «просачивается» в спринт, и команда вынуждена была полагаться на временной резерв, чтобы ее выполнить. Она всегда начинала спринт при условии, что определено только 70 % работы, потому что нетерпеливые руководители и пользователи будут искать возможность втиснуть в последнюю минуту еще 30 % (а то и все 40 % или даже больше) изменений и срочных просьб.

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

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

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

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

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

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

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

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

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