Nexus és un marc per desenvolupar i mantenir iniciatives de construcció de productes i programes a escala. Nexus utilitza Scrum com a bloc de construcció. Nexus augmenta Scrum proposant alguns canvis en esdeveniments, rols i artefactes que s’expliquen en aquest document. En un equip l’auto-organització individual es veu limitada per la de l’equip. A Nexus, l’auto-organització de l’equip es veu limitada per la de Nexus. És per això que algunes reunions es veuen afectades (augmentades) per tal que Nexus pugui desenvolupar-se a escala.
Nexus és una unitat representada per un únic Product Owner i un únic Product Backlog, amb la participació de 3 a 9 equips Scrum (de 10 a 100 persones), que treballen de forma cíclica per l’obtenció d’increments integrats. Cada equip Nexus està dirigit per un NIT (Nexus Integration Team). Els equips Scrum de Nexus segueixen les mateixes normes establertes a la guia Scrum.
El NIT (Nexus Integration Team) consta d’un PO, almenys un SM i membres representatius pels seus coneixements en eines, pràctiques o enginyeria, segons les necessitats establertes al Nexus Sprint Goal per aquell sprint (no necessàriament tècnics, i no obligatòriament membres dels equips).
Els membres (excepte el PO) poden canviar a cada Sprint (es decideix a cada Nexus Sprint Planning) en funció del valor compromès i la vàlua específica de cada membre respecte a aquest valor. Els membres del NIT, en cas de pertànyer a algun dels equips del Nexus, no desassisteixen les tasques en el seu equip, però donen prioritat a les tasques del NIT.
garantir la integració. El NIT ha de procurar la variabilitat dels seus membres a cada Sprint, per tal que no sigui vist com una estructura de poder.
El NIT existeix per coordinar, entrenar i supervisar l’aplicació del Nexus i el funcionament de Scrum, de manera que es derivin els millors resultats. Així ajuda als equips en l’aplicació de les millors pràctiques, alhora que té visió transversal del producte pel que fa a requisits, arquitectura, entorn, posta en producció, requisits no funcionals i qualitat.
El NIT se centra a fer possible el lliurament de valor de forma Integrada. La integració és una de les missions importants del NIT. Per a que la integració sigui possible i viable, s’ha de posar l’esforç en la identificació de les dependències entre històries i tasques assignades en el sprint a múltiples equips. El NIT facilita la integració (és accountable), tot i que ell no s’encarrega directament (això ho fan els equips)
El NIT és:
A l’estar format per membres dels equips, dona cohesió i fa fluir la informació a través de les Daily dels equips. A més el NIT té una visió més estratègica de l’evolució del producte, assegurant que es compleixen els requisits d’arquitectura, UX, legal, qualitat, desplegament i requisits no funcionals. Cada dia, el NIT es reuneix a la Nexus Daily Scrum, per tal d’avaluar la situació respecte a la integració i les dependències. Decidir accions i portar-les a les daily individuals dels equips.
Una altra responsabilitat del NIT és la definició d’un DoD mínim que serà d’aplicació obligatòria per a tots els equips del Nexus. A més el NIT s’ha d’assegurar que aquesta definició de DoD és viable. Cada equip individualment podrà ampliar aquesta DoD amb definicions pròpies. Però no podrà reduir-la.
El NIT pot passar a mode d’emergència si es detecta que el sprint no aportarà un valor integrat. En aquest cas el NIT es converteix en un Scrum Team per tal de resoldre els problemes o obtenir un valor mínim integrat. El NIT pot decidir aturar les operacions del Sprint fins a decidir un nou Nexus Sprint Goal
El Scrum Master en el NIT és responsable de què el marc de treball Nexus s’entengui en el NIT. Aquest Scrum Master pot ser dedicat en el NIT, o bé ser alhora Scrum Master d’un o més equips
La durada del sprint no té per què ser la mateixa per a tots els equips del Nexus, però si ha de ser coincident en els lliuraments integrats. Per exemple: n equips estan en sprints de 2 setmanes, i n equips en sprints de 4 setmanes. Cada 4 setmanes hi ha un lliurament més voluminós. Sigui com sigui, tots els Scrum Teams han de coincidir en la Nexus Sprint Planning, la Nexus Sprint Review i la Nexus Sprint Retrospective; per tal de poder proporcionar increments integrats
A cada Sprint hi pot haver mobilitat dels membres dels diversos Scrum Teams, de forma que s’auto-organitzin de la forma més eficient possible segons l’objectiu del sprint integrat. S’ha de fer amb compte per evitar que equips quedin desequilibrats. L’objectiu principal de tot l’equip Nexus durant el Sprint (el NIT i els Scrum Teams del Nexus) és la gestió de les dependències, així com l’assegurament constant de la integració.
A Nexus xisteixen 3 llistes de producte relacionades:
Com sempre, només pot haver-hi un únic Product Backlog. En l’àmbit del Nexus, un únic Product Owner és accountable del Product Backlog (contingut, accessibilitat i priorització). El principal objectiu del Product Owner amb el Product Backlog en el Nexus, és que aquest estigui prou refinat, amb les dependències i els problemes d’integració identificats, i a ser possible mitigats o resolts
En el Product Backlog, el Product Owner té el compromís de trobar i consensuar un Product Goal, el qual marca la conveniència en el sprint dels ítems del Product Backlog, amb relació a si responen o no a aquesta meta definida.
La Nexus Sprint Backlog és la composició de la Nexus Sprint Goal + el recull d’ítems del Product Backlog compromesos per al sprint. Cada equip disposa del seu Sprint Backlog, que és el subconjunt de la Nexus Sprint Backlog amb els ítems assignats a l’equip.
La Nexus Sprint Backlog pot ser actualitzada a cada Nexus Daily Scrum, amb la informació sobre la situació del sprint de cada un dels equips. La Nexus Sprint Goal és el compromís de Nexus per al Nexus Sprint Backlog. És una única definició d’objectiu de valor per al sprint, que posteriorment cada equip té present durant el sprint i que pot complementar (no substituir) amb els seus propis Sprint Goals. El Nexus Sprint Goal es crea durant la reunió de Nexus Sprint Planning.
Durant la Nexus Sprint Review pot utilitzar-se la Nexus Sprint Goal per a suportar la demostració i validació del valor obtingut durant el Sprint sobre l’increment integrat. I pot emprar-se com a base per a demandar el feedback als stakeholders
L’Increment Integrat és la suma dels diversos increments individuals creats per cada equip del Nexus, integrats de forma que funcionen com una unitat i permeten demostrar el Nexus Sprint Goal. L’increment integrat s’inspecciona a la Nexus Sprint Review, tot i que el lliurament a les parts interessades pot dur-se a terme abans de la finalització del sprint.
La Definition of Done és el compromís per a l’increment integrat. La DoD marca les premisses sobre qualitat, bones pràctiques i normatives que siguin requerides per tal de poder determinar que l’increment efectivament està acabat. L’increment es pot considerar com acabat únicament si acompleix el DoD i està integrat com una unitat, té valor i és utilitzable.
El NIT és el responsable de la definició de la DoD a nivell del Nexus i d’assegurar-se que aquesta DoD pot ser aplicada i s’aplica en un increment integrat. Cada equip, individualment, pot completar la definició de DoD descrita pel NIT, però no podrà reduir la DoD inicial. Cada equip Nexus és responsable d’assegurar que el seu increment acompleix el DoD
Els equips (Scrum Teams) són els únics responsables d’assegurar l’assoliment d’un únic increment integrat a cada Sprint. El NIT no “dirigeix” els equips i no existeixen Team leaders. Els membres dels equips treballen internament a cada equip i amb la resta dels equips per assegurar que la seva feina és integrable en un tot.
La Nexus Sprint Planning té com a objectiu la coordinació de les activitats de tots els equips Scrum del Nexus per assolir un únic increment integrat. La Nexus Sprint Planning no té un timebox definit. La Nexus Sprint Planning s’executa en dues fases
A la 1a part, la Nexus Sprint Planning és una reunió en què participa el NIT i tots els membres dels equips. En funció de la feina feta durant les sessions de Refinament d’Integració, es presenten els elements que es construiran. No té un Timebox definit
Per a que aquesta tria sigui possible, és necessari disposar d’un backlog prioritzat i refinat correctament (als esdeveniments de Refinament dels equips). Amb les dependències localitzades i, si és possible, minimitzades (a l’esdeveniment de Refinament d’Integració). És habitual que, en el treball amb diversos equips apareguin dependències que cal gestionar. Per exemple, reorganitzant els membres de l’equip per assegurar que cada equip disposa dels coneixements i habilitats necessàries. També pot ser necessari reordenar el backlog a la sessió de refinament, per tal de minimitzar el màxim possible l’impacte d’aquestes dependències.
Durant la reunió, els equips posen de manifest quins problemes d’integració o dependències poden trobar durant el sprint, i consensuen en aquell moment quines persones dels equips formaran part del NIT per al nou sprint. Durant aquesta part de la reunió, el PO negocia el Nexus Sprint Goal.
A la 2a part, cada equip durà a terme la seva pròpia Sprint Planning amb l’objectiu de complir la Nexus Sprint Goal en la selecció d’històries que tenen assignades com a equip. La Nexus Sprint Planning finalitza quan cada equip ha dut a terme la seva Sprint Planning
El resultat de la Nexus Sprint Planning ha de ser:
Tot i que a la sessió de Refinament d’Integració s’han de cercar solucions a les dependències existents, és habitual que apareguin de noves durant el Nexus Sprint Planning, i que s’hagin de resoldre allà. També a les sessions individuals de Sprint Planning poden sorgir noves dependències que calgui resoldre o reduir.
Durant la Sprint Planning és una possibilitat real que, a causa de les dependències, un equip no tingui prou assignació de feina en un Sprint. És una bona pràctica en aquests casos que els membres de l’equip practiquin la programació en parella en altres equips, o bé ajudin d’alguna altra manera. No és bona pràctica derivar tasques de documentació o testing d’altres equips.
A la Nexus Daily Scrum, hi participen només els membres representants dels equips que conformen el NIT (el PO i el SM no tenen per què participar). El NIT inspecciona l’estat actual de l’increment integrat, amb l’objectiu d’identificar problemes d’integració, dependències o impactes que els equips hagin descobert. En aquesta reunió diària, el NIT crea un pla d’acció per aquell dia, enfocat a resoldre els problemes detectats, i que serà traslladat als equips Scrum a les Dailys d’equip, pels diferents representants dels equips al NIT.
Preguntes habituals en la Nexus Daily Scrum:
| Un exemple de qüestió que pot tractar-se a la Nexus Daily Scrum | |
|---|---|
| Durant una Nexus Daily Scrum, un representant d’un equip posa de manifest una dependència d’arquitectura amb un altre equip. El NIT decideix llavors que l’arquitecte, juntament amb un altre arquitecte de l’altre equip, facin un Refinement per trobar una solució que resolgui la dependència. Aquesta decisió d’actuació es transmet als equips a la Daily individual. |
La Daily individual s’executa com sempre, però després d’haver tingut lloc la Nexus Daily Scrum. Els equips a la Daily a banda de tractar la seva situació, incorporen en el seu ordre del dia les decisions i plans d’acció comunicats pel NIT.
La Nexus Sprint Review és única per al Nexus, i està protagonitzada pel NIT. L’objectiu és verificar que es disposa d’un increment de valor integrat i que es compleix la DoD definida pel NIT. I obtenir feedback. No hi ha Review individuals. Una tècnica de comunicació a la review (no a totes) podria ser la “fira de mostres”. On cada equip mostra els seus avenços, focalitzant-se en el valor que proporciona a l’organització
Les retrospectives Nexus són sempre en 3 fases: NIT - Equip - NIT.
Part 1 (NIT): Els representants dels equips al NIT identifiquen els problemes que hagin pogut impactar als equips durant el sprint
Part 2 (Equip): Cada equip duu a terme una Retro individual amb l’ordre del dia de la llista de la part 1. A banda poden tractar els problemes propis que els hagin pogut afectar
Part 3 (NIT): Els representants del NIT, en funció del que s’ha debatut a cada equip, arriben a acords sobre accions de millora que puguin aplicar-se al sprint següent
Algunes preguntes a la part 1 de la retrospectiva:
I per al cas de necessitar aprofundir més en alguna d’aquestes qüestions, podem fer servir les preguntes següents:
El Refinament d’integració té l’objectiu de detectar i minimitzar les dependències entre els equips del Nexus. El NIT se centra en el Product Backlog per tal de refinar, prioritzar i detectar dependències i possibles problemes. El refinament és una activitat contínua, per tant, el NIT decideix la periodicitat i durada d’aquesta activitat, tenint en compte les necessitats del producte i la seva complexitat.
El refinament d’integració no substitueix els refinaments individuals que siguin necessaris.
El refinament d’integració persegueix cinc objectius:
Tipus de dependències:
Internes
Externes (de terceres parts). Aquestes dependències poden gestionar-se des d’una perspectiva clàssica de riscos
Algunes classificacions possibles de dependències:
No hauria d’haver-hi dependències respecte a les proves, tot i que si podria haver-hi respecte a les eines o artefactes de prova. Tampoc haurien d’haver-hi dependències respecte a la transparència, eines, tècniques, bones pràctiques o gestió o burocràcies de l’equip. Les dependències s’han de comunicar (com a mínim al PO) tan bon punt apareixen
El Product Owner prioritza el Product Backlog en aquest esdeveniment, per tal que a la Nexus Sprint Planning ja es disposi d’aquesta informació i l’equip pugui centrar-se a presentar els elements més prioritaris, les assignacions als equips, la seqüència de construcció que mitigui millor les dependències, les dependències o altres conflictes, i es pugui definir un Nexus Sprint Goal.
A l’inici del projecte, és possible que els equips demanin incorporar tècniques o eines que facilitin la coordinació o la integració dels increments. Aquestes propostes s’afegiran al Product Backlog i es discutirà amb el Product Owner la seva conveniència o el moment d’incorporar-les al sprint. Un cop es coneix l’assignació d’una necessitat a un equip, el refinament d’aquesta ja passa a ser responsabilitat del mateix equip, de la forma habitual en Scrum
Nexus és adequat en escenaris amb un producte i diversos equips (mes de 3) amb objectius convergents en aquest producte. Per a escenaris amb un producte i pocs equips (un màxim de 3), Scrum hauria de ser la solució adequada. En escenaris de multiprojecte o multiproducte i pocs equips, Scrum també pot ser la solució adequada sempre que es tingui present el foment de la focalització de l’equip en un producte per sprint, i de la creació de product backlogs per a cada producte. I en casos de molts productes alhora que molts equips, la creació de portfolios és recomanable i, en funció de la complexitat, el foment de l’estabilitat d’equips a productes
Nexus Guide, (https://www.scrum.org/resources/nexus-guide) Pàgina oficial de descàrrega multiidioma, març 2023
Scrum Guide, (https://scrumguides.org/download.html) Pàgina oficial de descàrrega multiidioma, març 2023
Les activitats de Scrum explicades pas a pas Calaix[À]gil, març 2023
Mapa d’activitats Scrum Calaix[À]gil, març 2023
Escalar Scrum con Nexus, (https://youssefoufaska.com/escalar-scrum-con-nexus/) youssefoufaska.com, març de 2021
Las 10 claves del escalado de Scrum con Nexus, (https://www.youtube.com/watch?v=PFXXfBWtbAw) Paradigma digital, juliol 2018
Scrum.org. Open assessments, (https://www.scrum.org/open-assessments) Scrum.org, març 2023
Scaled Professional Scrum Sample Questions, (https://www.processexam.com/scrum-org/scrum-org-sps-certification-exam-sample-questions) processexam, març 2023
SPS Preparation Quiz, (https://mlapshin.com/index.php/scrum-quizzes/scaled-scrum-quiz/) Mikhail Lapshin, 2018
SPS Practice Exam, (https://www.techagilist.com/practice-exams/sps-practice-test/sps-practice-exam-practice-mode-questions/) Tech Agilist, març 2023
Descarrega el documment per imprimir aquí
