В двух словах о NEXUS

в 7:06, , рубрики: nexus, scrum, Блог компании NIX Solutions, управление проектами, управление разработкой

В двух словах о NEXUS - 1

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

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

Роли

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

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

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

События

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

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

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

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

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

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

Помимо Daily Scrum для каждой команды, добавляется Daily Scrum для NIT — для ежедневного перепланирования оставшейся работы по общему инкременту.

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

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

Информация, полученная в ходе Nexus Daily Scrum, используется для обсуждения на командных Daily Scrum.

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

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

Стоит отметить, что длина спринтов у команд в Nexus может отличаться, но должна быть кратной (например, 1, 2 и 4 недели или 1 и 3 недели), чтобы пересекаться на общем планировании, спринт ревью и ретроспективе.

Артефакты

Чтобы видеть целостную картину по продукту, 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.

Автор: NIX Solutions

Источник

Поделиться новостью

* - обязательные к заполнению поля