Nexus

Nexus на одному екрані

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

Таблиці описують чинний Nexus Guide, січня 2021 року. Багато з написаного про Nexus, зокрема навчальні матеріали й посібники до іспитів, спирається на редакцію 2018 року, яка приписувала більше; відмінності перелічено нижче, у розділі про події.

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

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

Гайд називає дві причини залежностей, що стоять за цим. Структура продукту: наскільки чисто розділені частини продукту — від цього залежить, скільки команд має зачепити одна зміна. І структура комунікації: як люди спілкуються всередині команд і між ними, де кожна затримка гальмує роботу. Числа пояснюють, чому це вдаряє саме на цьому масштабі. Девʼять команд по семеро — це 63 людини, а 63 людини мають 1 953 можливі пари; сторінка про методи оцінювання малює ту саму криву для менших груп.

Тож Nexus додає одну зону відповідальності — і зупиняється. Усе інше лишається таким, як описує Scrum Guide: один Product OwnerProduct Ownerвідповідає за те, що будуютьОдна людина, відповідальна за те, що команда будує і в якому порядку. Повноваження тут справжні: Product Owner, який мусить погоджувати кожне рішення деінде, є посильним, і роль перестає працювати.Докладніше в статті →Усі терміни, один Product BacklogBacklogупорядкований список того, що лишилосьУпорядкований список усього, що може бути зроблено, і найцінніше — згори. Ключове слово тут «упорядкований»: беклог, де все однаково важливе, є списком побажань і не полегшує жодного рішення.Докладніше в статті →Усі терміни, одна Product Goal, один спринт однакової довжини для всіх. Саме слово «Nexus» означає звʼязок — між командами й між їхньою роботою.

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

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

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

• Product Owner

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

• Scrum Master

  Відповідає за те, щоб фреймворк Nexus розуміли й застосовували так, як описує гайд. Він може також бути Scrum MasterScrum Masterусуває те, що блокує командуЛюдина, відповідальна за те, щоб працював процес, а не за те, щоб робота була зроблена. Вона усуває перешкоди й захищає команду від смикань — вона не керівник команди, і саме ставлення до ролі як до керівної є звичною причиною провалу.Докладніше в статті →Усі терміни однієї чи кількох команд, але відповідальність рівня Nexus належить лише йому.

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

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

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

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

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

Nexus зберігає зі Scrum пару «артефакт плюс зобовʼязання» й додає один власний артефакт. Кожен відповідає на своє питання, а прив’язане зобовʼязання не дає артефакту сповзти в статус-звіт: Product Goal для беклогу, Nexus Sprint GoalSprint Goalнавіщо цей спринтОдне речення, узгоджене на плануванні спринту, про те, що зміниться наприкінці й навіщо це варто робити. Саме воно дає команді посеред спринту прибрати чи замінити окремі задачі без провалу: спринт, який оцінюють лише за списком тікетів, має квоту, а не ціль.Докладніше в статті →Усі терміни для спільної роботи спринту, Definition of DoneDefinition of Doneщо тут означає «готово»Перелік умов, які робота мусить пройти, перш ніж її дозволено назвати завершеною: протестовано, перевірено, задокументовано, розгорнуто — як домовилась команда. Цінність у тому, що «готово» перестає бути предметом думки на статус-зустрічі.Докладніше в статті →Усі терміни для інкремента.

Nexus SprintSprintцикл роботи фіксованої довжиниФіксований період, зазвичай від тижня до чотирьох, наприкінці якого є щось достатньо завершене, щоб показати. Фіксована саме довжина, а обсяг рухається: спринт, який подовжили під роботу, втратив єдине, заради чого існував.Докладніше в статті →Усі терміни Backlog заслуговує найбільшої уваги, бо це єдиний справді новий артефакт. Це не більший список справ, а вигляд залежностей. Команди дивляться в нього, щоб побачити, які їхні задачі залежать від задачі іншої команди й коли її очікувати, — інформація, що відрізняє виявлення залежності на другий день від виявлення на девʼятий. Гайд вимагає, щоб він був достатньо детальним для перевірки прогресу на кожному Nexus Daily ScrumDaily Scrum15-хвилинне переплановуванняПʼятнадцятихвилинна подія кожного робочого дня, на якій розробники перевіряють рух до Sprint Goal і переплановують наступні двадцять чотири години. Це не звіт про статус: якщо зустріч працює лише з керівником у кімнаті, вона ним уже стала.Докладніше в статті →Усі терміни і оновлювався впродовж усього спринту.

Nexus Sprint Goal — одна ціль для всього Nexus, складена з власних Sprint Goal команд. Її завдання — узгодженість: девʼять команд, кожна з яких досягла власної цілі, тоді як продукт не отримав нічого придатного, — саме той результат, якому вона має запобігти.

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

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

Події по черзі — і що змінилося 2021 року

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

Cross-Team Refinement

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

Nexus Sprint Planning

Представники кожної команди зустрічаються з Product Owner, щоб спланувати спринт для всього Nexus. Гайд 2021 року визначає цю подію через результати, а не кроки: Nexus Sprint Goal, узгоджена з Product Goal; Sprint Goal кожної команди, узгоджена з Nexus-ціллю; Nexus Sprint Backlog із видимими міжкомандними залежностями; і власний Sprint Backlog кожної команди. На практиці представники домовляються про розподіл, команди плануються у своїх кімнатах, а нові знайдені залежності повертаються на спільний вигляд до кінця планування.

Nexus Daily Scrum

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

Nexus Sprint Review

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

Nexus Sprint Retrospective

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

Це все, що каже гайд 2021 року, — а ось чого він більше не каже. Редакція 2018 року приписувала ретроспективу з трьох частин: представники зустрічаються, щоб назвати спільні проблеми; кожна команда проводить власну ретроспективу, беручи їх як вхід; і представники зустрічаються знову, щоб домовитися, що буде зроблено і як це відстежуватимуть. Вона також називала три питання, які має ставити кожна ретроспектива Nexus: чи лишилася недороблена робота і чи створив Nexus технічний борг; чи все інтегрували часто — аж до щодня; і чи збирали, тестували й розгортали софт достатньо часто, щоб нерозвʼязані залежності не накопичувалися. Ніщо з цього більше не є правилом. Усе це досі добра практика, і третю частину старої ретроспективи варто зберегти, навіть якщо не зберігати нічого іншого: без неї спільні проблеми обговорюють щоспринту й не виправляють жодного разу.

Знайти залежності раніше, ніж вони знайдуть вас

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

Щойно залежність знайдено, з нею можна зробити три речі, і вони не рівноцінні. Прибрати: розрізати задачу інакше, віддати всю задачу одній команді або перевести людину на спринт, щоб одна команда мала всі потрібні навички. Упорядкувати: вибудувати роботу так, щоб команда-постачальник закінчила першою — на початку спринту чи на спринт раніше. Або зробити видимою й керувати нею: винести на Nexus Sprint Backlog із датою й перевіряти щодня. Порядок важливий. Більшість Nexus за замовчуванням обирають третє, бо воно не потребує рішення, — і щоспринту керують тими самими видами залежностей.

Багато Nexus роблять цю картину фізичною під час Cross-Team Refinement: дошка з рядком на кожну команду й колонкою на кожен найближчий спринт, задачі як картки й нитка між двома картками для кожної залежності. Це та сама ідея, що й дошка планування в SAFeSAFeScaled Agile Framework — фреймворк, що веде багато agile-команд як однуScaled Agile Framework — ролі, події та практики для координації десятків agile-команд, побудовані навколо Agile Release Train: пʼять-дванадцять команд, що планують разом раз на вісім-дванадцять тижнів. Це найбільш приписовий і найпоширеніший фреймворк масштабування — і саме тому його можна встановити, не змінивши того, хто ухвалює рішення.Докладніше в статті →Усі терміни, але постійно й на два-три спринти вперед, а не раз на квартал. Нитка, що щоспринту перетинає ті самі два рядки, — не проблема планування; це структура продукту чи команд, яку гайд називає причиною, і вона просить змін.

Nexus проти LeSS, SAFe і Scrum@Scale

Діапазони найбільше перетинаються між трьома й девʼятьма командами, тож сам розмір не вирішує. Вирішує те, що організація готова змінити. Nexus не змінює жодної структури: він дає проблемі інтеграції власника й ритм, і це правильний перший хід для більшості груп, які щойно переросли одну команду. LeSS вимагає реорганізації, від якої зникає більшість залежностей, і віддає більше, коли керівництво на неї йде. SAFe стартує з наявної структури й додає прошарки, щоб її координувати.

Понад девʼять команд відповідь Scrum.org — Nexus+: кілька Nexus на одному продукті, інтегровані між собою так, як Nexus інтегрує команди. Його описують матеріали Scrum.org і книжка про Nexus Біттнера, Конг і Веста (2017), але жоден гайд його не визначає, — чесний сигнал, що це край фреймворку, а не його задумана територія. Порада до нього та сама, що й до самого Nexus: спершу навчитися дуже добре працювати в одному Nexus.

Що показують дані

Незалежних даних про Nexus мало, і це варто сказати прямо. Єдине лонгітюдне дослідження — Ерсоя й колег у Paycell, компанії Turkcell, опубліковане в Journal of Software: Evolution and Process 2024 року: дванадцять місяців вимірювань в одній продуктовій організації, шість за Scrum і шість після переходу на Nexus. Воно фіксує значне зростання продуктивності та якості продукту після переходу й невелике покращення мотивації команди.

Читайте його таким, яким воно є: одна організація, до і після, без групи порівняння, тож другі пів року несуть і все, чого команди навчилися в перші. Ширше опитування Verwijs і Russo 2024 року — 15 078 учасників із 4 013 команд — знайшло лише незначні відмінності в ефективності команд між підходами до масштабування. Разом вони вказують туди ж, куди й решта цього розділу: фреймворк вирішує менше, ніж те, чи інтегрують команди свою роботу безперервно, — а це єдине, чого Nexus вимагає і чого не може дати сам.

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

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

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

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

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

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

• МенеджментScrumScrum — це фреймворк, у якому команда до десяти людей видає придатний інкремент у фіксованих циклах до місяця — спринтах — і коригує курс на пʼяти подіях. Він визначає три зони відповідальності, три артефакти й ці пʼять подій — і свідомо нічого не каже про інженерію. Сторінка починається з усього фреймворку на одному екрані — кожна подія з таймбоксом, хто присутній і що вона дає; далі — теорія, на якій він тримається, кожна подія по черзі разом із чотирма зустрічами, які додають реальні команди, зони відповідальності й чому межа — десятеро, Definition of Done і що стається, коли вона зупиняється зарано, пʼять задокументованих епізодів і де все це вироджується.
• МенеджментLeSSLeSS (Large-Scale Scrum) — фреймворк, що масштабує Scrum, ведучи багато команд як одну: один Product Owner, один беклог, один спринт, один продукт. Він масштабується прибиранням організаційної структури, а не додаванням, і тому найвимогливіший до впровадження та найближчий до самого Scrum. Сторінка починається з усіх правил і всіх подій на одному екрані; далі — розмасштабування й визначення продукту, фіче-команди й те, що LeSS прибирає, десять принципів, кожна подія, LeSS Huge і його Requirement Areas, що показують чотири впровадження з датами і де все це вироджується.
• МенеджментScrum@ScaleScrum@Scale — фреймворк Джеффа Сазерленда для масштабування Scrum на всю організацію: дванадцять компонентів на двох повʼязаних циклах — що будувати і як. Команди обʼєднуються по чотири-пʼять у Scrum of Scrums, той самий патерн повторюється на кожному рівні, а нагорі дві групи керівників працюють як Scrum-команди. Сторінка починається з усіх дванадцяти компонентів на одному екрані — для чого кожен, хто його несе і як виглядає організація, де його не несе ніхто; далі — масштабовані ролі й події, кожен цикл, де цикли зустрічаються, як упроваджувати фреймворк у порядку, якого вимагають ваші проблеми, як він співвідноситься з Nexus, LeSS і SAFe, що показують дані і де все це вироджується.