Nexus

Одне доповнення — свідомо

Nexus починається з конкретного діагнозу. Коли три-дев’ять Scrum-команд працюють над одним продуктом, першим ламається зазвичай не узгодження планів — команди загалом уміють домовлятися й ділити роботу. Ламається інтеграція роботи. Код, який був справний окремо, перестає бути таким при зустрічі з кодом інших восьми команд, і поки це виявиться, спринт уже завершився.

Тож Nexus додає одну зону відповідальності — і зупиняється. Усе інше лишається точно таким, як описує Scrum Guide: один Product Owner, один Product Backlog, одна Product Goal, один спринт однакової довжини для всіх, і кожна команда проводить власні Sprint Planning, Daily Scrum, Review і ретроспективу. Саме слово «Nexus» означає зв’язок між командами й залежності між їхньою роботою.

Хто входить до команди інтеграції

Це та частина Nexus, яку читають неправильно найчастіше, і помилка закладена в самій назві. «Команда інтеграції» звучить як окремий загін, що мержить чужі гілки. Це не так. Nexus Integration Team відповідає за те, щоб готовий інтегрований інкремент створювався щонайменше раз на спринт, — відповідає за те, щоб це сталося, а не за те, щоб зробити це самій.

• Product Owner

  Той самий єдиний Product Owner, що володіє всім Product Backlog. Його присутність у команді інтеграції тримає рішення про пріоритети зв’язаними з реальністю інтеграції, а не дає порядок беклогу, який технічно неможливо поставити разом.

• Scrum Master

  Один Scrum Master із відповідальністю за те, щоб Nexus працював як ціле. Він може також обслуговувати одну зі Scrum-команд, але відповідальність рівня Nexus належить саме йому й не може бути розмазана по всіх.

• Учасники команди інтеграції

  Практики з самих Scrum-команд — зазвичай найсильніші в інструментах, архітектурі, тестуванні та деплой-пайплайні. Членство не постійне й змінюється разом зі зміною самої проблеми інтеграції.

Учасники продовжують працювати у своїх командах. Так і задумано: людина, яка частину тижня займається інтеграцією, а решту — фічами, приносить стандарт назад у свою команду, а не стає його вартовим. Гайд прямо каже, що робота команди інтеграції — це коучинг, консультування та підвищення обізнаності: навчити команди створювати інтегровну роботу, а не інтегрувати замість них.

Три артефакти, три зобов’язання

Nexus зберігає пару «артефакт плюс зобов’язання» зі Scrum і додає один власний артефакт. Кожен артефакт відповідає на своє питання, а прив’язане до нього зобов’язання не дає артефакту сповзти в статус-звіт.

Nexus Sprint Backlog вартий уваги, бо це єдиний справді новий артефакт. Його призначення — не бути більшим списком справ, а показувати залежності. Команди дивляться в нього, щоб побачити, які їхні задачі залежать від задач іншої команди й коли ця задача очікується, — і саме ця інформація відрізняє виявлення залежності на другий день від виявлення на дев’ятий.

Найсуворіший Nexus — саме в питанні Definition of Done. На весь Nexus він один, його визначає команда інтеграції, і кожна Scrum-команда має відповідати щонайменше йому. Команда може застосувати суворіший до власної роботи; м’якший — ніколи. Без цього єдиного стандарту «інтегровано» означає різне в кожній команді, а інтегрований інкремент не є інтегрованим у жодному змістовному сенсі.

Події Nexus

Кожна подія Scrum отримує відповідник рівня Nexus, що огортає її. Жоден із них не замінює подій рівня команди — команди й далі проводять свої — і жоден не є статус-зустріччю. Кожен існує, щоб виявити залежність чи проблему інтеграції раніше, ніж вона проявилася б сама.

Cross-Team Refinement

Це подія з найбільшою вагою, і саме її пропускають найчастіше. Її завдання — узяти задачі Product Backlog, які ще завеликі, і розбивати їх, поки не стане ясно, яка команда робитиме який шматок, і поки залежності між цими шматками не будуть усунені там, де можливо, і зроблені явними там, де ні. Рефайнмент у Nexus — не ритуал оцінювання, а знесення залежностей до початку спринту.

Nexus Sprint Planning

Відповідні представники кожної команди зустрічаються з Product Owner, щоб переглянути відрефайнений беклог і домовитися, як розподілена робота. Результат — єдина Nexus Sprint Goal, що описує призначення всього спринту для всіх команд. Далі кожна команда проводить власний Sprint Planning і формує власну Sprint Goal, яка має бути узгоджена з Nexus-ціллю.

Nexus Daily Scrum

Представники кожної команди — зазвичай розробники, близькі до інтеграційної роботи, а не менеджери — зустрічаються перед щоденними зустрічами команд. Вони перевіряють поточний інтегрований інкремент на проблеми й виявляють інтеграційні складнощі та нові залежності. Знайдене далі переносять у власний Daily Scrum кожної команди — тому порядок і має значення.

Огляд і триетапна ретроспектива

Nexus Sprint Review замінює окремі огляди команд, а не додається до них. Є один огляд одного інтегрованого інкремента зі стейкхолдерами — бо дев’ять окремих демо неінтегрованих частин не кажуть стейкхолдерам нічого про те, чи працює продукт.

Ретроспектива проходить у три етапи, і сама її форма — це і є суть. Спершу представники зустрічаються, щоб виявити проблеми, які зачіпають більш ніж одну команду. Потім кожна команда проводить власну ретроспективу, беручи ці спільні проблеми як вхід поряд зі своїми. Нарешті представники зустрічаються знову, щоб домовитися, що саме буде зроблено зі спільними. Без третього етапу міжкомандні проблеми обговорюють щоспринту й не виправляють жодного разу.

Вибір між фреймворками масштабування

Nexus — найменший крок угору від Scrum на одну команду, тому це правильний перший хід для більшості організацій, які щойно переросли одну команду. Якщо він перестає працювати після дев’яти команд, це і є сигнал дивитися на LeSS Huge чи SAFe — але не раніше. Scrum.org описує можливість вести кілька Nexus на один продукт для більших випадків, але свідомо не публікує детального припису — і це чесний сигнал, що тут край фреймворку, а не його задумана територія.

Як це виявляється в реальній поставці

Nexus виправдовує себе лише тоді, коли інтегрований інкремент справжній. Це означає спільний пайплайн, спільний Definition of Done та інтеграцію щонайменше щодня. Nexus без безперервної інтеграції — це набір зустрічей, який виявляє той самий інтеграційний борг на спринт пізніше, ніж це сталося б і без нього, і провину покладуть на фреймворк, а не на відсутній пайплайн.

Де він вироджується

• Команда інтеграції робить мержі замість того, щоб навчати команди інтегрувати власну роботу.
• Свій Definition of Done у кожної команди, тож «інтегровано» означає різне в різних командах.
• Пропуск Cross-Team Refinement переносить виявлення залежностей усередину спринту.
• Дев’ять окремих Sprint Review замість одного огляду інтегрованого продукту.
• Відправляти менеджерів на Nexus Daily Scrum — це перетворює робочу сесію на статус-коло.
• Відкидання третього етапу ретроспективи: спільні проблеми називають щоспринту й не виправляють жодного разу.

Коли це застосовувати

Пов’язані сторінки

• МенеджментScrumScrum — це найпоширеніший спосіб організувати роботу команди розробки. Scrum ділить роботу на короткі фіксовані цикли — спринти, дає трьом ролям чіткі зони відповідальності й обкладає роботу невеликим набором регулярних зустрічей, щоб проблеми спливали за дні, а не за місяці. На цій сторінці ми пройдемо кожну з цих зустрічей — включно з кількома, які реальні команди проводять, хоча в офіційному посібнику їх немає.
• МенеджментLeSSLeSS (Large-Scale Scrum) зберігає одного Product Owner, один Product Backlog, один спринт і один придатний до поставки інкремент — незалежно від кількості команд. Він масштабується прибиранням організаційної структури, а не додаванням, і тому є найвимогливішим до впровадження та найближчим до справжнього Scrum. На цій сторінці — десять принципів, розшарування «правила — гайди — експерименти», усі події LeSS і обидва варіанти.
• МенеджментScrum@ScaleScrum@Scale — це фреймворк масштабування Джеффа Сазерленда, побудований на двох пов’язаних циклах — що будується і як, — які повторюються фрактально на кожному рівні. Він модульний, а не конфігурований: ви впроваджуєте лише ті компоненти, яких вимагає ваше вузьке місце, а решти не чіпаєте. На цій сторінці — усі компоненти обох циклів, дві точки їх дотику та ролі й події, які кожен додає.