Embed Size (px)
Citation preview
Gidul Nexus™
Ghidul definitiv Nexus:
Exoscheletul de dezvoltare Scrum scalabil
Dezvoltat și sustinut de Ken Schwaber si Scrum.org
August 2015
Copyright Scrum.org, 2015 All Rights Reserved Page 1 (Version 1.1)
Cuprins
Nexus Vedere Generala.................................................................................................................. 2
Scopul acestui ghid .........................................................................................................................2
Cum definim Nexus ........................................................................................................................2
Fundamentele Nexus......................................................................................................................2
Nexus Framework ..........................................................................................................................3 Proces Tehnologic Nexus ................................................................................................................4
Practici Software ............................................................................................................................4
Nexus .............................................................................................................................................. 5
Roluri Nexus...................................................................................................................................5
Echipa de integrare Nexus ...........................................................................................................5
Evenimentele Nexus .......................................................................................................................6
Planificarea Sprint-ului Nexus (Sprint Planning) .............................................................................7
Sedinta zilnica de Scrum Nexus (Daily Scrum) ................................................................................7
Revizuirea Sprint-ului Nexus (Sprint Review) .................................................................................8
Retrospectiva Sprint-ului Nexus....................................................................................................8
Redefinire ...................................................................................................................................9 Artefactele Nexus...........................................................................................................................9
Backlog-ul produsului (Product Backlog) .......................................................................................9
Misiunea Nexus...........................................................................................................................9
Backlog-ul Sprint-ului Nexus (Sprint Backlog) .............................................................................. 10
Incrementare integrata.............................................................................................................. 10
Transparenta Artefactului............................................................................................................. 10
Definitia starii “Finalizat” (Definition of “Done”) .......................................................................... 10
Nota de final ................................................................................................................................ 11
Constatari .................................................................................................................................... 11
Traslated By:
Teodor Birca & Cristina Abunei
Copyright Scrum.org, 2015 All Rights Reserved Page 2 (Version 1.1)
Nexus privire de ansamblu
Scopul ghidului Nexus Nexus e un cadru folosit pentru dezvoltarea și sustinerea unui produs software scalabil și
dezvoltarea unei initiative software. Nexus va avea la baza metoda Scrum. Acest ghid contine
definitia Nexus. Aceasta definitie consta in rolulrile Nexus, evenimentele, artefactele si regulile
care le unesc. Ken Schwaber si Scrum.org au dezvoltat Nexus. Ghidul Nexus e scris si oferit de
catre ei.
Definitia Nexus Nexus (n): Unitate de dezvoltare (in Scrumul Professional Scalabil)
Nexus e un framework care consista in roluri, evenimente, artefacte si tehnicile care le tin
impreuna munca a approximativ trei pana la noua Echipe Scrum muncind pe acelasi coada de
asteptare (Product Backlog) pentru a creea o incrementare integrata care va acoperi obiectivul.
Fundamentele Nexus Dezvoltarea software e complexa, iar integrarea acesteia intr-un software care functioneaza are
multe artefacte si activitati care trebuiesc coordonate pentru a crea un produs bun. Munca
trebuie organizata, impartita, dependentele rezolvate si rezultatele organizate. Produsul
software prezinta mai multe dificultati de vreme ce nu e un produs fizic.
Foarte multi programatori au folosit framework-ul Scrum pentru a lucra impreuna, ca o echipa,
pentru a dezvolta incrementari functionale ale unui produs software. Totusi, daca mai mult de o
echipa Scrum lucreaza pe acelasi Product Backlog si in acelasi cod sursa pentru un produs,
dificultatile apar. Daca developerii nu sunt in aceeasi echipa ca si locatie, cum vor comunica
cand vor scrie cod care ar putea afecta munca celorlalti? Daca lucreaza in echipe diferite cum
vor integra codul lor si cum vor testa integrarea incrementala? Aceste provocari apar cand doua
echipe conlucreaza si devine substantial mai dificil cu trei sau mai multe echipe.
Aici sunt multe dependente care pot aparea in munca mai multor echipe ce colaboreaza pentru
a crea o incrementare finalizata, “Done”, macar in fiecare Sprint. Aceste dependente sunt
inrudite cu :
1. Cerintele: Scopul cerintelor poate fi comun, iar modul in care sunt implementate poate
afecta implementarea celorlalte. Aceste detalii trebuie avute in vedere cand ordonam
backlog-ul produsului si selectam cerintele.
2. Aria de cunoastere: Persoanele din echipa au diverse cunostinte despre afacere si/sau
sistemele computerizate. Acele cunostinte trebuiesc folosite de catre Scrum Master
pentru a minimiza blocajele intre echipe in timpul unui Sprint.
3. Softwareul si artefactele de test: Cerintele sunt sau vor aparea in cod si in seturile de
teste.
Copyright Scrum.org, 2015 All Rights Reserved Page 3 (Version 1.1)
Pentru a extinde aceste cereri, cunostintele membrilor echipei si artefactele de cod/test sunt
mapate catre aceeasi echipa Scrum pentru ca dependentele intre echipe sa fie reduse.
Cand dezvoltarea software folosind Scrum e scalabila, aceste dependente de cerinte,
cunostinte in domeniu si teste/artefacte software ar trebui sa conduca la organizarea echipei.
De asemenea, productivitatea va fi optimizata.
Framework-ul Nexus Nexus e un exoschelet situat deasupra mai multor echipe de Scrum combinate pentru a crea o
integrare incrementala. Nexus e consistent cu metoda Scrum si partile componente vor fi
familiare acelora care au lucrat in proiecte Scrum. Diferenta e ca mai multa atentie e data
dependentelor si cooperarii intre echipele Scrum pentru a livra cel putin o incrementare
integrata “Done” in fiecare sprint.
Dupa cum e vizibil in aceasta diagrama, Nexus consista in:
● Roluri: un nou rol, Echipa de Integrare Nexus, exista pentru a coordona, sfatui si
superviza aplicarea metodei Nexus si operarea Scrum pentru a obtine cele mai bune
rezultate. Echipa de Integrare Nexus consista in Product Owner, Scrum Master si
membrii echipei de integrare Nexus.
● Artefacte: Toate echipele Scrum folosesc acelasi backlog al produsului. Pe masura ce
elementele din Backlog-ul Produsului sunt revizuite si finalizate, acestea vor avea
indicatori vizuali cu marca echipei ce va lucra la ei. Ca un nou artefact, Backlogul Sprint-
ului Nexus exista pentru a oferi transparenta pe durata sprint-ului. Toate echipele Scrum
au grija de propriile Backlog-uri pentru Sprint.
● Evenimente: Evenimentele sunt atasate, plasate sau inlocuiesc (in cazul unui Sprint
Review) evenimente Scrum obisnuite. Cand sunt modificate, ele ajuta la efortul comun al
tuturor echipelor Scrum in Nexus, dar si pe fiecare echipa in parte.
Nexus™ Framework, exoschelet al unui Scrum scalabil
Copyright Scrum.org, 2015 All Rights Reserved Page 4 (Version 1.1)
Procesul de desfasurare Nexus Dezvoltarea in Nexus poate fi facuta de toti membrii echipei de Scrum. In functie de
dependente, echipele pot selecta pe cei mai in masura membri pentru un anumit task.
● Revizuirea Backlog-ului: Backlog-ul Produsului trebuie descompus in parti mai mici
pentru a identifica, inlatura sau minimiza dependentele. Elementele din Backlog sunt
impartite in parti functionale mai mici, iar membrii echipei responsabili de implementare
ar trebui identificati cat mai repede posibil.
● Planificarea unui Sprint Nexus: Reprezentati ai fiecarei echipe Scrum trebuie sa discute
si revizuiasca impartirea Backlogului. Ei ai trebui sa imparta itemii in functie de
responsabilul de implementare. Ulterior fiecare echipa trebuie sa isi planuiasca propriul
Sprint si sa interactioneze cu cealalte echipe. Rezultatul va fi o serie de obiective pentru
Sprint ce vor reflecta scopul principal Nexus, un Scrum Backlog Sprint pentru fiecare
echipa si un singur Nexus Sprint Backlog. Nexus Sprint Backlog face Backlog-ul Scrum-
ului pentru fiecare echipa in parte, cat si dependentele acestora cat mai transparente.
● Dezvoltarea: Toate echipele dezvolta software ce va fi cat mai frecvent integrat in mediul
de dezvoltare comun pentru a putea fi testat si a a ne asigura ca integrarea e corecta.
● Scrum-ul Zilnic Nexus: Reprezentati ai fiecarei echipe se intalnesc zilnic pentru a discuta
dificultati de implementare, daca acestea exista. Daca se gasesc astfel de situatii,
acestea trebuie comunicate ulterior catre echipa. Echipele de Scrum au propriul Scrum
Zilnic pentru a crea un plan de dezvoltare pentru ziua in curs si pentru a rezolva
problemele de integrare discutate la Scrum-ul Zilnic Nexus.
● Analiza Sprint-ului Nexus: Toate echipele trebuie sa discute alaturi de Managerul de
Produs integrarea incrementala. In timpul sedintei pot fi aduse ajustari Backlog-ului
Produsului.
● Retrospectiva Sprint-ului Nexus: Reprezentati ai fiecarei echipe se intalnesc pentru a
discuta si identifica dificultati de implementare. De asemenea fiecare echipa are propria
Retrospectiva a Sprint-ului. Reprezentati ai fiecarei echipe se intalnesc din nou pentru a
discuta solutii pentru rezolvarea dificultatilor de implementare.
Practici de dezvoltare software Multe practici de dezvoltare de software sunt necesare pentru a lega activitatea echipelor
Scrum ce colaboreaza pentru a crea o integrare incrementala . Cele mai multe dintre aceste
practici necesita automatizare. Automatizarea ajuta echipele sa gestioneze volumul si
complexitatea lucrarilor si artefacte in special in mediile scalate.
Copyright Scrum.org, 2015 All Rights Reserved Page 5 (Version 1.1)
Nexus
Rolurile Nexus, evenimentele si artefacte mostenesc scopul si atributele dorite pentru a fi
corespunzatoare rolurilor Scrum, evenimentelelor si artefactelor, așa cum este documentat in
Ghidul Scrum .
Roluri Nexus Un Nexus este format dintr-o echipa Nexus pentru integrare si aproximativ trei pana la noua
echipe Scrum .
Echipa de Integrare Nexus
Echipa de Integrare Nexus este responsabila pentru a se asigura ca avem o incrementare
integrata (lucrarea combinata finalizata de un Nexus) este produsa cel putin in fiecare Sprint .
Echipele Scrum sunt responsabile pentru dezvoltarea Incrementelor software-ului potential
eliberabil, așa cum este prescris in Scrum. Toate rolurile pentru membrii echipelor Scrum sunt
mentionate in Ghidul Scrum .
Echipa de integrare Nexus e o echipa Scrum care este formata din:
● Responsabilul de Produs (Product Owner)
● Un Scrum Master
● Unul sau mai multi membrii ai Echipei de integrare Nexus
Membrii ai Echipei de integrare Nexus pot lucra, de asemenea, in echipele Scrum sau in Nexus,
dupa caz, daca este necesar. Daca este cazul, trebuie acordata prioritate pentru Echipa de
Integrare Nexus. Calitatea de membru in Echipa de Integrare Nexus are prioritate fata de a fi
membru individual al echipei Scrum. Aceasta ofera siguranta ca activitatea de rezolvare a
problemelor care afecteaza mai multe echipe are prioritate.
Componenta echipei de integrare Nexus se poate modifica in timp pentru a reflecta nevoile
actuale ale unui Nexus . Printre activitatile comune ale echipei de integrare ar fi coaching-ul,
consultanta, subliniind gradul de constientizare a dependentelor si a problemelor intre echipe. Ei
ar putea efectua, de asemenea, o parte din lista de task-uri din Backlog.
Echipa Nexus de Integrare va avea proprietate pe orice problema de integrare. Este
responsabila pentru integrarea cu succes a tuturor lucrarilor de catre toate echipele Scrum intr-
un Nexus. Integrarea include rezolvarea oricaror constrangeri de ordin ethnic, dar si non-
tehnice, intre echipe care ar putea impiedica abilitatea unui Nexus de a oferi un increment
constant. Acestea ar trebui sa foloseasca inteligenta de jos in sus de la Nexus pentru a obtine
rezolutia.
Copyright Scrum.org, 2015 All Rights Reserved Page 6 (Version 1.1)
Responabilul de Produs (Product Owner) in Echipa de Integrare Nexus
Un Nexus lucreaza pe un singur Backlog si asa cum s-a descris in cadrul Scrum, un Backlog
are un singur Product Owner care are ultimul cuvant cu privire la continutul acestuia. Product
Owner-ul este responsabil pentru maximizarea valorii produsului si a lucrarilor efectuate si
integrate de catre echipele Scrum. Product Owner-ul este in Echipa de Integrare Nexus .
Product Owner-ul este responsabil pentru a comanda si rafina Backlog-ul , astfel incat valoarea
maxima este derivata din incrementarea integrata creata de un Nexus. Modul in care acest
lucru este realizat poate varia foarte mult in organizatii, Nexus-uri , echipe Scrum si individuali.
Scrum Master-ul in Echipa de Integrare Nexus
Scrum Master-ul in Echipa de Integrare Nexus are responsabilitatea globala ca Nexus sa fie
inteles si adoptat corect. Acest Scrum Master poate fi Scrum Master in una sau mai multe
Echipe Scrum in cadrul aceluiasi Nexus.
Membrii Echipei de Integrare Nexus
Dezvoltarea scalabila necesita unelte si practici ce in mod individual, echipele Scrum s-ar putea
sa le nu foloseasca foarte frecvent. Echipa de integrare Nexus consta din profesionisti software
ce sunt antrenati cu aceste practici, unelte si au cunostinte generale despre ingineria
sistemelor. Membrii echipei de Integrare Nexus se asigura ca practicile si uneltele sunt correct
implementate, intelese si folosite, identifica dependente si integreaza cat de frecvent posibil
artifacte cu definitia de “Done”.
Membrii Echipei de Integrare Nexus sunt responsabili de a superviza si a ghida in mediul Nexus
pentru implementarea si utilizarea corecta a acestor unelte. Aditional, acestia pot ghida echipele
de Scrum pentru dezvoltarea de software, parte de infrastructura, sau standarde arhitecturale
cerute de organizatie pentru a asigura o dezvoltare de calitate a Incrementarii Integrate.
Daca principala reponsabilitate este indeplinita, Membrii Echipei de Integrare Nexus pot de
asemenea lucra ca membri ai echipei de dezvoltare in una sau mai multe echipe Scrum.
Evenimente Nexus Durata evenimentelor Nexus e ghidata de durata evenimentelor corespunzatoare in Ghidul
Scrum. Ele sunt incadrate in intervale de timp aditionale celor corespunzatoare evenimentelor
Scrum.
Copyright Scrum.org, 2015 All Rights Reserved Page 7 (Version 1.1)
Planificarea Sprint-ului Nexus
Scopul Planificarii Sprint-ului Nexus este de a coordona activitatile tuturor echipelor Scrum din
cadrul Nexus pe parcursul unui Sprint. Product Owner-ul trebuie sa ofere informatiile despre
domeniul de implementare si sa ghideze selectia task-urilor si prioritatea acestora.
La inceputul Planificarii Sprint-ului Nexus, membrii reprezentativi ai fiecarei echipe Scrum
valideaza si ajusteaza ordinea creata in timpul evenimentului de Redefinire (Refinement). Toti
membrii echipei Scrum ar trebui sa participe pentru a minimiza problemele aparute din cauza
comunicarii.
Obiectivul Sprintului Nexus este stabilit in timpul Planificarii Sprint-ului Nexus (Sprint Planning).
Acesta descrie scopul ce trebuie atins de Echipele Scrum in timpul Sprint-ului. Odata stabilita
vederea de ansamblu, fiecare echipa Scrum va avea propria sesiune de Planificare a Sprintului.
Daca Planificarea in cadrul echipelor Scrum are loc in aceeasi locatie, acestea pot discuta noile
dependente gasite. Planificarea Sprintului Nexus se incheie cand toate echipele termina
evenimentele din Planificarea Sprintului.
Noi dependente ar putea aparea in timpul unei Plananificari de Sprint Nexus. Ele ar trebui
vizualizate si minimizate. O secventa de implementare intre echipe poate fi de asemenea
planificata. Un Backlog al Produsului bine structurat va minimiza aparitia noilor acareturi in
timpul unuei Planificari ale Sprintului Nexus. Toate tasku-urile Backlog-ului Produsului selectate
pentru un Sprint si dependentele acestora trebuie sa fie vizibile in cadrul Sprint Backlog-ului
Nexus.
Backlog-ul Produsului (Product Backlog) ar trebui structurat in functie de dependentele
identificate si eliminate sau diminuate inainte de Planificarea Sprint-ului Nexus (Sprint
Planning).
Scrum-ul Zilnic Nexus
Scrum-ul Zilnic Nexus e un eveniment al echipelor de dezvoltare pentru a identifica stadiul
implementarii Incremental Integrate si de a identifica probleme de integrare sau de a discuta noi
acareturi descoperite.
In timpul Scrum-ului Zilnic Nexus, participatii ar trebui sa se axeze pe impactul fiecarei echipe in
cadrul Integrarii Incrementale si sa discute:
● Ce a fost integrat cu succes ziua precedenta? Daca nu, de ce?
● Ce noi dependente au fost indentificate?
● Ce informatii trebuie impartasite cu ceallate echipe Nexus?
Copyright Scrum.org, 2015 All Rights Reserved Page 8 (Version 1.1)
In timpul Scrum-ului Zilnic Nexus, Backlog-ul Sprint-ului Nexus ar trebui folosit pentru
vizualizarea si managementul dependentelor curente.
Implenetarea identificata in timpul Scrum-urilor Zilnice Nexus este discutata individual cu
echipele de Scrum pentru a planifica dezvoltarea in cadrul propriului Scrum Zilnic.
Revizuirea Sprint-ului Nexus
Revizuirea Sprint-ului Nexus (Sprint Review) are loc la sfarsitul Sprint-ului pentru a oferi
feedback in legatura cu integrarea incrementala realizata in Sprintul Nexus.
Revizuirea Sprintului Nexus inlocuieste revizuirea individuala a Scrum-ului pe Echipe, deoarece
integrarea incrementala e scopul central pentru feedback din partea participantilor. Este posibil
sa nu poata fi prezentata intreaga munca implementata, in detaliu. Anumite tehnici pot fi
necesare pentru a obtine un feedback cat mai bun din partea participantilor.
Retrospectiva Sprint-ului Nexus
Retrospectiva Sprint-ului Nexus e o oportunitate formala pentru Nexus de a se concentra pe
examinare si adaptare. Aceasta consta din 3 parti:
1. Prima parte e o oportunitate pentru reprezentantii echipelor Nexus sa se intalneasca si
sa identifice problemele care le-ar putea intampina cel putin una din echipe. Scopul
principal este de a evidentia problemele comune catre toate Echipele Scrum.
2. Pentru partea a doua, fiecare echipa Scrum trebuie sa isi prezinte propria retrospectiva
a sprint-ului dupa cum o descrie framework-ul Scrum. Ei se pot folosi de problemele
evidentiate in prima parte a Retrospectivei Nexus ca parte definitorie a deciziilor echipei.
Actiunile impuse de acestea ar trebui discutate in cadrul Retrospectivei Individuale pe
Echipe.
3. A treia parte si ultima, este o oportunitate pentru reprezentatii Echipelor Scrum de a se
intalni din nou pentru a cadea de acord asupra vizualizarii problemelor si a modului de
urmarire a acestora. Lucrul acesta permite Nexus-ului sa se adapteze.
Din cauza disfunctiilor de scalare comune, fiecare Retrospectiva ar trebui sa se adreseze
urmatoarelor subiecte:
● Au ramas lucruri neterminate? Nexus a intampinat probleme tehnice?
● Toate artefactele, in particular codul, (cat de frecvent) a fost integrat cu succes?
● A fost software-ul construit cu success, testat si implementat suficient de des incat sa
previna acumularea dependentelor nerezolvate?
Pentru fiecare din intrebarile de mai sus, a se adresa daca e necesar:
● De ce s-a intamplat?
● Cum pot fi rezolvate problemele tehnice?
● Cum pot fi prevenite astfel de evenimente?
Copyright Scrum.org, 2015 All Rights Reserved Page 9 (Version 1.1)
Redefinire (Refinement)
In cadrul Nexus exista mai multe nivele de Redefinire. Doar atunci cand elementele din
Backlog-ul Produsului sunt independente, acestea pot fi selectate si se poate incepe
dezvoltarea fara a avea conflicte intre Echipele Scrum din cadrul Nexus.
Numarul, frecventa, durata si prezenta in cadrul sedintelor de Redefinire are la baza
dependentele inerente in Backlog-ul Produsului. Cu cat complexitatea si dependentele sunt mai
mari, cu atat mai mult Backlog-ul Produsului trebuie Redefinit si dependentele inlaturate. Task-
urile din Backlog-ul Produsului trec prin mai multe nivele de descompunere de la cerinte foarte
mari si vage, la ceva implementabil in cadrul unui Sprint de catre o singura echipa.
Backlog-ul Produsului redefinit in acest fel, serveste un dublu scop. Indica ce echipa va livra un
anumit element din Backlog si identifica dependentele intre echipe. Vizualizarea ajuta echipele
sa monitorizeze si minimizeze dependentele.
Prima parte a Redefinirii intre echipe trebuie petrecuta impartind task-urile din Backlog in parti
atat de detaliate, incat se poate prezice care echipa e responsabila de livrarea lor si cand
anume se pot pune in Sprint-urile viitoare.
A doua parte a Redefinirii trebuie dedicata dependentelor. Acestea ar trebui identificate si
vizualizate la nivel de echipa si de Sprint-uri. Echipele au nevoie de aceste informatii pentru a
reordona si aloca timpul necesar pentru minimizarea numarului de dependente din cadrul
echipelor.
Sunt necesare intalniri de redefinire pana cand elementele din Backlog sunt gata si selectabile
cu un minim de dependente pe durata unei sedinte de Planificare a Sprint-ului.
Artefacte Nexus Artefactele reprezinta efortul sau valoarea pentru a oferi transparenta si oportunitati pentru
inspectie si adaptare, asa cum s-a descris in Ghidul Scrum .
Backlog-ul
Exista un singur Backlog pentru intregul Nexus si toate echipele sale Scrum . Product Owner-ul
este responsabil pentru Backlog, inclusiv continutul, disponibilitatea si ordonarea lui.
La scara, Backlog-ul trebuie sa fie inteles la un nivel la care pot fi detectate dependente si pot fi
reduse la minimum . Pentru a sprijini rezolutia, elementele Backlog sunt adesea rezolvate la o
granularitate numita functionalitate " taiat in felii subtiri " . Articolele Backlog-ului sunt
considerate " gata " pentru Planificarea Sprint-ului Nexus atunci cand acestea pot fi selectate
pentru a fi efectuate de catre echipele Scrum fara dependente sau dependente minime cu alte
echipe Scrum .
Copyright Scrum.org, 2015 All Rights Reserved Page 10 (Version 1.1)
Scopul Nexus
In timpul sedintei de Planificare a Sprint-ului Nexus, se formuleaza un obiectiv pentru intregul
Sprint. Aceasta se numeste Obiectivul Nexus . Este suma tuturor lucrarilor si a Obiectivelor
Scrum individuale si din cadrul echipelor Scrum Nexus . Nexus ar trebui sa demonstreze
functionalitatea pe care ei au dezvoltat pentru a atinge Obiectivul Nexus in sedinta Nexus Sprint
Review .
Nexus Sprint Backlog
Un Nexus Sprint Backlog este compus din toate elementele din backlog-uri si Sprint Backlog-ul
echipelor Scrum . Este folosit pentru a evidentia dependente si fluxul de lucru in timpul Sprint-
ului . Acesta este actualizat cel putin zilnic, de multe ori, ca parte a Nexus Daily Scrum .
Incrementarile Integrate
Incrementarile Integrate reprezinta suma tuturor lucrarilor integrate completate de un Nexus .
Incrementarile Integrate trebuie sa fie utilizabile si gata pentru un release ceea ce inseamna ca
trebuie sa indeplineasca definitia "Done". Incrementarile Integrate sunt inspectate in Nexus
Sprint Review .
Transparenta Artefactelor
Identic ca si in construirea pe parti, Scrum , Nexus se bazeaza pe transparenta. Echipa de
Integrare Nexus lucreaza cu echipele Scrum intr-un Nexus pentru a se asigura ca transparenta
este evidenta in toate artefactele si ca starea integrata a incrementului este inteleasa.
Deciziile efectuate pe baza de artefacte Nexus sunt la fel de eficace ca si nivelul de
transparenta artefact. Informatii incomplete sau partiale vor duce la decizii incorecte sau
eronate. Impactul acestor decizii pot fi amplificate la scara Nexus. Lipsa de transparenta totala
va face imposibila ghidarea unui Nexus in mod eficient, in scopul de a minimiza riscurile si a
maximiza valoarea .
Software-ul trebuie sa fie dezvoltat astfel incat dependentele tehnice sa fie detectate si
rezolvate inainte ca ele sa devina inacceptabile. Inacceptabilitatea se poate vedea atunci cand
are loc integrarea, si e neclar faptul ca toate dependentele sunt rezolvate. In aceste cazuri,
dependentele nerezolvate raman ascunse in cod si in teste, scazand valoarea totala a software-
ului.
Definitia “Done”
Echipa de Integrare Nexus este responsabila pentru definitia " Done ", care poate fi aplicata
incrementului Integrat dezvoltat in fiecare Sprint. Toate echipele Scrum Nexus trebuie sa adere
Copyright Scrum.org, 2015 All Rights Reserved Page 11 (Version 1.1)
la aceasta definitie "Done". Incrementul este " Done ", numai daca versiunea e utilizabila si
potential livrabila.
Un element Backlog poate fi considerat " Done " , atunci cand aceasta functionalitate a fost
adaugata cu succes la produs si integrat in increment. Toate echipele Scrum sunt responsabile
pentru dezvoltarea si integrarea activitatii lor intr-un increment care satisface aceste atribute.
Echipele Individuale Scrum pot alege sa aplice o definitie mai stricta a " Done ", in cadrul
propriilor lor echipe, dar nu se pot aplica criterii mai putin riguroase decat convenite pentru
Increment .
Nota de Final
Nexus este gratuit si oferit in acest ghid, la fel ca si in cadrul Scrum, rolurile Nexus , artefacte,
evenimente si regulile sunt imuabile. Chiar daca punerea in aplicare a doar o parte din Nexus
este posibila, rezultatul nu este Nexus.
Nexus si Scrum Professional la Scara au fost dezvoltate in colaborare de Ken Schwaber, David
Dame, Richard Hundhausen, Patricia Kong, Rob Maher, Steve Porter, Christina Schwaber și
Gunther Verheyen.
