В этой новой среде существует понятие общей цели, определенной во время прелюдии. Принцип границ, который способствует обмену знаниями и опытом, применим и к отношениям между командами.
Как организовать несколько команд, работающих над одним и тем же продуктом?
Они должны уметь самоорганизовываться, чтобы приносить результаты. Результат – это функциональность. Такой паттерн распределения работы известен как продуктовая команда [Larman, «Feature team»].
Понятие функциональности детально рассмотрено ранее, и это упрощает понимание концепции продуктовой команды.
Команды организованы таким образом, что способны самостоятельно и полноценно разработать функциональность.
Это перекликается с понятием кроссфункциональности команды.
Внимание! Такой способ организации команд является не просто изменением, а настоящей организационной встряской, поскольку традиционная практика разделения работы основана на архитектуре системы. Задача – добиться успеха в переходе от компонентных команд к продуктовым.
Продуктовая команда – это Scrum-команда с ее классическими характеристиками (свойства Scrum-команды представлены в главе 3). Она должна быть подходящего размера, самоорганизованной, кроссфункциональной, самобытной и стабильной. Кроссфункциональность имеет особое значение для обеспечения командой ценности, ограничивая при этом зависимости от других команд.
Каждая продуктовая команда представляет собой Scrum-команду, которая реализует свои функциональности, разбивая их на истории. У каждой команды есть свой Scrum-мастер.
С ролью Владельца продукта все обстоит несколько иначе.
Владелец продукта – это роль, связанная одновременно и с продуктом, и с командой. При больших масштабах над одним продуктом работает несколько команд, что, разумеется, влияет на роль PO.
Связь между ролью и продуктом сохраняется (и это подчеркивается в наименовании роли): у продукта есть только один РО, который работает с несколькими командами. Это действенный принцип – в случае, если количество команд остается небольшим, до трех или даже четырех, и если команды немногочисленны.
Рисунок 21.2 – Один Владелец продукта для нескольких команд
Иногда же возникает необходимость иметь других Владельцев продукта, например, по одному для каждой основной функциональности. Есть вариант создать роль Владельца продукта для каждой команды или для каждых двух-трех команд.
Таким образом, формируется группа РО для одного продукта.
Это тоже команда, и у нее, как у любой другой, есть свой Владелец продукта. Эта роль называется РО из РО, начальник РО или менеджер по продукту. Многие решения принимаются коллегиально, но при необходимости окончательное слово будет за человеком, исполняющим данную роль.
В главе 3 были представлены зоны, соответствующие разным уровням взаимосвязей между участниками процесса. В многокомандном контексте в зону 3 также включены взаимоотношения между командами.
Идея продуктовых команд состоит в том, чтобы минимизировать ограничивающие их зависимости. При этом сохраняются и укрепляются отношения, направленные на получение новых знаний.
Далее мы увидим, как события Scrum побуждают команды к общим встречам. Более того, между ними возникают взаимосвязи, необходимые для работы над функциональностью. В некоторых случаях применим паттерн роения: функциональность, находящаяся под ответственностью одной команды, реализуется при поддержке других команд.
Создание сообществ для обмена практиками – это еще один способ обмена опытом и, соответственно, укрепления сотрудничества между командами. Это особенно важно для обмена техническими навыками, необходимыми для работы со сложными системами.
Когда задействовано столько человек, вряд ли они все смогут находиться в одном рабочем пространстве. Для комфортного сотрудничества следует обратиться к инструментам для совместной работы на расстоянии, что не исключает возможности видеться друг с другом регулярно – например, в конце сезона.
21.3 Жизненный цикл продукта
Для лучшего понимания этого раздела рекомендую сперва ознакомиться с главой 2.
Рисунок 21.3 – Последовательность сезонов в жизненном цикле продукта
В Scrum отсутствует фаза проекта для первой разработки, за которой следовала бы фаза техобслуживания: жизнь продукта состоит из спринтов и сезонов.
Когда несколько команд разрабатывают один продукт, каждая из них проводит свой спринт. Но команда не устанавливает собственный темп и продолжительность спринта. Применяется паттерн сезонного ритма:
Все Scrum-команды работают в одном ритме: они начинают и заканчивают спринты одновременно.
Рисунок 21.4 – Паттерн сезонного ритма в больших масштабах
Пример. Все команды Peetic придерживаются одного ритма: сезоны длятся по три месяца, спринты – по две недели, пять спринтов за сезон.
Суть паттерна в том, что он увеличивает частоту интеграции для всех команд. Не возникает ситуаций, когда приходится ждать поставку от запаздывающей команды, чтобы собрать все части воедино. Частая интеграция улучшает качество и снижает риски. Ускоряется обратная связь, что ограничивает цену изменения.
Точно как и спринты, сезоны команд синхронизированы: одна дата начала, одна дата завершения. Все следуют одному ритму.
Общая для всех команд цель каждого сезона – добиться максимальной ценности продукта в заданные и известные временные рамки. Вот наш треугольник: дата и стоимость определены заранее, содержание, ориентированное на увеличение ценности, может корректироваться.
Рисунок 21.5 – Корректировка в космической программе
Все команды следуют сезонному ритму.
В конце сезона два момента, на которые стоит обратить внимание.
✓ Для ретроспективы и планирования нужен высокий уровень синхронизации между командами.
✓ Состав команд может меняться.
В целом паттерн сезонного ритма идет рука об руку с вводом в эксплуатацию в конце сезона. Но важно помнить, что ввод в эксплуатацию не связан с непосредственным завершением спринтов и сезонов: ввод в эксплуатацию должен произойти как можно скорее, что действительно и для Scrum в больших масштабах.
Прелюдия с участием нескольких команд бывает нечасто. Лучше начинать с малого, с одной команды, и постепенно добавлять в процесс новые. Если же это действительно необходимо, все команды используют один шаблон прелюдии и техники, которые представлены ниже.
21.4 Бэклог и доработка несколькими командами
Для лучшего понимания этого раздела рекомендую сперва ознакомиться с главами 6 «Структура бэклога», 7 «Доработка бэклога» и 8 «Определение критериев завершенности».
Философия заключается в сохранении концепции единого бэклога для нескольких команд.
Паттерн рабочего бэклога/бэклога поставки предполагает использование kanban-таблицы функциональностей, что интересно и в масштабе одной команды. Если же в процессе задействовано несколько команд, такая таблица становится обязательным инструментом. Упорядоченность элементов в таблице имеет фундаментальное значение для общего понимания приоритетов.
Также при помощи такой таблицы можно разделить работу между командами. Функциональность, как правило, – это ответственность одной команды, на что указывает какой-либо атрибут (например, цвет), добавленный к каждому элементу.
Рисунок 21.6 – Таблица функциональностей для трех команд
Итак, у команд есть бэклог поставки (представленный в виде таблицы функциональностей). Он один для продукта, даже если продукт большой.
Должны ли команды, работающие над одним и тем же продуктом, иметь общий бэклог со всеми историями? Или у каждого есть своя часть в общем бэклоге? Это решать командам!
Если команды приняли решение использовать паттерн лотков, есть вариант сохранить предложенное изображение рабочего процесса и добавить в него строчки для каждой команды в столбцах готово и в процессе. А можно помечать истории цветом, соответствующим той или иной команде.
Командам важно знать, что они будут делать во время спринта. Поэтому у каждой из них должен быть свой собственный план спринта.
Традиционная доработка (помимо того, что выполняется каждой командой) проводится еще и на более высоком уровне – уровне функциональностей. Во время сессии доработки решается, какие новые функциональности команды возьмут в работу.
Рисунок 21.7 – Доработка в больших масштабах практикуется в Авероне[63]
Это собрание предшествует сессии доработки на уровне каждой команды.
В нем участвует группа Владельцев продукта, эксперты и представители команд (в случае, если у команды нет своего собственного Владельца продукта).
Действия во время крупномасштабной доработки следующие:
✓ разбить большие функциональности на части,
✓ обсудить, какие пойдут в работу, выявить зависимости и риски, определить готовность,
✓ упорядочить функциональности,
✓ определить, какая команда отвечает за реализацию функциональности; другие, соответственно, участвуют в роении.