Nexus Framework — официальный фреймворк масштабирования Scrum от Scrum.org для 3-9 Scrum-команд, работающих над ОДНИМ общим бэклогом продукта для создания единого интегрированного инкремента как минимум раз в каждый спринт, — сам Кен Швабер описывает Nexus как «экзоскелет Scrum»: минимальное дополнение к базовому фреймворку (см. отдельную статью про Agile/Scrum), а не полностью новая, самостоятельная методология масштабирования.
Происхождение и исследовательская база
Nexus Framework создан Кеном Швабером, сооснователем Scrum, и выпущен его организацией Scrum.org вместе с «Nexus Guide» в 2015 году, впоследствии обновлённым в 2018 и 2021 годах. Фреймворк разработан как ответ на растущую потребность крупных организаций масштабировать Scrum на несколько команд, работающих над единым продуктом, при этом сохраняя минимальность и целостность оригинального Scrum-фреймворка вместо создания принципиально новой, тяжеловесной методологии.
Ключевое структурное дополнение Nexus к базовому Scrum: единая новая роль — Nexus Integration Team (команда интеграции Nexus) — отвечающая за координацию, инструменты и практики, необходимые для создания интегрированного инкремента; расширенные версии стандартных Scrum-событий — Nexus Sprint Planning, Nexus Daily Scrum, Nexus Sprint Review, Nexus Sprint Retrospective — на межкомандном уровне, дополняющие, а не заменяющие внутрикомандные версии тех же событий; и явный артефакт Nexus Sprint Backlog, объединяющий работу всех команд-участниц спринта.
Ключевой принцип минимальности: Nexus расширяет базовый Scrum только там, где это абсолютно необходимо для координации нескольких команд вокруг общего бэклога и общего интегрированного инкремента — фреймворк намеренно избегает добавления избыточной организационной структуры или процессов там, где стандартный Scrum-фреймворк уже достаточен для отдельной команды.
Ключевые идеи и принципы
Принцип: интеграция продукта должна происходить непрерывно, а не только в конце спринта.
Nexus явно требует, чтобы команды регулярно интегрировали свою работу в течение спринта, а не откладывали интеграцию на финальный день — раннее выявление интеграционных конфликтов между командами критично для создания реально работающего единого инкремента к концу каждого спринта.
Принцип: команда интеграции Nexus фокусируется на процессе, а не подменяет собой работу команд.
Роль Nexus Integration Team — обеспечивать наличие необходимых инструментов, практик и координационных процессов для интеграции, а не выполнять саму разработческую работу вместо отдельных Scrum-команд — команда интеграции координирует, а не централизует исполнение.
Принцип: единый бэклог продукта — основа координации между командами.
Все команды-участницы Nexus работают из одного, общего бэклога продукта, а не из изолированных, самостоятельно управляемых бэклогов — это обеспечивает единую приоритизацию и предотвращает ситуацию, когда разные команды независимо работают над несовместимыми или дублирующими направлениями.
Ограничения, слепые зоны и критика
Nexus рассчитан на диапазон примерно 3-9 команд, работающих над одним продуктом — при значительно большем числе команд (десятки) фреймворк не масштабируется напрямую, требуя либо иерархической структуры из нескольких Nexus-групп, либо перехода к более комплексным фреймворкам масштабирования (SAFe, LeSS) с иной архитектурой.
Требование единого общего бэклога продукта предполагает, что работа команд действительно тесно связана вокруг одного продукта — для организаций с относительно независимыми продуктовыми направлениями, требующими лишь редкой координации, более лёгкая техника вроде Scrum of Scrums (см. отдельную статью) может быть достаточной без полной формализации Nexus.
Дополнительная роль Nexus Integration Team и расширенные межкомандные события создают дополнительную управленческую и координационную нагрузку по сравнению с работой одной отдельной Scrum-команды — организации с малым числом команд должны оценить, оправдывает ли реальная сложность интеграции эту дополнительную структуру.
Типовые ошибки
Ошибка 1: откладывают интеграцию работы команд на конец спринта вместо непрерывной интеграции.
Команды работают изолированно весь спринт, обнаруживая интеграционные конфликты только в последний день, что срывает создание единого работающего инкремента к концу спринта.
Как избежать: внедрять практику непрерывной интеграции работы команд в течение всего спринта, а не только в его завершении.
Ошибка 2: превращают команду интеграции Nexus в централизованного исполнителя вместо координатора процесса.
Nexus Integration Team начинает выполнять разработческую работу вместо отдельных команд, подменяя их автономию и создавая узкое место в процессе.
Как избежать: явно ограничивать роль команды интеграции координацией процессов и инструментов, оставляя исполнение работы отдельным Scrum-командам.
Ошибка 3: применяют Nexus при масштабе, для которого фреймворк не рассчитан (десятки команд).
Организация пытается применить Nexus к значительно большему числу команд, чем предусмотренный диапазон 3-9, что приводит к неуправляемой сложности координации.
Как избежать: при значительном превышении диапазона рассматривать иерархическую структуру из нескольких Nexus-групп или переход к более комплексным фреймворкам масштабирования.
Главное, что нужно знать
Nexus Framework (Кен Швабер, Scrum.org, 2015) — официальный фреймворк масштабирования Scrum для 3-9 команд с единым бэклогом продукта.
Описан автором как «экзоскелет Scrum» — минимальное расширение, а не новая методология.
Ключевое дополнение: роль Nexus Integration Team и расширенные межкомандные версии стандартных Scrum-событий.
Все команды работают из ОДНОГО общего бэклога продукта для единой приоритизации.
Не масштабируется напрямую за пределы диапазона 3-9 команд — для большего масштаба нужны иные фреймворки.
План внедрения
Неделя 1: сформировать единый бэклог продукта для всех команд-участниц
Объединить работу команд вокруг одного общего, приоритизированного бэклога продукта.
Неделя 2: сформировать команду интеграции Nexus
Назначить представителей команд в Nexus Integration Team для координации интеграционных процессов и инструментов.
Неделя 3: внедрить расширенные межкомандные версии Scrum-событий
Настроить Nexus Sprint Planning, Nexus Daily Scrum, Nexus Sprint Review и Retrospective на межкомандном уровне.
Неделя 4: наладить практику непрерывной интеграции в течение спринта
Обеспечить регулярную, а не только финальную интеграцию работы команд для раннего выявления конфликтов.
Далее: оценка необходимости дальнейшего масштабирования — при росте числа команд за пределы диапазона Nexus оценить переход к более комплексным фреймворкам масштабирования.
Как реализовать этот план с помощью фрейма «Nexus Framework» в OrgDevTools
Фрейм состоит из четырёх карточек на вкладке «Карточки», каждая соответствует одной неделе плана внедрения выше.
Неделя 1 — карточки «Единый бэклог продукта» и «Проверка соответствия масштабу 3-9 команд». Сюда вносится общий приоритизированный бэклог для всех команд, с явной проверкой, что число команд укладывается в диапазон 3-9 — применение Nexus при десятках команд прямо повторяет ошибку 3.
Неделя 2 — карточка «Nexus Integration Team — координация, не исполнение». Сюда вносится, как команда интеграции обеспечивает инструменты и процессы, не подменяя разработческую работу команд — превращение её в централизованного исполнителя прямо повторяет ошибку 2.
Неделя 3-4 — карточка «Непрерывная интеграция в течение спринта». Сюда вносится, как расширенные межкомандные версии Scrum-событий (неделя 3) обеспечивают регулярное объединение работы команд (неделя 4) — откладывание интеграции на финальный день спринта прямо повторяет ошибку 1.
Вкладка «Итоги» явно предупреждает, если интеграция откладывается на конец спринта или масштаб выходит за диапазон 3-9 команд. Кнопка создания задачи формирует задачу «Обеспечить непрерывную интеграцию вокруг единого бэклога, удерживая Nexus в пределах масштаба».