Proscrum
Масштабируем Scrum с помощью Nexus
Артем Колышкин
Константин Разумовский
Константин Разумовский
В этой статье мы кратко расскажем про Nexus – подход для масштабирования Scrum, предложенный создателем Scrum Кеном Швабером. Мы также проиллюстрируем ключевые идеи этого подхода на примере реального большого продукта, который разрабатывают более 200 человек, используя Scrum и Nexus.
Две проблемы
Agile и Scrum становятся все более востребованными для больших компаний и больших продуктов. Есть несколько известных подходов к тому, как «масштабировать Agile», то есть организовывать работу нескольких Agile-команд над одним большим продуктом, – SAFe, LeSS, Nexus и другие. У каждого подхода есть свои особенности и свои преимущества.
Что касается Nexus - он отражает практический опыт масштабирования создателя Scrum Кена Швабера и его сподвижников из организации Scrum.org. Этот опыт в частности говорит о том, что при разработке большого продукта существуют две самые болезненные проблемы:
⦁ Зависимости. Они приводят к тому, что команды ожидают или даже блокируют друг друга, ломают чужой код, замедляя друг друга и т.д.
⦁ Интеграция. По отдельности команды могут создавать работающий код, но продукт в целом может при этом быть не работоспособным.
Важно отметить, что эти 2 проблемы в принципе отсутствуют, если над продуктом работает только одна команда. Проблемы возникают именно при масштабировании. Однако фреймворк Scrum, определенный в Руководстве по Scrum, практически ничего не говорит о таких «масштабированных» ситуациях.
Идея Nexus очень проста: нужно дополнить Scrum несколькими простыми элементами, помогающими прежде всего решить две упомянутые проблемы. Эти дополнительные элементы описаны в Nexus Guide – кратком бесплатном руководстве, доступном на сайте Scrum.org.
Давайте теперь рассмотрим обе проблемы на реальном примере.
Что касается Nexus - он отражает практический опыт масштабирования создателя Scrum Кена Швабера и его сподвижников из организации Scrum.org. Этот опыт в частности говорит о том, что при разработке большого продукта существуют две самые болезненные проблемы:
⦁ Зависимости. Они приводят к тому, что команды ожидают или даже блокируют друг друга, ломают чужой код, замедляя друг друга и т.д.
⦁ Интеграция. По отдельности команды могут создавать работающий код, но продукт в целом может при этом быть не работоспособным.
Важно отметить, что эти 2 проблемы в принципе отсутствуют, если над продуктом работает только одна команда. Проблемы возникают именно при масштабировании. Однако фреймворк Scrum, определенный в Руководстве по Scrum, практически ничего не говорит о таких «масштабированных» ситуациях.
Идея Nexus очень проста: нужно дополнить Scrum несколькими простыми элементами, помогающими прежде всего решить две упомянутые проблемы. Эти дополнительные элементы описаны в Nexus Guide – кратком бесплатном руководстве, доступном на сайте Scrum.org.
Давайте теперь рассмотрим обе проблемы на реальном примере.
Проблема №1
Зависимости-киллеры.
Зависимости-киллеры.
На картинке ниже Вы можете видеть набор функциональных модулей реального большого продукта для retail-домена, который разрабатывает распределенная интернациональная команда, состоящая из более чем 200 человек. Размер каждого эллипса зависит от оценки трудоемкости требований в данном модуле: чем больше трудоемкость – тем больше эллипс. Два эллипса пересекаются, если между соответствующими модулями есть зависимости: связанные требования, общий код, и др.
Как видно из картинки, команде, работающей, например, над компонентом Order Management, необходимо как минимум координировать свою работу с командами, работающими над 7 другими связанными компонентами. И это не считая так называемых внешних зависимостей, связанных со специалистами, находящимися вне продуктовой команды. В нашем реальном кейсе такие зависимости неоднократно приводили (особенно в начале разработки) к простою команд, вынужденной работе над низкоприоритетным фичами, недостижению целей Спринта и другим негативным последствиям.
Nexus и Scaled Professional Scrum помогают справиться с этими проблемами за счет ряда практик, в частности:
⦁ Правильный выбор структуры команд, Бэклога продукта и архитектурных решений, позволяющий минимизировать зависимости
⦁ Расширение практики Product Backlog refinement, которая из необязательной активности в Scrum становится обязательным событием с фокусом на минимизацию зависимостей и кросс-командное взаимодествие
⦁ Обнаружение, визуализация и минимизация зависимостей во время планирования спринта
Прочитать про это подробнее можно в Nexus Guide и на страничке Scrum.org/Nexus. Познакомиться с этим на практике лучше всего на тренинге Scaled Professional Scrum with Nexus.
Nexus и Scaled Professional Scrum помогают справиться с этими проблемами за счет ряда практик, в частности:
⦁ Правильный выбор структуры команд, Бэклога продукта и архитектурных решений, позволяющий минимизировать зависимости
⦁ Расширение практики Product Backlog refinement, которая из необязательной активности в Scrum становится обязательным событием с фокусом на минимизацию зависимостей и кросс-командное взаимодествие
⦁ Обнаружение, визуализация и минимизация зависимостей во время планирования спринта
Прочитать про это подробнее можно в Nexus Guide и на страничке Scrum.org/Nexus. Познакомиться с этим на практике лучше всего на тренинге Scaled Professional Scrum with Nexus.
Проблема №2
Ужас интеграции
Ужас интеграции
Давайте вернемся к нашей retail-компании и ее продукту. Более 20 команд непрерывно добавляют новый код в общий репозиторий, забирают из него свежий код коллег, пересобирают продукт, тестируют, исправляют баги, показывают продукт представителям бизнеса, снова пишут код. И при всем этом в конце каждой недели (да-да, спринты здесь недельные!) необходимо иметь полностью интрегрированную production-ready версию продукта. Всего продукта целиком, а не 20 отдельных кусочков!
Каждый, кто участвовал в разработке, понимает, насколько это тяжелая задача. Большинство реальных команд не в состоянии довести даже небольшой продукт к концу спринта до состояния Done. А здесь команд много, и сложность задачи увеличивается многократно. Как обеспечить решение этой задачи? Кто должен нести за это ответственность?
Для решения этой важнейшей задачи в Nexus добавляется
специальная роль – Nexus Integration Team.
Каждый, кто участвовал в разработке, понимает, насколько это тяжелая задача. Большинство реальных команд не в состоянии довести даже небольшой продукт к концу спринта до состояния Done. А здесь команд много, и сложность задачи увеличивается многократно. Как обеспечить решение этой задачи? Кто должен нести за это ответственность?
Для решения этой важнейшей задачи в Nexus добавляется
специальная роль – Nexus Integration Team.
Эта новая команда в основном состоит из представителей команд разработки и несмотря на название, ее задачей не является «руками» интегрировать продукт вместо отдельных команд. Nexus Integraion Team отвечает (accountable) за внедрение инженерных и процессных практик, которые позволят иметь общий интегрированный инкремент как минимум в конце каждого спринта.
Вот лишь некоторые из активностей, в которые вовлечены члены интеграционной команды из нашего реального примера:
- Фасилитация выработки и внедрения общих инженерных практик
- Фасилитация выработки и внедрения общей архитектуры, CI/CD, DevOps инфраструктуры
- Помощь командам с разрешением зависимостей (особенно внешних, блокеров)
- Фасилитация долгосрочного планирования с учетом зависимостей
Как видно из примера, значительная часть действий направлена на достижение инженерного совершенства, и это не случайно: важность хороших технических практик и автоматизации при масштабировании значительно возрастает!
При этом крайне важно, чтобы интеграционная команда не принимала решения за команды, не делала за них их работу и никаким другим способом не препятствовала самоорганизации команд. Опять-таки, узнать про эту тонкую грань подробнее можно на тренинге Scaled Professional Scrum with Nexus.
Вот лишь некоторые из активностей, в которые вовлечены члены интеграционной команды из нашего реального примера:
- Фасилитация выработки и внедрения общих инженерных практик
- Фасилитация выработки и внедрения общей архитектуры, CI/CD, DevOps инфраструктуры
- Помощь командам с разрешением зависимостей (особенно внешних, блокеров)
- Фасилитация долгосрочного планирования с учетом зависимостей
Как видно из примера, значительная часть действий направлена на достижение инженерного совершенства, и это не случайно: важность хороших технических практик и автоматизации при масштабировании значительно возрастает!
При этом крайне важно, чтобы интеграционная команда не принимала решения за команды, не делала за них их работу и никаким другим способом не препятствовала самоорганизации команд. Опять-таки, узнать про эту тонкую грань подробнее можно на тренинге Scaled Professional Scrum with Nexus.
Что осталось за кадром?
В рамках небольшой статьи невозможно осветить все нюансы Nexus. Но ручаемся, за кадром осталось не так уж и много. Действительно, взглянем на официальную визуализацию Nexus ниже.
Большинство людей, знакомых со Scrum, при виде этой картинке воскликнут: да это же просто… Scrum. И они правы. Nexus - это Scrum, в котором участвуют 3-9 команд (если больше – нужно несколько связанных «Нексусов»). При этом в Scrum-процесс добавлено несколько дополнительных элементов, самые важные из которых мы уже упомянули выше.
Таким образом, Nexus – легковесный фреймворк, основанный на Scrum. Кстати, именно поэтому он прекрасно сочетается с LeSS, который также основан на Scrum, а кроме того содержит в себе массу полезных руководящих указаний (guides) и экспериментов, которые можно и нужно использовать в контексте Nexus.
Таким образом, Nexus – легковесный фреймворк, основанный на Scrum. Кстати, именно поэтому он прекрасно сочетается с LeSS, который также основан на Scrum, а кроме того содержит в себе массу полезных руководящих указаний (guides) и экспериментов, которые можно и нужно использовать в контексте Nexus.
Так почему Nexus?
Суммируем то, что мы узнали из статьи.
⦁ При масштабировании возникают новые проблемы, которых нет при «однокомандной» разработке: прежде всего зависимости и сложность интеграции.
⦁ Nexus помогает решать эти проблемы за счет добавления нескольких новых элементов в дополнение к обычным правилам Scrum. Эти новые элементы описаны в коротком документе Nexus Guide – Руководстве по Nexus.
⦁ Nexus отлично сочетается с LeSS, так как оба основаны на правильном Scrum, а эксперименты из LeSS помогают дополнить Nexus-фреймворк конкретными практиками.
⦁ При масштабировании возрастает важность инженерных практик и автоматизации.
⦁ Наш реальный опыт внедрения Nexus показал, что даже продуктовая группа из двухсот человек может иметь production-ready версию продукта как минимум каждую неделю.
⦁ При масштабировании возникают новые проблемы, которых нет при «однокомандной» разработке: прежде всего зависимости и сложность интеграции.
⦁ Nexus помогает решать эти проблемы за счет добавления нескольких новых элементов в дополнение к обычным правилам Scrum. Эти новые элементы описаны в коротком документе Nexus Guide – Руководстве по Nexus.
⦁ Nexus отлично сочетается с LeSS, так как оба основаны на правильном Scrum, а эксперименты из LeSS помогают дополнить Nexus-фреймворк конкретными практиками.
⦁ При масштабировании возрастает важность инженерных практик и автоматизации.
⦁ Наш реальный опыт внедрения Nexus показал, что даже продуктовая группа из двухсот человек может иметь production-ready версию продукта как минимум каждую неделю.