Книга: Scrum и XP: заметки с передовой

«Пожарные» команды

«Пожарные» команды

Мы столкнулись с ситуацией, когда было невозможно внедрить Scrum в большом проекте из-за того, что его команда постоянно тушила пожары, т. е. в панике устраняла дефекты преждевременно выпущенной системы. Это был порочный круг: из-за того, что всё время уходило на постоянную борьбу с пожарами, не было времени на их предотвращение (т. е. на улучшение архитектуры, внедрение автоматического тестирования, создание систем мониторинга и оповещения, и т. п.)

Мы разрубили этот гордиев узел тем, что выделили специальную «пожарную» команду и отдельную Scrum-команду.

Задачей Scrum-команды (с благословления Product owner’а) была стабилизация системы и предотвращение потенциальных пожаров. А «пожарная» команда (её мы назвали «командой поддержки») выполняла две задачи:

1. Тушить пожары.

2. Прикрывать Scrum-команду от всяких раздражителей, вроде неожиданных запросов на изменение функционала, которые непонятно откуда берутся.

«Пожарную» команду мы разместили поближе к дверям, а Scrum-команду — подальше в комнате. Таким образом, «пожарная» команда могла даже физически защищать Scrum-команду от раздражителей типа жаждущих общения «продажников» или разозлённых клиентов.

В каждую команду были включены старшие разработчики, чтобы команды не слишком зависели друг от друга.

В основном этот подход был решением проблемы внедрения Scrum'а. Как вообще можно начать практиковать Scrum, если команда не может спланировать свою работу больше, чем на один день вперёд? Нашим ответом на это, как сказано выше, было разделение команд.

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

Естественно, полностью оставить Scrum-команду в покое не получилось. Частенько пожарная команда вынуждена была привлекать к решению вопросов отдельных людей из Scrum-команды, или, в худшем случае, всю команду.

В любом случае через пару месяцев система стала настолько стабильной, чтобы мы могли отказаться от пожарной команды в пользу дополнительных Scrum-команд. «Пожарные» были просто счастливы сдать свои шлемы и присоединиться к обычным Scrum-командам.

Оглавление книги