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

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

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

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

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

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

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

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

Разбивать product backlog или нет?

Предположим, у вас есть один продукт и две Scrum-команды. Сколько вам нужно product backlog'ов? Сколько Product owner’а? Выбор достаточно сильно повлияет на то, как будут проходить встречи по планированию спринта. Мы оценили три возможных подхода.

Подход первый: Один product owner - один backlog

«Должен остаться только один». Наш любимый подход.

Преимущество этого подхода в том, что можно разрешить команде самой планировать работу на основе приоритетов, расставленных product owner'ом. Product owner может сосредоточиться на том, что ему нужно, и предоставить командам самим, разбивать истории на задачи.

Ближе к делу. Давайте посмотрим, как проходит встреча по планированию спринта для этой команды. Встреча по планированию спринта проходит на нейтральной территории.

Прямо перед встречей product owner называет одну из стен «стеной product backlog и развешивает на ней истории (учетные карточки), отсортированные по приоритету. Он продолжает вешать их, пока не займёт всю стену. Как правило, такого количества историй более чем достаточно для спринта.

Каждая Scrum-команда выбирает пустой участок стены и вешает там своё название. Это будет их «командная стена». После этого каждая команда отклеивает истории со «стены product backlog, начиная с самых важных, и переклеивает их на свою «командную стену».

На рисунке ниже показана описанная ситуация. Желтые стрелки изображают движение учетных карточек со «стены product backlog на стены команд.

По ходу встречи product owner и команды торгуются за учетные карточки, двигают их между командами, передвигают карточки вверх-вниз, меняя приоритеты, разбивают их на части и т.п. Где-то через час каждая из команд получает предварительную версию sprint backlog’а на своей «командной стене». Дальше команды работают независимо, оценивая истории и разбивая их на подзадачи.

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

Подход второй: Один product owner - несколько backlog'ов

В этом подходе product owner ведёт несколько product backlog’а, по одному на команду. Мы на самом деле не применяли этот подход, но мы делали что-то похожее. Это был наш запасной план на случай, если первый подход не сработает.

Недостатком этого подхода является то, что здесь истории командам раздает product owner, хотя команды, вероятно, справились бы с этим лучше сами.

Подход третий: Несколько product owner’ов - несколько backlog’ов

Похоже на второй вариант, по отдельному product backlog на команду, только ещё и с отдельным product owner’ом на каждую команду.

Мы не пробовали так делать, и, скорее всего, пробовать не будем.

Если два product backlog’а касаются одного и того же исходного кода, это скорее всего приведёт к серьёзному столкновению интересов между Product owner’ами.

Если же два product backlog’а имеют дело с разными исходниками, то это, по большому счету, всё равно, что разбить продукт на отдельные подпродукты, и разрабатывать их независимо. И это значит, что мы вернулись к ситуации «одна команда разрабатывает один продукт», которая для нас приятна и понятна.