82 / 94
Scrum и XP: заметки с передовой
82
Сработало это достаточно хорошо. Так как Scrum-команде дали возможность планировать свою работу,
она, в конце концов, смогла стабилизировать систему. А тем временем пожарная команда полностью
отказалась от попыток что-либо планировать и работала полностью по запросам, то есть только устраняла
очередной проявившийся ужасный дефект.
Естественно,
полностью
оставить Scrum-команду в покое не получилось. Частенько пожарная команда
вынуждена была привлекать к решению вопросов отдельных людей из Scrum-команды, или, в худшем случае,
всю команду.
В любом случае через пару месяцев система стала настолько стабильной, чтобы мы могли отказаться от
пожарной команды в пользу дополнительных Scrum-команд. «Пожарные» были просто счастливы сдать свои
шлемы и присоединиться к обычным Scrum-командам.
Разбивать product backlog или нет?
Предположим, у вас есть од н продукт и две Scrum-команды. Сколько вам нужно product backlog'ов?
Сколько product owner'ов? Выбор достаточно сильно повлияет на то, как будут проходить встречи по
планированию спринта. Мы оценили три возможных подхода.
Подход первый: Один product owner – один backlog
"Д лж н остаться только один". Наш любимый подход.
Преимущество этого подхода в том, что можно разрешить команде самой планировать работу на основе
приоритетов, расставленных product owner'ом. Product owner может сосредоточиться на том,
что ему нужно
,
и предоставить командам самим, разбивать истории на задачи.
Продукт А
Product
owner
Product
Backlog
Ближе к делу. Давайте посмотрим, как проходит встреча по планированию спринта для этой команды.
Встреча по планированию спринта проходит на нейтральной территории.
Прямо перед встречей product owner называет одну из стен "стеной product backlog'а" и развешивает на
ней истории (учетные карточки), отсортированные по приоритету. Он продолжает вешать их, пока не займёт
всю стену. Как правило, такого количества историй более чем достаточно для спринта.