Внимание! Такой способ организации команд является не просто изменением, а настоящей организационной встряской, поскольку традиционная практика разделения работы основана на архитектуре системы. Задача – добиться успеха в переходе от компонентных команд к продуктовым.
Продуктовая команда – это Scrum-команда с ее классическими характеристиками (свойства Scrum-команды представлены в главе 3). Она должна быть подходящего размера, самоорганизованной, кроссфункциональной, самобытной и стабильной. Кроссфункциональность имеет особое значение для обеспечения командой ценности, ограничивая при этом зависимости от других команд.
Каждая продуктовая команда представляет собой Scrum-команду, которая реализует свои функциональности, разбивая их на истории. У каждой команды есть свой Scrum-мастер.
С ролью Владельца продукта все обстоит несколько иначе.
Владелец продукта – это роль, связанная одновременно и с продуктом, и с командой. При больших масштабах над одним продуктом работает несколько команд, что, разумеется, влияет на роль PO.
Связь между ролью и продуктом сохраняется (и это подчеркивается в наименовании роли): у продукта есть только один РО, который работает с несколькими командами. Это действенный принцип – в случае, если количество команд остается небольшим, до трех или даже четырех, и если команды немногочисленны.
Рисунок 21.2 – Один Владелец продукта для нескольких команд
Иногда же возникает необходимость иметь других Владельцев продукта, например, по одному для каждой основной функциональности. Есть вариант создать роль Владельца продукта для каждой команды или для каждых двух-трех команд.
Таким образом, формируется группа РО для одного продукта.
Это тоже команда, и у нее, как у любой другой, есть свой Владелец продукта. Эта роль называется
В главе 3 были представлены зоны, соответствующие разным уровням взаимосвязей между участниками процесса. В многокомандном контексте в зону 3 также включены взаимоотношения между командами.
Идея продуктовых команд состоит в том, чтобы минимизировать ограничивающие их зависимости. При этом сохраняются и укрепляются отношения, направленные на получение новых знаний.
Далее мы увидим, как события Scrum побуждают команды к общим встречам. Более того, между ними возникают взаимосвязи, необходимые для работы над функциональностью. В некоторых случаях применим паттерн
Создание сообществ для обмена практиками – это еще один способ обмена опытом и, соответственно, укрепления сотрудничества между командами. Это особенно важно для обмена техническими навыками, необходимыми для работы со сложными системами.
Когда задействовано столько человек, вряд ли они все смогут находиться в одном рабочем пространстве. Для комфортного сотрудничества следует обратиться к инструментам для совместной работы на расстоянии, что не исключает возможности видеться друг с другом регулярно – например, в конце сезона.
Для лучшего понимания этого раздела рекомендую сперва ознакомиться с главой 2.
Рисунок 21.3 – Последовательность сезонов в жизненном цикле продукта
В Scrum отсутствует фаза проекта для первой разработки, за которой следовала бы фаза техобслуживания: жизнь продукта состоит из спринтов и сезонов.
Когда несколько команд разрабатывают один продукт, каждая из них проводит свой спринт. Но команда не устанавливает собственный темп и продолжительность спринта. Применяется паттерн
Все Scrum-команды работают в одном ритме: они начинают и заканчивают спринты одновременно.
Рисунок 21.4 – Паттерн сезонного ритма в больших масштабах
Пример. Все команды Peetic придерживаются одного ритма: сезоны длятся по три месяца, спринты – по две недели, пять спринтов за сезон.