85 / 94
Scrum и XP: заметки с передовой
85
Продукт А
Product
owner
Product
Backlog
Product
Backlog
Product
owner
Мы не пробовали так делать, и, скорее всего, пробовать не будем.
Если два product backlog'а касаются одного и того же исходного кода, это скорее всего приведёт к
серьёзному столкновению интересов между product owner'ами.
Если же два product backlog'а имеют дело с разными исходниками, то это, по большому счету, всё равно,
что разбить продукт на отдельные подпродукты, и разрабатывать их независимо. И это значит, что мы
вернулись к ситуации "одна команда разрабатывает один продукт", которая для нас приятна и понятна.
Параллельная работа с кодом
При наличии несколь их команд, одновременно работающих над одним исходным кодом, нам
неизбежно придется иметь дело с параллельными ветками кода в системе SCM (software configuration
management). Есть много книг и статей, рассказывающих, как обеспечить одновременную работу с кодом для
нескольких людей, поэтому я не буду вдаваться в детали. Вряд ли мне удастся добавить что-то новое. Однако
я хотел бы вкратце поделиться наработками нашей команды:
•
Всегда поддерживайте основную ветку проекта в рабочем состоянии. Это, как минимум, означает,
что все должно компилироваться, и все юнит-тесты должны проходить. Таким образом, мы
получаем возможность в
любой момент
выпустить рабочий релиз. Желательно, чтобы сервер
непрерывной интеграции строил и автоматически устанавливал готовый продукт в тестовом
окружении каждую ночь.
•
Помечайте каждый релиз тэгом. Всякий раз, когда для приемочного тестирования или реального
использования выпускается очередной релиз, соответствующая версия кода должна быть
помечена тэгом. Это позволит вам при необходимости в любой момент создать в этой точке
отдельную ветку для поддержки выпущенного продукта.
•
Создавайте новые ветки кода только тогда, когда это действительно необходимо. Хорошим
практическим правилом будет создание новой ветки
только
при условии, если вы вынуждены
нарушать стратегию использования текущий ветки. Если у вас есть сомнения, то не делайте
ветвлений. Почему? Потому что каждое ветвление требует дополнительной работы и
последующей поддержки.
•
Используйте ветвление для разделения кода
разных стадий разработки
. Вы можете создать для
каждой Scrum команды отдельную ветку разработки. Но если вы смешаете краткосрочные
изменения с долгосрочными изменениями в одной и той же ветке, вам очень сложно будет
выпускать небольшие заплатки!
•
Чаще синхронизируйтесь. Если вы работаете в отдельной ветке, синхронизируйтесь каждый раз,
когда вы хотите что-либо построить. Каждый день, когда вы начинаете работу, синхронизируйтесь
с главной ветвью разработки, так чтобы ваша ветка была в адекватном состоянии и учитывала все
изменения, сделанные другими группами. Даже если это приведет к кошмару слияния (merge-
hell), учтите, что все могло бы быть еще хуже, если бы вы затянули слияние.