Nexus framework что это

Обновлено: 06.07.2024

Расскажем об особенностях методологии и её основных компонентах.

Кто и зачем создал Nexus

В 1996 году разработчики Кен Швабер (Ken Schwaber) и Джефф Сазерленд (Jeffrey Sutherland) представили сообществу методологию гибкой разработки ПО Scrum. Она представляет собой набор строго ограниченных по времени итераций (спринтов), за которые разработчики должны реализовать новые функции для программы.

Как отмечает Джефф Сазерленд, в своей книге «Scrum. Революционный метод управления проектами», Scrum позволяет командам разработки добиваться «сверхэффективности» и увеличивать производительность труда на 300%.

Однако Scrum имеет недостаток — он хорошо подходит для работы в пределах одной команды (причем рекомендованное количество её участников составляет всего семь человек), но плохо «масштабируется» за её пределы — когда нужно скоординировать работу большого числа людей.

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

Компоненты Nexus

Фреймворк состоит из знакомых любому адепту Scrum ролей, событий, артефактов, а также правил, которые это всё объединяют. В Nexus эти составляющие немного изменили, чтобы методологию можно было применять в масштабных проектах.

Роли. По методике Scrum всем участникам процесса разработки назначаются определённые роли. Их можно разделить на две большие группы — «свиней» и «кур». В первую входят все те, кто имеет непосредственное отношение к созданию приложения: скрам-мастер (Scrum Master), который проводит совещания и следит за соблюдением принципов скрама, владелец продукта (Product Owner), представляющий интересы конечных пользователей, и, собственно, команда разработки (Development Team).

Ко второй группе — «курам» — относятся конечные пользователи, продавцы, консультанты и др.

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

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

Артефакты. В Scrum под артефактами понимают набор требований к функциональности продукта, которые помогают организовать деятельность разработчиков. Эти требования описаны в двух журналах: журнале пожеланий проекта (project backlog) и журнале пожеланий спринта (sprint backlog).

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

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

В Nexus вместо журнала пожеланий проекта команды используют журнал пожеланий продукта (Product Backlog). Для упрощения взаимодействия большого количества разработчиков, этот журнал разбивают на части. Каждая часть «закрепляется» за одной из команд. Так, все разработчики понимают, какими задачами из всего проекта они занимаются. При этом каждая команда по-прежнему ведет свой журнал пожеланий спринта.

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

Для улучшения коммуникации между разными командами разработчики Nexus добавили четыре новых вида событий:

Nexus Sprint Planning — в это время команды решают, кто лучше справится с конкретным спринтом из Product Backlog. После этого каждая команда планирует свой спринт, общаясь с другими скрам-командами, чтобы их задачи не пересекались.
Nexus Daily Scrum — используется для обсуждения текущего положения дел. Позволяет составить план на день или решить проблемы интеграции.
Nexus Sprint Review — здесь команды делятся своими успехами по итогам каждого спринта.
Nexus Retrospective — это время тратится на оценку прошлого опыта и составление плана для улучшения процесса разработки в будущем.

На странице официального гайда по Nexus можно найти схему взаимодействия и последовательности всех этих событий.

Когда стоит использовать Nexus

В масштабных проектах. Фреймворк помогает «бесшовно» организовать работу нескольких скрам-команд в крупных проектах. К примеру, одна индийская компания, создающая security-софт (авторы Scrum не раскрыли её название), год использовала Scrum для разработки своих продуктов. Поначалу в компании была одна скрам-команда, однако вскоре их число увеличилось до трех, и начались проблемы с интеграцией отдельных решений.

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

Тогда в компании решили попробовать Nexus. Методика позволила сократить время выпуска релизов в три раза и выпускать продукт раз в три месяца.

Nexus помогает наладить взаимодействие и между командами, «раскиданными» по всем земному шару. «Ежедневных спринты» поддерживают высокий уровень коммуникации и вовлеченности сотрудников в проект.

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

Таким образом, Nexus подходит для работы над крупными проектами (по словам создателей методологии, она дает эффективно управлять девятью скрам-командами) и при грамотном применении помогает ускорить процесс разработки в 3–4 раза. Однако главным фокусом этой методологии является решение проблем с интеграцией, потому она не может помочь в решении других организационных вопросов в компании.

P.S. Пара свежих материалов из Первого блога о корпоративном IaaS:

P.S. Несколько публикаций из нашего Telegram-канала:

Добавить в избранное

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

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

К стандартным scrum-ролям добавляется новая — Nexus Integration Team, отвечающая за успешную интеграцию всех сделанных инкрементов и решение технических и нетехнических ограничений между командами.

Эта группа участников состоит из выбранных представителей команд, которые озвучивают интересы команды. Если рабочее время участников делится между NIT и командой разработчиков, то более приоритетна работа в Nexus Integration Team.

Состав интеграционной команды может меняться по необходимости.

События

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

Событие проходит в несколько этапов: сперва NIT разбивает содержимое бэклога на мелкие и независимые части до уровня, когда одна команда может закончить фичу за один спринт.

Затем выявляются и визуализируются все зависимости между фичами и командами. На этом этапе NIT определяет своеобразную «дорожную карту» фич и зависимостей: что и какой командой будет сделано, в каком спринте.

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

Планирование в Nexus также проходит этапами:

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

Классические три вопроса скрама для интеграционной команды трансформируются в:

Что было успешно интегрировано до сегодняшнего Daily Scrum?
Какие новые зависимости обнаружили?
Какую информацию нужно распространить среди команд сегодня?

Nexus Retrospective состоит из трёх частей:

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

Артефакты

Чтобы видеть целостную картину по продукту, Product Backlog всегда сохраняется в единственном числе, как и инкремент. В Nexus нет командных Sprint Review, и результатом спринта является сумма всего, сделанного командами — Integrated Increment по продукту. Помимо Sprint Backlog, добавляется новый артефакт — Nexus Sprint Backlog, который является набором фич для всех команд с указанными между ними зависимостями — своеобразным общим планом спринта, — и используется для отслеживания прогресса и ежедневного перепланирования по общему инкременту.

Definition of Done формируется NIT, пересматривается и поддерживается в актуальном состоянии после каждой ретроспективы. Команды могут дополнительно создавать свои DoD, но правила должны быть строже, чем у общего.

Масштабирование

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

Nexus предполагает работу над одним продуктом 3-9 команд. Существует еще Nexus+, представляющий собой следующий уровень надстройки над фреймворком (Nexus для Nexus-а), но стоит трижды подумать, прежде чем его применять. В какой-то момент количество времени, уходящее на менеджмент зависимостей, перевешивает пользу от добавления новых команд.

Single source control, continuous integration/build/test/deploy, use of SOLID principles, API’s, DevOps concepts и т.п. — чем больше масштабирование, тем большее количество техник и подходов необходимо использовать.

Product Owner отвечает за верхнеуровневое видение продукта, за стратегию, приоритезацию и определение ценности. В независимости от масштаба проекта, существует только один бэклог и один PO на продукт. Он или она может иметь помощников по ежедневными задачами: описывать критерии истории, разъяснять командам детали, обращаться за помощью к экспертам в какой-то доменной области. Но финальное слово по приоритезации остаётся за Product Owner.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Масштабированный скрам (Scaled Scrum) — это такой скрам, в котором много скрам-команд работают над одной системой или продуктом. Цель скрама, независимо от его масштаба, такова: создавать высококачественные, готовые к релизу версии продукта к концу каждого спринта.

Для этого есть великое множество фреймворков. Самые распространенные — SAFe, Less и Nexus, есть и другие. Кстати, вот статистические данные использования разных фреймворков масштабирования крупными организациями из отчета Scrum Master Trends 2019.

А сейчас мы поговорим о двух популярных фреймворках масштабирования скрама — SAFe и Nexus — и о том, чем они похожи и чем отличаются между собой.

Что такое Nexus и что такое SAFe

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

Nexus — это группа от трех до девяти скрам-команд, работающих вместе над одним продуктом. У Nexus один владелец продукта, управляющий единым бэклогом продукта, из которого берут задачи все скрам-команды.

Scaled Agile Framework® (SAFe) — это онлайн-база знаний проверенных, интегрированных принципов, практик и компетенций для масштабного внедрения Lean, Agile и DevOps.

Научитесь внедрять Nexus на тренинге Scaled Professional Scrum

У команд, работающих по SAFe, бэклоги разные, но есть также и один общий для всех — программный бэклог.

Дорожная карта для осуществления SAFe

Это глубокая тема, и начать ее изучать стоит с тренинга Leading SAFe

Это было вкратце, а теперь разберемся поподробнее.

Чем похожи Nexus и SAFe

Nexus — ART

Группа команд в Nexus очень похожа по составу с Agile Release Train (ART). И в SAFe, и в Scrum/Nexus она по сути является самоуправляемой командой самоорганизованных команд 😂 с парочкой ключевых ролей на уровне команды команд.

Следование принципам эмпиризма, самоуправление внутри ограничений, организация вокруг ценностей и потока

Теория Scrum подчеркивает эмпиризм и самоуправление в сочетании с Flow. Теоретическая база SAFe более обширна, но по сути похожа.

Lean/Agile-лидерство

И SAFe, и Scrum/Nexus подчеркивают необходимость в изменении стиля лидерства — в формировании лидеров, которые служат своим командам, обладают мышлением роста, подают пример, живут и дышат принципами и практиками Lean и Agile и стремятся к постоянному совершенствованию.

Спринт — итерация

SAFe выбирает термин «итерация», который больше напоминает экстремальное программирование (XP), но, если обратить внимание на детали, спринты и итерации вполне взаимозаменяемы.

Бэклог одного продукта — программный бэклог

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

Группа интеграции Nexus (NIT) — системная группа

Обе имеют похожую цель — включение интегрированного инкремента в конце каждой итерации/спринта для всех команд. Когда дело доходит до того, КАК работают эти команды, Nexus делает упор на коучинговую/вспомогательную роль, в то время как SAFe уделяет чуть больше внимания фактической работе с интеграцией. Подход NIT может быть крайне интересен системной группе SAFe ART.

Группа интеграции Nexus (NIT)

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

Скрам-мастер в NIT — RTE

Скрам-мастер в NIT выполняет роль, аналогичную Release Train Engineer (инженеру подготовки релизов), — координирует и содействует эффективному использованию Scrum/SAFe в Nexus/ART с целью обеспечения жесткого цикла проверки и адаптации с использованием инкрементов рабочего продукта.

Эмпиризм через интегрированные рабочие инкременты каждого спринта — демо системы и обзор спринта Nexus, отвечающие общему определению готового

И SAFe, и Scrum ясно дают понять, что частые проверки и адаптация рабочих интегрированных инкрементов являются ключом к управлению неопределенностью/изменчивостью, присущей разработке продукта в сложном пространстве. Обзор спринта в Nexus и демонстрация системы — похожие события, происходящие с одинаковой частотой — каждые несколько недель (каждый спринт/итерацию).

Цель спринта Nexus — цели программного PI, только с разной частотой

Цели программного PI служат той же цели, что и цель спринта Nexus. Они должны быть устойчивыми в целом, но детали могут меняться.

Не стоит масштабировать дерьмо. Масштабирование требует технического совершенства

И Nexus, и SAFe подчеркивают качество сборки и важность технических приемов, основанных на XP, для эффективного масштабирования. Без технического совершенства и SAFe, и Nexus утонули бы в техническом долге.

Чем отличаются Nexus и SAFe

Nexus — ART

Разве мы не писали выше, что Nexus похож на ART? Что ж, Господь в деталях.

Nexus — это 3-9 Scrum-команд, работающих вместе. ART — это 5-12 команд. Это, казалось бы, незначительное изменение дает представление о некоторых вариантах дизайна двух фреймворков. Для Nexus меньшего размера может быть проще предоставить право собственности на продукт, что делает единого владельца продукта более жизнеспособным. События уровня Nexus организовать легче, чем мероприятия, посвященные всему ART, и это дает некоторое представление о том, почему SAFe объединяет все ART только для каждого PI, а не для каждого спринта.

ARTы целиком и полностью кроссфункциональны

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

Один владелец продукта — группа владельцев продукта (PO) или менеджеров (PM)

Подход SAFe ко владению продуктом заключается в том, что масштабирование происходит за счет разделения роли владельца продукта между Product Manager, который больше похож на классического Scrum Product Owner, и Product Owner, который напоминает представителя или технического владельца продукта, тесно сотрудничающего с командой. Одна из основных причин этого — в том, что одному владельцу продукта сложно иметь дело с большим количеством команд, при этом балансируя исходящие и входящие действия.

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

О том, как добиться расширения полномочий владельца продукта, поговорим на PSPO Advanced

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

Вы Продакт Оунер в SAFe-организации? Присмотритесь к тренингу SAFe Product Owner/Product Manager

Темп/частота объединения всего Nexus/ART для планирования и ретроспективы

Обзоры, ретроспективы, планы и уточнения Nexus общедоступны на каждом спринте. Как правило, обзор спринта посещается достаточно широко, в том числе стейкхолдерами Nexus. На уточнении, планировании и ретроспективе присутствуют соответствующие представители Scrum-команд. Уместность, конечно, зависит от контекста.

В SAFe единственным событием итерации на уровне ART является демонстрация системы, которая, как мы уже обсуждали, очень похожа на обзор спринта. В ART нет формального места для планирования/уточнения/ретроспективного анализа команд на основе спринта за спринтом. При этом ART Sync дает возможность проверять и адаптировать ART, который многие организации используют для планирования/уточнения/ретроспективы.

Формальная межкомандная ретроспектива/каденция планирования в SAFe — это этап программы, охватывающий все событие АRТ.

Нет обзора спринта на уровне команды

У Nexus есть только обзор спринта между командами. “На бумаге” в SAFe тоже есть как итерации на уровне команды, так и системная демонстрация на уровне ART. На деле же многие ART пропускают обзоры итераций и получают достаточный анализ и адаптацию из системной демонстрации.

Объем – команда команд и организационный уровень

Nexus фокусируется только на команде команд, считающейся необходимой конфигурацией в SAFe. SAFe также охватывает другие компетенции, необходимые для гибкости бизнеса, – бережливое управление портфелем (Lean Portfolio Management) и крупные решения (Large Solutions). Некоторые организации, использующие Nexus, в конечном итоге обращаются к компетенциям SAFe на уровне портфолио или к портфельным канбанам в дополнение к Nexus.

Интегрированный бэклог спринта Nexus – различные бэклоги командных итераций

Бэклог спринта Nexus представляет собой сборную солянку из элементов цели спринта Nexus и бэклога продукта, состоящего из бэклогов спринта отдельных скрам-команд. Этого нет в SAFe и это стоит внимания специалистов ART, которые хотят подчеркнуть зависимости и поток работы во время спринта в ART.

Программный Kanban

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

Если вы еще не попробовали использовать ее в команде, поэкспериментируйте: она того стоит.

Другие потенциально полезные элементы SAFe, которых нет в Nexus

Поскольку Nexus спроектирован как облегченный фреймворк с более ограниченными возможностями, чем SAFe, неудивительно, что в SAFe гораздо больше элементов, о которых Nexus не упоминает. Некоторые из них могут быть полезны в вашем контексте, некоторые – не обязательно. Вспомните об Architectural Runway, итерации инноваций и планирования, Kanbans на уровне команды, DevOps, конвейере непрерывной доставки, системной архитектуре, владельцах бизнеса, фичах/енейблерах, эпиках.

И вообще, за подробностями всегда лучше почитать мануалы:

Несколько идей о том, как один фреймворк может повысить продуктивность второго

Как улучшить SAFe с помощью Nexus

Анализируйте и планируйте вместе каждый спринт/итерацию в ART

Простого общего обзора спринтов недостаточно. Делайте ретроспективы, планируйте вместе. И это не значит, что нужно объединить весь ART. Нужно сначала добиться некой согласованности в ART, ведь потом придется отделиться и спланировать итерации по отдельности, а затем снова объединиться. Паттерн по принципу того, который используют Solution Trains при PI Planning.

Подобно программ-борду для PI, используйте интегрированный бэклог спринта Nexus для просмотра зависимостей на более детальном уровне спринта/итераций. Это артефакт, который может поддерживать планирование итераций на уровне ART.

Как улучшить Nexus с помощью SAFe

Используйте Big Room Planning (планирование большой комнаты) каждые 8–12 недель

Время от времени в Nexus можно использовать SAFe PI Planning для высокоуровневых согласований/уточнений.

Отрегулируйте каденции и уровень участия

Выясните, какой уровень «большой комнаты» во всем Nexus нужен в каждом спринте, а какой может соответствовать менее частой каденции (например, PI). Просмотрите, как вы выполняете планирование спринта Nexus, в частности ретроспективу.

Вдохновляйтесь принципами и компетенциями SAFe Lean/Agile

Рассмотрите принципы SAFe и дополнительные компетенции Lean/Agile, такие как Lean Portfolio Management, как способ поддержки Nexus в рамках традиционной экосистемы в организации. Можно использовать просмотр оценок гибкости бизнеса «Measure&Grow». В его контексте, каждая категория или элемент может быть:

чем-то, что вы уже делаете (отлично!)
чем-то, что вы еще не делаете, но имеет смысл рассмотреть (также отлично!)
чем-то, что не имеет смысла делать в вашей ситуации (достаточно справедливо)
или тем, с чем вы категорически не согласны (полностью приемлемо, если вы рассматриваете каждый принцип/метод по достоинству).

Обзор семи главных компетенций, необходимых для гибкости в бизнесе, от SAFe

Это упражнение поможет вам разработать бэклог/дорожную карту улучшений.

Много вариантов – это всегда хорошо. Тоннельное видение – это всегда плохо

Любой профессиональный аджайлист должен быть открыт к новому. Знакомство с разными фреймворками масштабирования к этому также относится: оно дает нам лучшее понимание фреймворка, который мы используем, и добавляет новых идей, с которыми можно экспериментировать.

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

“Принимайте изменчивость, сохраняйте опциональность”

Изучайте новые фреймворки масштабирования, пробуйте разные техники. В конце концов, и скрам, и сейф говорят о том, что главное – практика 😉

В этой, восемнадцатой статье из серии «Менеджмент цифрового мира» (оглавление) я буду рассказывать о фреймворках масштабирования Agile на большие подразделения или компанию в целом. Эту тему я уже начал в прошлой статье «Kanban и Lean - эволюция вместо революции»: Kanban также позволяет оркестровать работу в рамках компании, но он нем я здесь говорить больше не буду.

Отмечу, что ячейкой организации в любом случае является автономная самоорганизующаяся Agile-команда, поэтому совместимость способов управления с Agile-культурой является принципиальным требованием. Опыт показывает, что многие подходы менеджмента, основанные на уважении авторитета руководителя, полагаемого безусловным, или следовании за непогрешимым лидером не выдерживают столкновения с Agile-культурой: сотрудники могут просто уйти целой командой. И если руководство привыкло к такому стилю управления, то в Agile нет никакого смысла. С другой стороны, как я говорил в статьях «Три вызова цифрового мира» и «Цифровой мир: от физического труда — к умственному» методы регулярного менеджмента в цифровом мире перестают работать, а Agile-методы являются одной из работающих альтернатив, что подробно рассмотрено в статье «Agile – ответ IT на вызовы цифрового мира».

Фреймворки имеют разную сложность и рассчитаны на компании или подразделения разного размера. При этом большинство из них рассчитано на короткие цепочки создания ценности, когда одна кроссфункциональная команда делает продукт, поставляемый потребителям. Как я писал в статье «Место Agile-команд в компании», в условиях неопределенности и быстрого изменения условий работы компании в VUCA-мире короткие цепочки являются естественным способом организации труда, способным быстро реагировать на изменения, в отличие от стабильных условий функционирования, которые ведут к специализации и образованию длинных цепочек из функциональных подразделений.

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

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

И перед тем, как перейти к обзору фреймворков я хочу порекомендовать доклад Асхата Уразбаева «Фреймворки масштабирования Agile» на SECR-2017 со сравнением разных фреймворков.

Начну я с наиболее простого Scrum of Scrums, который появился раньше других. Он применяется в случае, если у вам в компании есть независимые Scrum-команды, каждая из которых делает свой продукт. Тогда для работы надо общими вопросами достаточно собрать команду Product Owner для обсуждения стратегии развития продуктов и координации усилий, и команду Scrum Master для обсуждения и координации вопросов организации. Если в командах есть Tech Lead, отвечающий за технологии и обучение им сотрудников, то добавляется еще координирующая команда из них.

Однако, бывают ситуации, когда одна команда не может обеспечить развитие продукта в требуемой темпе, ее мощности не хватает. Ведь размер команды ограничен, эффективно работает команда в 7-9 человек, а если их становится сильно больше, то необходимо дополнительное структурирование. Есть относительно простой способ нарастить команду до 15-20 человек, представленный на схеме. Это конструкция из мини-команд, каждая из которых состоит из опытного сотрудника и 1-2 стажеров, для которых опытный является наставником для стажеров. При этом операционные вопросы взаимодействия решаются командой из руководителей мини-команд.

Другой относительно простой способ – это собрать Integration Team из представителей отдельный команд, которая будет решать вопросы координации и зависимостей. Это предлагает Nexus и достаточно в случае, когда зависимости являются достаточно слабыми.

Более сложный фреймворк – Large Scaled Scrum (LeSS) (русское описание) – несколько команд на одном продукте с общим Product Owner, BackLog, спринтами, планированием, демо и поставкой, это позволяет объединить до 8 команд. У фреймворка есть huge вариант, применяемый для больших компаний и рассчитанный на работу 1000+ человек.

Ответственность команды не ограничивается выполнением основных производственных задач, она имеет много планов и фокусов, и логично, когда это реализуется через отдельные организационные структуры. Это мы видели на примере Scrum of Scrum, который организует две структуры управления – продуктовую и организационную, иногда дополняемую третьей, технологической. Более сложной конструкцией является Spotify фреймворк, который заслуживает отдельного рассмотрения.

Основной производственной единицей в ней является клан (tribe) в 100-200 человек, который работает над отдельным продуктом. Он представляет собой матрицу: делится на кроссфункциональные производственные отряды (squad) и функциональные отделы (chapter). Отряды реализуют новый функционал и состоят из специалистов разных специализаций, которые дополняют друг друга. А отделы координируют работы специалистов из разных команд, использующих общие технологии, решая такие задачи, как разработка мобильных интерфейсов в едином стиле, однородная работа серверной части или развитие технологий тестирования. Отметим, что отделы работают над применением технологий в рамках продукта, а вот для развития технологий в целом по компании существуют еще гильдии (guild) по интересам. По мере роста компании над кланами появились структуры следующего уровня – альянсы (alliance) и бизнес-единицы (business unit).

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

При этом в самой компании Spotify организационная структура развивается очень быстро. И я хочу интересующимся порекомендовать доклад Yuliya Kurapatenkava на Saint TeamLeadConf-2018, в котором она рассказывала про логику развития (мой конспект есть в отчете с конференции, сам доклад по-английски). И вы можете сравнить то, что звучит в докладе с тем описанием фреймворка, которое доступно по ссылке в начале раздела и фиксирует состояние несколько лет ранее.

Здесь стоит рассмотреть практическое применение подобных фреймворков. Один продукт, над которым работают несколько команд, далеко не всегда означает единственный продукт в смысле софта, более того, часто речь идет об одном бизнес-продукте, поддержка которого со стороны софта требует общей серверной части и нескольких приложений на разных платформах – web и мобильных. Естественным образом для того, чтобы какой-то новый функционала стал доступен конечным пользователям, он часто должен быть реализован в серверной части и для каждой из платформ. И тут может быть два подхода: сделать команды, каждая из которых сосредоточенна вокруг каждого софтверного продукта, при этом только она работает с кодовой базой продукта и отвечает за его архитектуру. В этом случае для организации могут применяться фреймворки, подобные LeSS.

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

Так вот, в зависимости от потока задач и этапа развития компании предпочтительная структура может сильно изменяться. И сейчас IT-компании умеют достаточно быстро и успешно перестраивать свою структуру в зависимости от потребностей развития продукта. Я хочу сослаться на опыт компании ivi. На TeamLeadConf-2018 Евгений Россинский рассказывал, как они обеспечивали целостность продуктов и поддерживали знания разработчиков при переходе к кроссфункциональным командам от команд, собранных вокруг отдельных приложений. А через год TeamLeadConf-2019 он же рассказывал как за год они для решения задач реинжиниринга ядра продукта вернулись к командам, организованным по приложениям, провели реинжиниринг, а затем – снова перешли к кросс-функциональным командам, и все это - за один год, и продолжая мониторинг производительности, чтобы не допустить деградации.

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

Scaled Agile Framework (SAFe) является самым сложным Agile-фреймворком, но при этом – самым популярным. Это сложная конструкция уровня компании с управлением потоками создания ценности и архитектурой. На мой взгляд, популярность этого фреймворка сродни популярности PMBOK или RUP – в нем есть все и на все случаи жизни, и предлагается просто взять нужное. Те, кто читал мою статью «Развитие и провал регулярного менеджмента в IT» не удивятся моему мнению, что у это – неработоспособная конструкция, хотя и привлекательная в своем инженерном совершенстве. И он не будет работать по тем же самым причинам – его сложность превышает разумный предел, при этом обвинить сам фреймворк будет невозможно, всегда окажется, что это вы не смогли его правильно реализовать.

Но дело не только в сложности фреймворка: SAFe пытается за счет сложных регламентов превратить запутанную область в сложную, а это – невозможно (подробнее о сложности областей – в моей статье «Место Agile-команд в компании»). Однако, SAFe может быть полезен как теоретический источник, подобно PMBOK. Кстати, автором фреймворка является Дин Леффингуэлл (Dean Leffingwell), один из авторов RUP.

Довольно интересен фреймворк Enterprise Scrum предлагает переход от создания IT-продукта к поставке ценности, управляемой набором связанных метрик. К сожалению, в отличие от всего остального он не завершен. Его создатель Mike Beedle, кстати, один из авторов Agile-манифеста был, к сожалению убит в Чикаго весной 2018 года, и работа не завершена. Однако, на сайте есть достаточно подробная конструкция системы метрик, совместимая с Agile-методами управления, и, возможно, она вам окажется полезной при конструировании собственной, хотя в готовом виде ее, естественно, брать не стоит. Поэтому я и даю ссылку.

На этом я завершаю эту статью. Полное оглавление серии «Менеджмент цифрового мира» можно увидеть у меня на сайте. В следующей статье мы поговорим про кейсы Agile-трансформации. Продолжение следует…

Читайте также: