Постигая Agile

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

Миновало уже шесть месяцев, пять спринтов были пройдены. Роджер чувствовал, как Ави усложняет требования для команды разработчиков. Ави был расстроен, что не удается разработать сайт, который он мог бы продать своим клиентам. Команда предполагала закончить страницу видеотегов и социальных медиа двумя спринтами ранее, но до сих пор не сделала этого. На последней встрече аккаунт-менеджеров Ави обвинил команду в отставании от сроков. Роджер понял: проект находится под угрозой закрытия.

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

Обращаясь к команде, Роджер в отчаянии сказал: «Меня просто затащили в кабинет к генеральному директору. Он недоволен отсутствием результатов, так же как и Ави. Послушайте, я буду защищать вас и возьму ответственность за случившееся на себя. Но для этого нужно поработать над нашими расчетами, потому что они совершенно неверные. И, кроме того, мне действительно необходимо, чтобы вы поработали по выходным и выправили ситуацию». За последние два месяца он просил об этом свою команду уже в третий раз. Этот проект так же, как и предыдущие, выбился из расписания.

Но что пошло не так? Можете ли вы определить, в чем проблема? Что бы вы сделали, если бы вас назначили scrum-мастером этого проекта? Вспомните об agile-ценностях и принципах. Есть ли способ их применения, который бы помог проекту?

Каждый член scrum-команды – владелец проекта

У каждого scrum-проекта есть владелец продукта, scrum-мастер и команда. Но не всякий проект можно назвать эффективным. Два владельца продукта, которые придерживаются разных методологий (Scrum и Waterfall), будут действовать по-разному. Scrum-мастер не делает того же, что командно-административный менеджер проекта или технический руководитель команды. Вот когда scrum-мастер, владелец продукта и команда начинают работать вместе, а не врозь, – это начинает походить на scrum-проект.

Scrum-мастер управляет процессом принятия командных решений

То, как scrum-мастер делает свою работу, сильно отличается от командно-административной модели управления.

В командно-административном проекте его руководитель – владелец и хранитель расписания и плана работы. Он беседует со стейкхолдерами, получает требования, меняет план работы, получает от команды расчеты, распределяет задачи и строит график. Именно такой подход Роджер использовал в проекте Lolleaderz.com – он получил требования от Ави, смету от команды и распределил задачи между ее членами.

Участники командно-административной команды всеми силами спасают свою шкуру и не берут на себя ответственность, если в проекте возникают проблемы, вызванные планами каких-то других работ. Любому, кто имеет исключительное право собственности на график и план работы, остальные члены группы и владелец продукта с удовольствием позволяют принимать решения самостоятельно.

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

Владелец продукта помогает команде понять ценность программного обеспечения