Когда у вас над одним продуктом работают сразу несколько Scrum-команд, всё намного сложнее. Это общая проблема и она характерна не только для Scrum'а. Чем больше разработчиков, тем больше проблем.

Мы и с этим экспериментировали (как обычно). Максимальный размер команды, работавшей у нас над одним проектом, был порядка 40-ка человек.

Как оказалось, ключевыми являются следующие вопросы:

• Сколько сформировать команд?

• Как распределить людей по командам?

Если настолько сложно работать по Scrum'у с несколькими командами, то зачем вообще заморачиваться? Почему просто не собрать всех в одну команду?

Самая большая Scrum-команда, которая у нас когда-либо была, состояла из 11-ти человек. И это работало, правда, не очень хорошо. Ежедневный Scrum всегда длился больше 15-ти минут. Членам команды было сложно держать в голове информацию о том, чем каждый из них занимается, из-за этого могли возникать недоразумения. ScrumMaster'у тоже было сложно направить работу в нужное русло, и было сложно найти время, чтобы разобраться со всеми возникшими трудностями.

Как вариант, можно выделить две команды. Но будет ли это лучше? Не факт.

Если команда опытная, ей комфортно работать по Scrum'у, и вы знаете, как правильно разделить работу на два отдельных направления, что позволит избежать одновременной работы над одними и теми же исходниками, тогда я скажу, что это хорошая идея: разделить на отдельные команды. В противном же случае, не смотря на все минусы работы в большой команде, я бы подумал о том, как оставить одну большую команду.

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

Как же понять, насколько правильно были оценены преимущества и недостатки при выборе между «большой командой» или «несколькими командами»?

Будьте предельно внимательны, и вы заметите формирование «виртуальных команд».

Пример 1: Вы остановились на одной большой команде. Но как только начнёте наблюдать за тем, кто с кем общается на протяжении спринта, то заметите, что команда фактически разбивается на две подкоманды.

Пример 2: Вы решили сделать три небольшие команды. Но как только начнёте прислушиваться, кто и с кем говорит в ходе спринта, то заметите, что первая и вторая команды общаются между собой, тогда как третья работает сама по себе.

Что бы это значило? Что ваша стратегия разделения была неправильной? И да (если виртуальные команды постоянные) и нет, (если виртуальные команды временные).

Взгляните ещё раз на первый пример. Если состав обеих виртуальных подкоманд меняется (т. е. люди переходят из одной виртуальной подкоманды в другую), тогда возможно вы приняли правильное решение, создав одну большую Scrum-команду. Если же две виртуальные подкоманды в ходе спринта остаются неизменными, то, возможно, для следующего спринта их следует разбить на две настоящие независимые Scrum-команды.

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

Разбиение на команды — это действительно одна из самых сложных задач в Scrum'е. Не пытайтесь копать очень глубоко или заниматься очень сложной оптимизацией. Экспериментируйте, наблюдайте за виртуальными командами, и не забывайте уделять обсуждению этого вопроса достаточно времени на ретроспективах. Рано или поздно вы найдёте для себя правильное решение. Однако запомните, что вам следует сделать всё, чтобы команды чувствовали себя комфортно и не мешали друг другу слишком часто.

Практически во всех книгах, которые я читал, утверждается, что «оптимальный размер» команды составляет примерно 5–9 человек.

Исходя из того, что я видел, остаётся только согласиться с этим мнением. Хотя, как по мне, всё-таки лучше иметь команду от 3-ёх до 8-ми человек. Поднапрягитесь, но создайте команды такого размера.

Допустим, у вас есть одна Scrum-команда из 10-ти человек. Подумайте, может быть стоить выкинуть двух наиболее слабых участников команды. Ой-йо-йой, я что — правда, сказал это?

Предположим, вы разрабатываете два разных продукта, у вас по три человека в каждой команде, однако обе команды работают очень медленно. Может быть, их следует объединить в одну команду из 6-ти человек. И пусть эта команда одновременно создаёт оба продукта. В этом случае одному из двух product owner'ов придётся уйти (или начать играть роль консультанта, ну или ещё что-то наподобие этого).

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

Предположим, есть три Scrum команды, которые работают над одним проектом. Должны ли их спринты быть синхронизированными, т. е. начинаться и заканчиваться одновременно? Или же они должны пресекаться друг с другом?

Сначала мы решили, что нужны пересекающиеся спринты (по времени).

Это звучало круто. В любой момент времени у нас был бы спринт, который вот-вот закончится, и спринт, который вот-вот начнётся. Нагрузка на Product owner’а была бы распределена равномерно по времени. Постоянные релизы продукта. Демонстрации каждую неделю. Аллилуйя.

Да-да, утопия… но тогда это действительно звучало убедительно!

Мы только-только начали так работать, но тут мне подвернулась возможность пообщаться с Кеном Швабером (Ken Schwaber) (в рамках моей Scrum-сертификации). Он указал на то, что это неправильно, и что было бы гораздо лучше синхронизировать спринты. Я точно не помню его доводов, но в ходе нашей дискуссии он меня убедил в этом.

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

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

• Все команды могут работать на одну цель в течение спринта и проводить планирование спринта вместе, что приводит к лучшему сотрудничеству между командами.

• Меньше административной мороки, например меньшее количество встреч для планирования спринта, демонстраций и релизов.

Предположим, что у нас над одним продуктом работают три команды.

Красным помечен product owner. Чёрным — Scrum Master. А остальные это пехота… ну то есть… почтенные члены команды.

Кто при таком распределении ролей должен решать, какие люди будут отнесены к какой команде. Может, product owner? Или может все три ScrumMaster'а вместе? Или вообще каждый человек сам решает, в какой команде работать? Но если так, то что делать в случае, когда все захотят в одну и ту же команду (потому что там красивая ScrumMaster'ша)?

А что если потом окажется, что над этим кодом больше двух команд работать не смогут, и нам придётся трансформировать три команды по 6 человек в две по 9? Это значит, что будет всего 2 ScrumMaster'а. Так кого же из трёх текущих ScrumMaster'ов надо лишить титула?

Во многих компаниях эти вопросы надо решать очень деликатно.

Есть соблазн отдать распределение людей по командам и их последующее перераспределение на откуп product owner’у. Но ведь это не совсем то, чем должен заниматься product owner, правда же? Product owner это специалист по предметной области, который указывает команде направление движения. В общем случае его не должно волновать всё остальное. Особенно, учитывая его роль «цыплёнка» (это если вы слышали про метафору «свиней и цыплят», а если не слышали, то погуглите).

Мы решили проблему вводом роли «тимлид». Человека в этой роли можно описать как «Scrum-of-Scrums master», «босс» или «главный ScrumMaster». Ему не нужно возглавлять какую-либо команду, но он отвечает за вопросы, не входящие в компетенцию команд, такие как, например, «кого назначить ScrumMaster'ом», «как распределить людей по командам» и т. д.

Придумать действительно подходящие название для этой роли у нас так толком и не получилось. А «тимлид» оказалось наименее неподходящим, из тех, что мы перепробовали.

Такой подход сработал в нашем случае, и я его рекомендую (не зависимо от того, как вы решите назвать эту роль у себя).

На случай, когда у вас несколько команд работают над одним и тем же продуктом, существует две стратегии распределения людей по командам.

• Позволить специально назначенному человеку провести распределение, например «тимлиду», про которого я писал выше, product owner’а или любому другому менеджеру (если у него достаточно информации, чтобы с этим справиться).

• Позволить командам каким-то способом самоорганизоваться.

Мы попробовали все три стратегии. Три?!? Ну да — стратегию № 1, стратегию № 2 и их комбинацию. И оказалось, что комбинация двух стратегий работает лучше всего.

Перед планированием спринта тимлид приглашает Product owner’а и всех ScrumMaster'ов на совещание по поводу формирования команд. Мы обсуждаем прошлый спринт и решаем, есть ли необходимость в переформатировании команд. Возможно, нам нужно объединить две команды или перевести несколько человек из одной команды в другую. Мы решаем, что именно нам нужно, записываем это на листик и несём на планирование спринта как предварительное распределение по командам.

Первым делом на планировании спринта мы проходимся по наиболее приоритетным историям из product backlog’а. А потом тимлид говорит что-то вроде:

«Всем привет. Вот как мы предлагаем сформировать команды на следующий спринт».

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

(тимлид ждёт пока народ побродит по комнате, и через некоторое время появляются три группы людей, каждая соберётся возле своей части стены).

«Текущее распределение — только прикидка! Просто чтобы было с чего начать. По мере планирования спринта любой из вас волен переходить в любую другую команду, можно разделять команды, можно, наоборот, объединять их… В общем, делайте всё, что подскажет здравый смысл, учитывая приоритеты, которые озвучивает product owner.»

Описанный выше подход оказался для нас наиболее эффективным. Немного директивного управления, которое оптимизируется разумной долей самоуправления.

Предположим, ваша система состоит из трёх основных компонентов:

Клиент

Сервер

БД

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

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

Именно с этого подхода мы когда-то начинали. Работает не очень хорошо, по крайней в том случае, когда большинство историй затрагивают сразу несколько компонентов.

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

Это значит, что всем трём командам придётся довольно плотно сотрудничать, чтобы закончить эту историю. Не очень удобно.

А можно создать универсальные команды, то есть команды, которые не заточены на работу всего лишь с одним специфическим компонентом.

Если большая часть всех историй предполагает работу над несколькими компонентами, тогда такое разделение на команды работает намного лучше. Каждая команда сможет реализовать историю целиком: клиентскую часть, серверную и базу данных. Благодаря чему команды смогут работать намного более независимо друг от друга, что на самом деле ОЧЕНЬ ХОРОШО.

Когда мы начали внедрять Scrum, первым делом мы сделали из всех наших специализированных команд (подход № 1) универсальные команды (подход № 2). Это уменьшило количество ситуаций «мы не можем закончить задачу, так как ждём, пока эти ребята закончат серверную часть».

Однако иногда нам всё-таки приходится собирать временные команды, специализирующиеся на разработке отдельных компонентов.

Обычно каждый спринт обладает своими собственными особенностями в зависимости от того, какого рода задачи мы пытаемся решить. Как следствие, оптимальный состав команды для каждого спринта может отличаться.

Фактически, почти каждый спринт нам приходилось говорить себе что-то вроде: «этот спринт не совсем обычный спринт, потому что (ля-ля-ля)…». Через некоторое время мы прекратили использовать понятие «обычный» спринт. Обычных спринтов просто нет. Так же как нет «обычных» семей или «обычных» людей.

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

Одним из ключевых аспектов Scrum'а является «сработанность команды», т. е. если члены команды работают вместе в течение многих спринтов, они обычно становятся очень сплоченными. Они научатся входить в групповой поток, и достигнут невероятного уровня продуктивности. Но чтобы достичь этого требуется несколько спринтов. Если вы будете часто изменять состав команды, то вы никогда не достигнете настоящей командной сработанности.

Поэтому, если вы решили изменить состав команды, учитывайте все последствия. Будут ли это долговременные или кратковременные изменения? Если кратковременные, стоит их пропустить. На долговременные изменения можно пойти.

Есть одно исключение: большая команда, которая только-только начала работать по Scrum’у В этом случае возможны некоторые эксперименты с разделением команды на подкоманды, пока не будет найден вариант, который полностью устраивал бы всех. Удостоверьтесь, что все понимают, что отрицательный результат — тоже результат, что первые несколько итераций могут быть комом — и это нормально, при условии, что вы работаете над улучшениями.

Могу только подтвердить то, что говорят книги, посвящённые Scrum’у наличие в Scrum-команде участников с частичной занятостью — не очень хорошая идея.

Предположим, вы рассматриваете возможность взять Джо в свою команду как участника с частичной занятостью. Сначала хорошо всё обдумайте. Действительно ли Джо необходим вашей команде? Уверены, что не можете заполучить его на полный день? Какие у него ещё обязанности? Можно ли передать обязанности Джо кому-то другому и перевести его на роль консультанта? Можно ли заполучить Джо на полный день, начиная со следующего спринта, а пока передать его обязанности кому-то другому [6]?

Но иногда просто нет выбора. Вам позарез нужен Джо потому, что он единственный администратор баз данных (DBA) во всём здании. Другим командам он нужен так же сильно, как и вам, поэтому он никак не может работать с полной занятостью в вашей команде. Кроме того, компания не может себе позволить нанять ещё одного DBA. Ну и ладно. Это аргументированный случай, чтобы взять его на неполную занятость (что, кстати, было у нас). Но прежде, чем сделать это, всегда проводите подобный анализ.

В обычной ситуации я бы предпочёл команду, состоящую из трёх участников с полной занятостью, чем из восьми, но с частичной.

Если у вас есть человек, являющийся участником нескольких команд, как, например вышеупомянутый DBA, всё равно неплохо бы его закрепить за одной командой. Определите, какая команда нуждается в нём больше всего, и назначьте её в качестве «домашней команды». Когда его никто не будет дёргать, он будет присутствовать на ежедневных Scrum'ах, планированиях спринтов, ретроспективах и т. д. этой команды.

Scrum-of-scrums — это регулярные встречи, цель которых — обсуждение различных вопросов между Scrum-мастерами.

Как-то мы работали над четырьмя продуктами. Над тремя из них работало по одной Scrum-команде, а над четвёртым — 25 человек, которые были разделены на несколько Scrum-команд. Это выглядело следующим образом:

У нас было два уровня Scrum-of-Scrums: «уровня продукта», который проводился с участием команд продукта Д, и «уровня компании» для участников всех команд.

Эта встреча была очень важной. Мы проводили её не реже одного раза в неделю. Мы обсуждали проблемы интеграции, балансировки команд, подготовку к следующему планированию спринта и т. д. Мы выделяли на это 30 минут, но часто нам их не хватало. В качестве альтернативы можно было бы проводить ежедневный Scrum-of-Scrums, однако, мы так и не собрались опробовать его.

Наша повестка дня имела следующий вид:

1. Каждый по очереди рассказывал, что его команда сделала на прошлой неделе, что планирует закончить на этой недели, и с какими трудностями они столкнулись.

2. Любые другие проблемы, относящиеся к компетенции нескольких команд одновременно, которые нужно обсудить. Например, вопросы интеграции.

На самом деле повестка дня Scrum-of-Scrums не так уж и важна — важнее, чтобы эта встреча проводилась регулярно.

Мы назвали эту встречу «Пульсом». Мы пробовали проводить её в разных форматах с разными участниками. В конце концов, мы отказались от всех остальных идей в пользу еженедельного собрания продолжительностью 15 минут, в котором участвует весь коллектив (вообще-то все те, кто участвуют в процессе разработки).

Чегооо? 15 минут? Весь коллектив? Все участники всех продуктовых команд? И это работает?

Да — работает, если вы (или ответственный за проведение этого собрания) очень строги относительно того, чтобы собрание было сжатым.

Формат собрания:

1. Новости и уточнения со стороны руководителя разработки. Например, информация о предстоящих мероприятиях, событиях.

2. «Карусель». Один человек из каждой продуктовой группы [7] отчитывается в том, что было сделано за прошлую неделю, что планируется сделать на этой неделе и о проблемах. Некоторые другие люди так же отчитываются (например, начальник отдела по работе с клиентами, начальник отдела контроля качества).

3. Все, кто хочет, могут свободно высказаться и задать любые вопросы.

Это собрание для подачи сжатой информации, а не для дискуссий или рефлексии. Если этим и ограничиться, то 15-ти минут вполне хватает. Иногда оно занимает больше времени, но очень редко больше 30ти минут. Если завязывается интересная дискуссия, я её приостанавливаю и предлагаю всем заинтересованным остаться и продолжить её после собрания.

Почему мы проводим «Пульс» всем коллективом? Потому, что мы заметили, что Scrum-of-Scrums уровня компании посвящен преимущественно отчётности. На нём очень редко возникали дискуссии. Кроме того, информация, озвучиваемая на Scrum-of-Scrum'е, очень интересна и многим из тех, кто на него не попадает. Обычно командам интересно, чем занимаются другие команды. И мы посчитали, если всё равно нужно тратить время на информирование друг друга, то почему бы не присутствовать всем.

Если у вас есть много Scrum команд, работающих над одним продуктом, и у всех ежедневный Scrum происходит в одно и то же время, может возникнуть проблема. Product Owner'ы (и не в меру надоедливые люди вроде меня) обладают физической возможностью посещать только один ежедневный Scrum в один момент времени. Поэтому мы просим команды разнести время проведения ежедневных Scrum'ов.

Этот пример расписания относится к тому периоду, когда у нас был ежедневный scrum в разных комнатах, а не в комнате совещаний команды. Обычно встречи планируются на 15 минут, но каждая команда получала 30 минутный временной слот на случай, если ей надо было немного задержаться.

Это очень удобно по двум причинам:

1. Люди, подобные мне и product owner’а могут посетить все ежедневные scrum’ы за одно утро. Нет лучшего способа получить представление о том, как проходит спринт, и в чем основные проблемы.

2. Команды могут посещать ежедневные Scrum'bi друг друга. Не очень часто, но иногда случается, что две группы работают в смежных областях, и участники групп заглядывают друг к другу на ежедневные Scrum’ы, чтобы быть в курсе происходящего.

Обратная сторона медали заключается в ограничениях для команды — теряется возможность изменить время проведения ежедневного Scrum'а. Хотя, на самом деле, для нас это не составляло проблемы.

Мы столкнулись с ситуацией, когда было невозможно внедрить Scrum в большом проекте из-за того, что его команда постоянно тушила пожары, т. е. в панике устраняла дефекты преждевременно выпущенной системы. Это был порочный круг: из-за того, что всё время уходило на постоянную борьбу с пожарами, не было времени на их предотвращение (т. е. на улучшение архитектуры, внедрение автоматического тестирования, создание систем мониторинга и оповещения, и т. п.)

Мы разрубили этот гордиев узел тем, что выделили специальную «пожарную» команду и отдельную Scrum-команду.

Задачей Scrum-команды (с благословления Product owner’а) была стабилизация системы и предотвращение потенциальных пожаров. А «пожарная» команда (её мы назвали «командой поддержки») выполняла две задачи:

1. Тушить пожары.

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

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

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

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

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

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

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

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

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

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

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

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

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

На рисунке ниже показана описанная ситуация. Желтые стрелки изображают движение учетных карточек со «стены 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), учтите, что все могло бы быть еще хуже, если бы вы затянули слияние.

Как мы проводим ретроспективы в случае, если над одним продуктом работает сразу несколько команд?

Сразу же после того как закончилась демонстрация спринта и отшумели бурные овации, команды расходятся по своим комнатам или отправляются в какое-то удобное местечко. И каждая команда проводит свою ретроспективу как это описано на странице 50 «Как мы проводим ретроспективы».

А на планировании (где присутствуют все команды, так как мы стараемся синхронизировать спринты всех команд, которые работают над одним продуктом), мы первым делом выслушиваем представителей каждой команды, на тему наиболее важных моментов последней ретроспективы. Выходит примерно по 5 минут на команду. После этого проводим свободное обсуждение минут на 10–20. И, собственно, только потом начинается планирование спринта.

Мы не пробовали никаких других способов, потому что и такой подход работает достаточно хорошо. Однако, самый большой недостаток этого подхода, состоит в отсутствии возможности немного передохнуть между ретроспективой и началом планирования (см. стр. 55 «Отдых между спринтами»).

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

Примечания:

6

участнику вашей команды (прим. переводчика)

7

группы команд, вовлечённых в разработку одного продукта (прим. переводчика)