Скрам: Правила игры. Карманное руководство

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

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

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

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

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

Несколько скрам-команд используют одни и те же критерии качества продукта, выраженные в определении готовности. Они, возможно, решат, что проще работать с одинаковой продолжительностью спринта, чтобы упростить планирование, интеграцию, выпуск и оценку работы. Будет предусмотрен дополнительный объем работ в индивидуальных бэклогах спринтов, чтобы работа была всегда интегрированной.

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

Соблюдаются все правила, определенные скрамом. Ядро системы – узнаваемый скрам. Чтобы выпускать инкременты продукта, которые обеспечивают от начала до конца ценность для конечного пользователя, все целиком есть «система функциональной возможности». Независимо от их комбинации, команды совместно выпускают интегрированные инкременты продукта не позднее конца каждого спринта.

3.7.3. Мультипродуктовый скрам

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

У каждого продукта есть свой владелец. Для каждого продукта существует бэклог продукта и несколько команд, которые его выпускают и поддерживают. Каждая продуктовая экосистема – это однокомандный или мультикомандный скрам.

Из схем мультипродуктового скрама (рис. 3.4) становится ясно, что синхронизация и выравнивание в основном происходят на уровне бэклогов продуктов через соответствующих владельцев продуктов. Отдельные бэклоги продукта упорядочиваются с помощью оптимизации продуктовой линейки, пакета продуктов, соображений относительно программ или портфолио. Таким образом, владельцы продуктов при поддержке и помощи своей организации инкрементально управляют своими бэклогами продуктов на основе обмена информацией и общего продвижения в работе.

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