МасштабируемСкрамс помощьюНексуса

В этой статье мы кратко расскажем про Нексус — подход для масштабирования Скрама, который предложил создатель Скрама Кен Швабер. Мы также проиллюстрируем ключевые идеи этого подхода на примере реального большого Продукта, который разрабатывают более 200 человек.

Две проблемы масштабирования Скрама

Аджайл и Скрам становятся всё более востребованными для больших компаний и больших продуктов. Есть несколько известных подходов к тому, как «масштабировать Аджайл», то есть организовывать работу нескольких аджайловых команд над одним большим Продуктом, — это SAFe, LeSS, Нексус и другие. У каждого подхода есть свои особенности и свои преимущества.

Что касается Нексуса, он отражает практический опыт масштабирования создателя Скрама Кена Швабера и его сподвижников из организации Scrum.org. Этот опыт говорит о том, что при разработке большего Продукта существуют две самые болезненные проблемы:

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

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

Идея Нексуса очень проста: нужно дополнить Скрам несколькими простыми элементами, чтобы решить проблемы с зависимостями и интеграцией. Эти дополнительные элементы описаны в кратком и бесплатном Руководстве по Нексусу (Nexus Guide), доступном на сайте Scrum.org.

Давайте теперь рассмотрим обе проблемы на реальном примере.

Зависимости-киллеры

На схеме ниже изображён набор функциональных модулей реального Продукта для ритейл-домена, который разрабатывает распределённая интернациональная Команда из 200 человек. Размер каждого эллипса зависит от оценки трудоёмкости требований в данном модуле: чем больше трудоёмкость, тем больше эллипс. Два эллипса пересекаются, если между модулями есть зависимости: связанные требования, общий код и другие.

Схема функциональных модулей Продукта для ритейл-домена, в котором участвует 200 человек

Из схемы видно: компонент Order Management связан ещё с семью другими компонентами. Это значит, что Команда, которая разрабатывает Order Management, должна синхронизироваться с семью другими командами. И это не считая так называемых внешних зависимостей, связанных со специалистами, находящимися вне Команды. В жизни такие зависимости неоднократно приводили к простою команд, вынужденной работе над низкоприоритетными фичами, недостижению Цели Спринта и другим негативным последствиям. Особенно остро проблема ощущалась в начале разработки.

Нексус и Scaled Professional Scrum помогают справится с этими проблемами за счёт ряда практик:

• правильный выбор структуры команд, Бэклога Продукта и архитектурных решений, позволяющий минимизировать зависимости;
• расширение практики Product Backlog Refinement, которая из необязательной активности в Скраме становится обязательным событием с фокусом на минимизацию зависимостей и кросс-командное взаимодействие;
• обнаружение, визуализация и минимизация зависимостей во время Планирования Спринта.

Прочитать про это подробнее можно в Руководстве по Нексусу и на страничке Scrum.org/Nexus.

Ужас интеграции

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

Каждый, кто участвовал в разработке, понимает, насколько это сложная задача. Часто команды не могут довести даже небольшой Продукт к концу Спринта до состояния Done. А здесь и команд много, и сложность задачи увеличивается многократно. Как обеспечить решение этой задачи? Кто должен нести за это ответственность?

Для решения этой важнейшей задачи в Нексусе добавляется специальная роль — Nexus Integration Team.

Схема Команды Интеграции в Нексусе

Эта новая Команда в основном состоит из представителей команд разработки и, несмотря на название, её задачей не является «руками» интегрировать Продукт вместо отдельных команд. Nexus Integraion Team отвечает (Accountable) за внедрение инженерных и процессных практик, которые позволят иметь общий Интегрированный Инкремент как минимум в конце каждого Спринта.

Вот лишь некоторые из активностей, в которые вовлечены члены Команды Интеграции из нашего реального примера:

• фасилитация выработки и внедрения общих инженерных практик;
• фасилитация выработки и внедрения общей архитектуры, CI/CD, DevOps инфраструктуры;
• помощь командам с разрешением зависимостей (особенно внешних, блокеров);
• фасилитация долгосрочного планирования с учётом зависимостей.

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

При этом крайне важно, чтобы Команда Интеграции не принимала решения за команды, не делала их работу и никаким другим способом не препятствовала самоорганизации команд. Научиться держать эту тонкую грань можно на тренинге Scaled Professional Scrum with Nexus.

Что осталось за кадром

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

Официальная визуализация Нексуса

Большинство людей, знакомых со Скрамом, при виде этой картинки воскликнут: «Да это же просто… Скрам!» И они правы, Нексус — это Скрам, в котором участвуют 3–9 команд (если больше, нужно несколько связанных Нексусов). При этом в процесс добавлено несколько дополнительных элементов, самые важные из которых мы уже упомянули выше.

Таким образом, Нексус — легковесный фреймворк, основанный на Скраме. Именно поэтому он прекрасно сочетается с LeSS, другим фреймворком для масштабирования Скрама. Кроме того, LeSS содержит массу полезных руководящих указаний и экспериментов, которые можно и нужно использовать в контексте Нексуса.

Нексус для масштабирования Скрама

Суммируем то, что мы узнали из статьи:

1. При масштабировании возникают проблемы, которых нет при «однокомандной» разработке: зависимости и сложность интеграции.
2. Нексус помогает решать эти проблемы за счёт добавления нескольких новых элементов в дополнение к обычным правилам Скрама. Эти новые элементы описаны в кратком Руководстве по Нексусу.
3. Нексус отлично сочетается с LeSS, так как оба основаны на правильном Скраме, а эксперименты из LeSS помогают дополнить Нексус конкретными практиками.
4. При масштабировании возрастает важность инженерных практик и автоматизации.
5. Наш реальный опыт внедрения Нексуса показал, что даже продуктовая группа из 200 человек может иметь Production-Ready версию Продукта как минимум раз в неделю.