Привет! Меня зовут Артем, я технический лидер в крупной it компании РФ. Расскажу как использовал nexus framework для масштабирования команд разработки.

Проекты не стоят на месте, команды разрастаются, а управление ими, по словам Джеффа Безоса, — это искусство, требующее постоянного совершенствования. Поэтому, когда команда вырастает за пределы 15 человек и накормить ее двумя пиццами становится невозможно, приходится искать новые способы для масштабирования Scrum и эффективной организации работы.

Для этих целей мы внедрили Nexus Framework — он создан для многокомандной разработки, достаточно популярен и используется в таких компаниях, как Spotify, Siemens, Bosch, Volkswagen, SAP и многих других.

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

Про Nexus в двух словах

Nexus — это фреймворк, разработанный Кеном Швабером, органичное и эволюционное расширение классического Scrum для крупных проектов с многокомандной разработкой. Он основан на знакомых принципах Scrum — ролях, артефактах и событиях, — но дополняет их специальными элементами для выявления зависимостей между командами и управления. Так можно сохранять фокус на продукте, даже когда над ним одновременно работает несколько команд.

Что мы имеем на входе:

• масштабный проект с большим количеством модулей;

• команда разработки около 20 человек со сложной координацией и управлением;

• сложно выделить отдельные доменные зоны в проекте.

Почему мы выбрали Nexus

Традиционный Scrum не справлялся с масштабированием, а Nexus предложил структурированный подход к управлению зависимостями между командами. При выборе мы опирались на эти критерии:

• продукт остается один — разрабатывается единый продукт из нескольких модулей;

• проект сложно масштабировать — количество участников команды постоянно увеличивается;

• сложность разделения — полной сепарации команд и разделения не требуется

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

Что предлагает методология фреймворка Nexus

Разделение на несколько команд. В Nexus проект масштабируется через работу нескольких Scrum‑команд — их может быть больше двух, в зависимости от размера и сложности продукта. Каждая команда берёт на себя часть задач из общего бэклога, исходя из специализации и зон ответственности. При этом команды остаются слабо связанными, чтобы минимизировать пересечения и работать эффективнее.

Создание Nexus Integration Team. Это команда интеграции, которая отвечает за координацию работы всех Scrum‑команд в Nexus. Её задача — управлять зависимостями между командами, обеспечивать быстрый обмен информацией и следить за тем, чтобы все команды двигались в одном направлении и создавали единый инкремент продукта.

Изменение процессов. Внедряются новые процессы, которые улучшат координацию и коммуникацию между командами. Например, регулярные встречи, совместное планирование

Что такое команда NIT и чем она занимается

Nexus Integration Team (NIT) занимается координацией, коучингом и контролем применения Nexus и работы Scrum. Она обеспечивает прозрачную ответственность за интеграцию среди Scrum‑команд в Nexus. NIT состоит из Product Owner, Scrum Master и членов команды интеграции. В нашем случае в постоянный состав NIT входят:

• архитектор продукта;

• технический лидер;

• DevOps

• менеджер продукта.

На некоторые встречи мы приглашаем лидов команд или специалистов QA и ИБ.

Основная задача NIT‑ устранять проблемы, которые влияют на несколько команд. Вот примеры задач, которыми занимается NIT:

Чтобы Nexus Integration Team и остальные команды эффективно работали и могли выполнять задачи в срок, необходимо внедрять дополнительные церемонии.

Церемонии в Nexus

Согласно принципам Nexus, каждая команда остаётся независимой, но при этом тесно сотрудничает с другими командами в рамках общего проекта.

Мы организовали работу таким образом, чтобы сократить дублирование задач, сохранить гибкость, избежать несогласованности действий и вместе с тем бесконечных согласований, а также не потерять управляемость. Для этого оставили Scrum‑основу, но добавили специфические церемонии:

• Дейлики для Nexus Integration Team (NIT) — три раза в неделю. Встречи для синхронизации работы команд и задач, связанных с интеграцией. На них важно вовремя выявлять и устранять проблемы, а также координировать усилия всех участников.

• Sprint Review — Проводим обзор совместно с командами. Готовимся к нему тоже вместе, чтобы создать полное представление о результатах и обсудить дальнейшие шаги. Это важно для оценки прогресса и принятия решений на основе общего контекста. Проводим в конце каждого спринта.

• Sprint Retrospective — Проводим для всех команд. Учитываем влияние команд друг на друга, анализируем взаимодействие и ищем возможности для улучшения. Периодичность церемонии 1 раз в два спринта.

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

Предварительное планирование спринта — для формирования общих целей и задач предстоящего спринта. Распределяем задачи между командами с учетом их емкости и возможностей. Это помогает распределять нагрузку и эффективно использовать ресурсы.

Общий PBR — чтобы повысить прозрачность и взаимопонимание между командами. На этих встречах разработчики могут услышать разбор задач не только своей, но и смежной команды — это помогает заранее выявить пересечения, лучше понимать общий контекст и упрощает последующее кросс‑ревью pull request'ов.

Технические аспекты и процессы

Теперь, когда мы определились с составом команд и церемониями, важно также уделить внимание техническим аспектам проекта. Как организовать инфраструктуру, процессы тестирования, формирование релизов и другое?

Инфраструктура. Для каждой команды разворачиваем отдельные среды для разработки и тестирования. В нашем случае локальная разработка ведется с помощью docker‑compose, а для тестирования приложение разворачивается на стенде с deckhouse.

Структура репозиториев. Оставлять один репозиторий или делать на несколько — вопрос философский, у каждого подхода есть свои минусы и плюсы. Мы выбрали остаться в одном репозитории. Мастер‑ветка осталась единой, команды отгибают фич‑ветки и работают там, далее у каждой команды есть свой отдельный стенд для тестирования.

Такой подход удобен и прост, но есть и свои недостатки:

• команды вынуждены часто делать ребайзы из‑за pull request'ов других команд;

• существует риск, что одна команда может нарушить функционал другой.

Можно выбрать вариант с тремя мастер‑ветками, двумя локальными мастерами и одним основным. Выглядит это следующим образом:

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

Актуализация PR по цели. Чтобы избежать частых ребайзов при новых слияниях в мастер, выстраиваем на доске приоритет User Stories (US) таким образом, чтобы разработчик понимал, когда подходит его очередь, и актуализировал PR в нужный момент. Также специалист QA предупреждает разработчика о том, что PR нужно актуализировать. Конечно, никто не запрещает ему делать это после каждого изменения в мастере, если это необходимо.

Разграничение зон ответственности. User Stories (US) формируются так, чтобы не затрагивать функциональность других частей системы. Если требуется общая доработка, тогда подключается NIT для координации и интеграции изменений.

Организация документации и архитектуры. На проекте применяются подходы docs as code и architecture as code. Для удобства мы вынесли их в отдельный репозиторий. Это позволяет поддерживать документацию и архитектуру в актуальном состоянии и упрощает их обновление. Доступ есть у всех участников команды.

Стенды. У каждой команды есть свой стенд для тестирования, но для демонстрации заказчику и полноценного тестирования перед релизом нужен единый стенд. На нем специалист QA проводит полную проверку по графику дежурств.

Процесс работы с задачами

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

• задачи в спринте — задачи попадают в спринт после приоритизации и согласования с командой;

• анализ — анализируем требования, выявляем необходимые детали и возможные риски;

• дизайн — разрабатываем дизайн, если это нужно;

• план тестирования — формируем план тестирования, который включает все проверки качества;

• уточнение деталей реализации — уточняем технические детали и требования;

• разработка — команда приступает к разработке задачи;

• на подтверждении — задача висит на PR;

• тестирование — задача в работе у специалиста QA;

• документирование — задача документируется и добавляется информация в пользовательскую инструкцию

• закрытая — задача закрывается после успешного прохождения всех этапов и подтверждения качества.

Впрочем разделы достаточно стандартные, интересный момент заключается, что у NIT появляется своя доска с задачами.

Сложности и их решения

Вот несколько ситуаций, с которыми мы столкнулись, и практические решения.

Несогласованность фич в разных командах. Чтобы визуализировать зависимости и лучше координировать работу команд, мы начали создавать карты фич. Карты помогают отслеживать, какие фичи зависят друг от друга, и эффективно планировать их реализацию. Такую карту полезно формировать на планировании спринта NIT.

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

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

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

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

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

Подобные графики мы составляем не только для работы с обращениями пользователей, но для релизов.

Проверка PR перед публикацией. При создании PR разработчик обязан заполнить шаблон для самопроверки — в нем перечислены обязательные условия для каждого PR.

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

Какие мы используем метрики

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

• Cycle time — сколько времени проходит от начала работы над фичей с этапа анализа до её завершения. Помогает оценить скорость доставки и находить задержки в процессе.

• Capacity — сколько задач (User Stories) команда планировала на спринт и сколько реально выполнила. Показывает реалистичность планирования и загрузку команды.

• WIP (Work in Progress) — количество задач в работе одновременно. Чем выше показатель, тем выше риск расфокусировки. Оптимально — не более 1–2 задач на разработчика.

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

Применение искусственного интеллекта

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

Написание unit‑тестов

Для этой задачи мы используем open source модели AI, аналогами которых являются Mistral и DeepSeek и т. д. Они помогают генерировать тесты для новых функций, обновлять существующие при изменении кода и обеспечивать высокое покрытие кода тестами.

Ревью кода

С ростом объема Pull Requests процесс ревью кода стал занимать больше времени, поэтому теперь мы применяем модели AI для автоматического анализа кода. Они выявляют наиболее очевидные ошибки и потенциальные проблемы, поддерживают высокий уровень качества. Процесс ревью ускорился, а разработчики могут сосредоточиться на более сложных аспектах кода.

Раньше мы использовали модели искусственного интеллекта для ревью кода вручную: копировали, вставляли и добавляли комментарии. Теперь этот процесс автоматизирован на этапе CI. Пайплайн CI запускает модель, развернутую на нашей виртуалке dev стенда, и полученные комментарии от AI автоматически добавляются к PR.

Написание Docker‑файлов и конфигураций

Нейронные сети также помогают автоматизировать написание Docker‑файлов и различных файлов конфигурации. Это включает генерацию Dockerfile для новых проектов, настройку конфигурационных файлов (например,.env,.yaml,.json) и оптимизацию существующих конфигураций на основе лучших практик.

Оценка размера задач и емкости команды разработки

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

База знаний 

Базу знаний мы решили вести в отдельном репозитории. Что в ней хранится:

• Постановки задач и аналитика. Мы используем подход docs as code для отображения документации. Это позволяет поддерживать ее в актуальном состоянии и упрощает обновление.

• Архитектурные схемы. Вся архитектура проекта хранится в виде кода. Для описания архитектуры используется подход C4. Это обеспечивает наглядность и понятность архитектурных решений.

• Технический дизайн. Для описания технического дизайна мы используем UML‑диаграммы. Это помогает визуализировать структуру системы и взаимодействие её компонентов.

Также мы ведем записи архитектурных решений (ADR), чтобы фиксировать их контекст и последствия. Это помогает сделать понимание архитектуры и ее поддержку проще.

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

Так выглядит процесс работы с базой знаний:

Заключение

Внедрение Nexus Framework стало для нас не радикальной трансформацией, а разумной настройкой существующих процессов. Мы масштабировали разработку без разрушения текущей структуры, сохранили целостность продукта и темп работы. Да, Nexus не избавил нас от всех вызовов — где‑то пришлось добавить новых церемоний, где‑то договориться заново. Но он помог навести порядок там, где хаос был вполне ожидаем.

Плюсы:

• легкая интеграция в текущие процессы разработки;

• минимум накладных расходов при внедрении;

• сохранение производительности команд.

Минусы:

• изменения одной команды могут влиять на другую команду;

• дополнительные церемонии, которые тратят рабочее время.

Рекомендации:

• добавить дополнительный этап планирования, чтобы разделить зоны ответственности между командами;

• создать NIT и наладить в ней дейли‑синхронизации;

• ввести дежурства, чтобы не нагружать постоянно одних и тех же участников команды нецелевыми задачами;

• организовать процесс кросс‑ревью и зафиксировать правила синхронизации между командами;

• сформировать актуальную базу знаний;

• использовать метрики для анализа эффективности команд и поиска точек роста;

• использовать ИИ для автоматизации рутинных задач.

Если вы стоите перед задачей масштабирования Scrum‑команд, хотите сохранить гибкость и не перегружать процессы — Nexus может стать тем самым лёгким решением, которое работает. Главное — подходить к внедрению осознанно и поэтапно. А также помните: ни один фреймворк не решит все проблемы, но правильный инструмент поможет выстроить то, что работает именно у вас.