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

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

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

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

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

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

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

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

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

При наличии нескольких команд, одновременно работающих над одним исходным кодом, нам неизбежно придется иметь дело с параллельными ветками кода в системе SCM (software configuration management). Есть много книг и статей, рассказывающих, как обеспечить одновременную работу с кодом для нескольких людей, поэтому я не буду вдаваться в детали. Вряд ли мне удастся добавить что-то новое. Однако я хотел бы вкратце поделиться наработками нашей команды:

• Всегда поддерживайте основную ветку проекта в рабочем состоянии. Это, как минимум, означает, что все должно компилироваться, и все юнит-тесты должны проходить. Таким образом, мы получаем возможность в любой момент выпустить рабочий релиз. Желательно, чтобы сервер непрерывной интеграции строил и автоматически устанавливал готовый продукт в тестовом окружении каждую ночь.

• Помечайте каждый релиз тэгом. Всякий раз, когда для приемочного тестирования или реального использования выпускается очередной релиз, соответствующая версия кода должна быть помечена тэгом. Это позволит вам при необходимости в любой момент создать в этой точке отдельную ветку для поддержки выпущенного продукта.

• Создавайте новые ветки кода только тогда, когда это действительно необходимо. Хорошим практическим правилом будет создание новой ветки только при условии, если вы вынуждены нарушать стратегию использования текущий ветки. Если у вас есть сомнения, то не делайте ветвлений. Почему? Потому что каждое ветвление требует дополнительной работы и последующей поддержки.

• Используйте ветвление для разделения кода разных стадий разработки. Вы можете создать для каждой Scrum команды отдельную ветку разработки. Но если вы смешаете краткосрочные изменения с долгосрочными изменениями в одной и той же ветке, вам очень сложно будет выпускать небольшие заплатки!

• Чаще синхронизируйтесь. Если вы работаете в отдельной ветке, синхронизируйтесь каждый раз, когда вы хотите что-либо построить. Каждый день, когда вы начинаете работу, синхронизируйтесь с главной ветвью разработки, так чтобы ваша ветка была в адекватном состоянии и учитывала все изменения, сделанные другими группами. Даже если это приведет к кошмару слияния (merge-hell), учтите, что все могло бы быть еще хуже, если бы вы затянули слияние.