Nexus Guide Den definitive guide til Nexus: Et ydre skelet for skaleret Scrum udvikling Udarbejdet og vedligeholdt af Ken Schwaber og Scrum.org August 2015
Indholdsfortegnelse Nexus overblik... 2 Formålet med Nexus Guide...2 Definition af Nexus...2 Baggrunden for Nexus...2 Nexus rammeværk...3 Nexus proces flow...4 Software processer...4 Nexus... 4 Nexus Roles...5 Nexus Integration Team...5 Nexus Events...6 Nexus Sprint Planning...6 Nexus Daily Scrum...7 Nexus Sprint Review...7 Nexus Sprint Retrospective...7 Refinement...8 Nexus Artifacts...9 Product Backlog...9 Nexus Goal...9 Nexus Sprint Backlog...9 Integrated Increment...9 Gennemsigtighed af Artifact... 10 Definition of Done... 10 Slut bemærkninger... 10 Anerkendelse... 10 TRANSLATED BY: Stig Efsen LinkedIn Copyright Scrum.org, 2015 All Rights Reserved Page 1 (Version 1.1)
Nexus overblik Formålet med Nexus Guide Nexus er et rammeværk der anvendes ved udvikling og vedligehold af skalerede produkt- og softwareudvikling initiativer. Det benytter Scrum som sine byggesten. Denne guide indeholder definitionen af Nexus. Denne definition består af Nexus roles, events, artifacts, samt de regler der binder dem sammen. Ken Schwaber og Scrum.org har udviklet Nexus og er stillet til rådighed af dem. Definition af Nexus Nexus (n): Enhed for udvikling (i skaleret Professional Scrum) Nexus er et rammeværk og består af roles, events og artifacts, samt de teknikker der binder og sammenfletter arbejdet af mellem tre til ni Scrum Teams, der arbejder på én fælles Product Backlog for at udvikle et Integrated Increment som opfylder et mål. Baggrunden for Nexus Software udvikling er kompleks og integrationen af arbejdet i working software har mange artefakter og aktiviteter som skal koordineres for at skabe et resultat der er Done. Arbejdet skal tilrettelægges, nedbrydes i rækkefølge og afhængigheder skal være løst. Slut resultatet skal være planlagt. Software indeholder yderligere udfordringer, idet der ikke er tale om et fysisk produkt. Mange software udviklere benytter Scrum rammeværket til at arbejde i teams for at udvikle et Increment af working software. Men hvis mere end ét Scrum Team arbejder på den samme Product Backlog og i en fælles codebase for et produkt, opstår der udfordringer. Hvis udviklerne ikke sidder i et fælles team på samme lokalitet, hvordan skal de så kommunikere når de arbejder på opgaver der afhænger af hinanden? Hvis de arbejder i forskellige teams, hvordan skal de så integrere deres arbejde og teste det til et Integrated Increment? Disse udfordringer opstår når to eller flere teams arbejder sammen, og bliver signifikant mere besværligt med tre eller flere teams. Der er mange afhængigheder der opstår i arbejdet mellem multible teams der samarbejder om at frembringe et komplet og Done Increment mindst hver Sprint. Disse afhængigheder er relateret til: 1. Krav: Scope af kravene kan overlappe hinanden, og måden hvorpå de udvikles kan også påvirke hinanden. Denne viden bør tages i betragtning når man ordner Product Backlog og udvælger krav. 2. Domæne viden: Team medlemmer har forskellig viden om forretning og teknologi. Denne viden bør fordeles i Scrum Teams for at sikre at der er tilstrækkelig viden i de enkelte teams og for at minimere forstyrrelser mellem teams under et Sprint. 3. Software og test artefakter: Krav er eller vil blive afspejlet i software code og test suiter. Copyright Scrum.org, 2015 All Rights Reserved Page 2 (Version 1.1)
I det omfang at krav, teammedlemmers viden, og code/test artefakter er knyttet til samme Scrum Teams, så kan afhængigheder mellem teams blive reduceret. Når Scrum software udvikling skaleres bør disse afhængigheder af krav, domæne viden og software/test artefakter drive hvordan team organiseres. I det omgang det er tilfældet vil produktiviteten blive optimeret. Nexus rammeværk Nexus er et ydre skelet, der hviler på toppen af flere Scrum Teams når de kombineres for at skabe et Integrated Increment. Nexus er i overensstemmelse med Scrum og dens bestanddele vil være velkendt for dem, der har arbejdet på Scrum projekter. Forskellen er, at der fokuseres mere på afhængigheder og samspil mellem Scrum Teams, om at levere et "Done" Integrated Increment mindst hver Sprint. Som vist i den efterfølgende grafik består Nexus af: Roles: En ny rolle, Nexus Integration Team, er til for at koordiner, coache og vejlede brugen af Nexus og Scrum så det bedste resultat opnås. Nexus Integration Team består af en Product Owner, en Scrum Master samt Nexus Integration Team medlemmer. Artifacts: Alle Scrum Teams benytter en og samme Product Backlog. Når Product Backlog items bliver uddybet og gøres Sprint ready, vil indikatorer for hvilket team der skal implementere opgaven i et Sprint gøres synlig. Et nyt artefakt, Nexus Sprint Backlog, er oprettet for at hjælpe med at synliggøre arbejdet under Sprintet. Alle Scrum Teams vedligeholder deres egen Sprint Backlog. Events: Events tilføjes, omkranser, eller erstatter (for Sprint Reviews vedkommende) de normale Scrum events for at udvide dem. I modificeret udgave understøtter de både den overordnede indsats for alle Scrum Teams i Nexus og de individuelle teams. Nexus Framework, exoskeleton of scaled Scrum Copyright Scrum.org, 2015 All Rights Reserved Page 3 (Version 1.1)
Nexus proces flow Alt arbejde i et Nexus kan udføres af alle medlemmer i Scrum Teams, som cross-functional medlemmer af et Nexus. Ud fra afhængigheder kan teams vælge det bedst egnede medlem til en specifik opgave. Detaljering af Product Backlog: Product Backlog skal nedbrydes så afhængigheder er identificeret, fjernet eller minimeret. Product Backlog items er nedbrudt i små dele af funktionalitet og det team der skal udføre opgaven skal identificeres så tidligt i processen som muligt. Nexus Sprint Planning: Passende repræsentanter fra hvert Scrum Team mødes for at diskutere og reviewe den nedbrudte Product Backlog. De vælger Product Backlog items for hvert team. Hvert Scrum Team planlægger sit eget Sprint og samarbejder med øvrige teams efter behov. Resultatet er et antal Sprint Goals, som tilsammen opfylder det overordnede Nexus Goal, hvert Scrum Team's Sprint Backlog og en enkel Nexus Sprint Backlog. Nexus Sprint Backlog udgør Scrum Team's valgte Product Backlog items og enhver afhængighed transparent. Development work: Alle teams udvikler software og integrerer hyppigt deres arbejde i et fælles miljø og sikrer at integrationtests er gennemført. Nexus Daily Scrum: Passende repræsentanter fra hvert Scrum Development Team mødes dagligt for at identificere om der er udfordringer med integrationen. Hvis der er dette så tages denne information med tilbage til hvert Scrum Team s Daily Scrum. Scrum Teams benytter herefter deres Daily Scrum til at udarbejde en plan for dagen, hvor det sikres at udfordringerne med integration fra Nexus Daily Scrum bliver adresseret. Nexus Sprint Review: Alle teams mødes med Product Owner for at reviewe Integrated Increment. Justeringer til Product Backlog kan forekomme. Nexus Sprint Retrospective: Passende repræsentanter fra hvert Scrum Team mødes for at identificere fælles udfordringer. Herefter holder hvert Scrum Team individuelle Sprint Retrospectives. For at give en buttom-up tilgang mødes passende repræsentanter fra hvert team igen for at diskutere de nødvendige aktioner der skal igangsættes baseret på de fælles udfordringer. Software processer Mange software udviklingsprocesser er nødvendige for at sammenkoble resultater af Scrum Teams, der samarbejder om at skabe et Integrated Increment. De fleste af disse processer kræver automatisering. Automatisering hjælper med at styre størrelsen og kompleksiteten af arbejdet og de artefakter der er specielle især i et skalerbart miljø. Nexus Nexus roles, events og artifacts nedarver formål og hensigt fra de tilsvarende Scrum roles, events og artifacts, som dokumenteret i Scrum Guide. Copyright Scrum.org, 2015 All Rights Reserved Page 4 (Version 1.1)
Nexus Roles Et Nexus består af et Nexus Integration Team og ca. tre til ni Scrum Teams. Nexus Integration Team Et Nexus Integration Team er ansvarlig for at et Integrated Increment (det samlede arbejde færdiggjort af et Nexus) er leveret mindst en gang hvert Sprint. Scrum Teams er ansvarlige for udvikling af Increments af potentially releasable software, som foreskrevet in Scrum. Alle roller for medlemmer af Scrum Teams er som foreskrevet i Scrum Guide. Et Nexus Integration Team er et Scrum Team som består af: Product Owner Scrum Master Et eller flere Nexus Integration Team medlemmer Medlemmer af et Nexus Integration Team kan også arbejde i Scrum Teams i Nexus, hvis det er relevant og nødvendigt. Hvis dette er tilfældet, skal der gives prioritet til arbejdet for Nexus Integration Teamet. Medlemskab af et Nexus Integration Team har forrang for individuelle Scrum Team-medlemskab. Denne præference er med til at sikre, at arbejdet med at løse problemer, der påvirker mange hold har prioritet. Sammensætning af et Nexus Integration Team kan ændre sig over tid til at reflektere de aktuelle behov i et Nexus. Fælles aktiviteter et Nexus Integration Team kan udføre omfatter coaching, rådgivning, og at fremhæve bevidstheden om afhængigheder og cross-team udfordringer. Det kan også udføre arbejde fra Product Backlog. Nexus Integration Team'et tager ejerskab af eventuelle integrationsspørgsmål. Det har ansvaret for en vellykket integration af alt arbejde fra alle Scrum Teams i et Nexus. Integration omfatter at løse eventuelle tekniske og ikke-tekniske cross-team begrænsninger, der kan hindre et Nexus' evne til at levere en vedvarende Integrered Increment. De bør bruge bottom-up informationer fra Nexus for at løse udfordringerne. Product Owner i Nexus Integration Team Et Nexus arbejder ud fra en enkelt Product Backlog, og som beskrevet i Scrum rammerværket har en Product Backlog én Product Owner, der bestemmer over dens indhold. Product Owner er ansvarlig for at maksimere værdien af produktet og det arbejde der er udført og integreret af Scrum Teams. Product Owner er en del af et Nexus Integration Team. Product Owner er ansvarlig for at ordne og nedbryde Product Backlog så maksimal værdi leveres i Integrated Increment skabt af et Nexus. Hvordan dette skal gøres kan variere meget på tværs af organisationer, Nexus, Scrum Teams og enkeltpersoner. Copyright Scrum.org, 2015 All Rights Reserved Page 5 (Version 1.1)
Scrum Master in the Nexus Integration Team Scrum Master i et Nexus Integration Team'et har det overordnede ansvar for at sikre at Nexus rammerværket er forstået og følges. Denne Scrum Master kan også være en Scrum Master i et eller flere af de andre Scrum Teams i denne Nexus. Nexus Integration Team Members Skaleret udviklingsarbejde kræver værktøjer og processer, som de enkelte Scrum Teams måske ikke bruger så ofte. Nexus Integration Team'et består af software fagfolk, der er uddannet i brugen af disse processer, værktøjer og generelt indenfor systemudvikling. Nexus Integration Team medlemmer sikre, at praksis og værktøjer er implementeret, forstået, og anvendes til at påvise afhængigheder, og at alle artefakter integreres ofte til en "Done" tilstand. Nexus Integration Team medlemmer er ansvarlige for coaching og at vejlede Scrum Teams i et Nexus til at tilegne, implementere og lære disse processer og værktøjer. Derudover coacher de Scrum Teams indenfor nødvendige udviklings-, infrastruktur, eller arkitektoniske standarder, der kræves af organisationen for at sikre udviklingen af kvalitets Integrered Increments. Hvis deres primære ansvar er opfyldt, kan Nexus Integration Team medlemmer også arbejde som Development Team medlemmer i et eller flere Scrum Teams. Nexus Events Varigheden af Nexus begivenheder er styret af længden af de tilsvarende begivenheder i Scrum Guide. De er timeboxe i tillæg til deres tilsvarende begivenheder i Scrum. Nexus Sprint Planning Formålet med Nexus Sprint Planning er at koordinere aktiviteterne i alle Scrum Teams i et Nexus for en enkelt Sprint. Product Owner bidrager med domæneviden og guider udvælgelse og prioriterer beslutninger. Nexus Sprint Planning starter med, at relevante repræsentanter fra hver Scrum Team validerer og foretager tilpasninger til rækkefølgen af arbejdet som er skabt under Refinement begivenheder. Alle medlemmer af Scrum Teams bør deltage for at minimere tab af information. Nexus Sprint Goal formuleres i løbet af Nexus Sprint Planning. Den beskriver det formål, som vil blive opnået af Scrum Teams under Sprintet. Når det samlede arbejde for et Nexus er forstået, vil hver Scrum Team holde deres egen separate Sprint Planning. Hvis mødet gennemføres i et fælles lokale, kan Scrum Teams fortsætte med at dele nyligt fundne afhængigheder. Nexus Sprint Planning er færdig, når hver Scrum Team er færdig med deres individuelle Sprint Planning aktiviteter. Copyright Scrum.org, 2015 All Rights Reserved Page 6 (Version 1.1)
Nye afhængigheder kan opstå i løbet af Nexus Sprint Planning. De bør visualiseres og minimeres. Rækkefølgen af arbejdet på tværs af teams kan også justeres. Et tilstrækkeligt nedbrudt Product Backlog vil minimere fremkomsten af nye afhængigheder under Nexus Sprint Planning. Alle Product Backlog Items udvalgt til Sprint og deres afhængigheder skal visualiseres på Nexus Sprint Backlog. Product Backlog bør være tilstrækkeligt forfinet og identificerede afhængigheder bør være fjernet eller minimeret før Nexus Sprint Planning. Nexus Daily Scrum Nexus Daily Scrum er en begivenhed for relevante repræsentanter fra de enkelte Scrum Development Teams til at inspicere den aktuelle tilstand af Integrated Increment og for at identificere udfordringer med integrationen eller nyopdagede cross-team afhængigheder. Under Nexus Daily Scrum, bør deltagerne fokusere på hvert teams indvirkning på Integrated Increment og diskutere: Var den foregående dags arbejde succesfuldt integreret? Hvis ikke, hvorfor ikke? Hvilke nye afhængigheder er blevet identificeret? Hvilken information skal deles på tværs af teams i Nexus? Under Nexus Daily Scrum, bør Nexus Sprint Backlog bruges til at visualisere og administrere de nuværende afhængigheder. Arbejde, der er identificeret under Nexus Daily Scrum bliver derefter taget med tilbage til de enkelte Scrum teams for planlægning i deres Daily Scrum aktiviteter. Nexus Sprint Review Nexus Sprint Review afholdes i slutningen af Sprintet for at give feedback på det Integrated Increment et Nexus har leveret igennem Sprintet. En Nexus Sprint Review erstatter de individuelle Scrum Team Sprint Reviews, fordi hele Integrated Increment er i fokus under feedback fra interessenterne. Det kan være umuligt at vise alt afsluttet arbejde i detaljer. Forskellige teknikker kan være nødvendige for at maksimere feedback fra interessenterne. Nexus Sprint Retrospective The Nexus Sprint Retrospective er en formel mulighed for et Nexus til at fokusere på inspektion og tilpasning. Det består af tre dele: 1. Den første del er en mulighed for relevante repræsentanter fra hele Nexus til at mødes og identificere problemer, der har påvirket mere end et enkelt team. Formålet er at synliggøre disse problemer for alle Scrum Teams. Copyright Scrum.org, 2015 All Rights Reserved Page 7 (Version 1.1)
2. Den anden del består af, at hver Scrum Team holder deres eget Sprint Retrospective som beskrevet i Scrum Guide. De kan bruge problemer fra den første del af Nexus Retrospective som input til deres team diskussioner. De enkelte Scrum Teams bør oprette aktioner for at løse disse problemer i løbet af deres individuelle Scrum Team Sprint Retrospectives. 3. Tredje og sidste del er en mulighed for relevante repræsentanter fra Scrum Teams til at mødes igen og blive enige om, hvordan man kan visualisere og spore de identificerede tiltag. Dette gør det muligt for et Nexus at tilpasse sig som en helhed. Idet de er almindelige dysfunktioner ved skalering bør hver Retrospective behandle følgende emner: Var noget arbejde udeladt? Har Nexus genereret teknisk gæld? Blev alle artefakter, især kode, ofte (så ofte som hver dag) succesfuldt integreret? Var softwaren succesfuld bygget, testet og deployed ofte nok til at forhindre en uoverskuelig ophobning af uløste afhængigheder? For de ovennævnte spørgsmål, adressér om nødvendigt: Hvorfor skete det? Hvordan kan teknisk gæld fjernes? Hvordan kan en gentagelse forhindres? Refinement Ved skalering af Nexus er der mange niveauer af nedbrydning. Kun når Product Backlog items er tilstrækkeligt uafhængige kan de udvælges og arbejdes på uden en overdreven konflikt mellem Scrum Teams i et Nexus. Antallet, hyppighed, varighed og tilstedeværelse af Refinement møder er baseret på de afhængigheder der ligger i Product Backlog. Jo større kompleksitet og afhængigheder, jo mere skal Product Backlog nedbrydes for at fjerne afhængigheder. Product Backlog items passerer gennem forskellige niveauer af nedbrydning fra meget store og vage idéer til handlingsrettet arbejde, som et enkelt Scrum teamet kunne levere i et sprint. Product Backlog nedbrydning ved skalering tjener et dobbelt formål. Det forudsiger hvilket team der vil levere hvilke Product Backlog items, og det identificerer afhængigheder på tværs disse team. Visualisering giver teams mulighed for at overvåge og minimere afhængigheder. Den første del af cross-team Refinement bør bruges på at nedbryde Product Backlog items i tilstrækkelig detaljer til at forstå, hvilke team der kan levere dem, og i hvilken rækkefølge i løbet af kommende Sprints. Den anden del af Refinement bør bruges fokuseret på afhængigheder. Afhængigheder bør identificeres og visualiseres på tværs af teams og Sprints. Teams har brug for disse oplysninger Copyright Scrum.org, 2015 All Rights Reserved Page 8 (Version 1.1)
til at ændre på rækkefølgen og fordelingen af deres arbejde for at minimere antallet af crossteam afhængigheder. Tilstrækkelige antal Refinement møder er blevet afholdt under et Sprint, hvis Product Backlog items er klar og kan vælges med minimale afhængigheder under Sprint Planning mødet. Nexus Artifacts Artifacts repræsenterer arbejde eller værdi skabt for at give gennemsigtighed og mulighed for inspektion og tilpasning, som beskrevet i Scrum Guide. Product Backlog Der er én enkelt Product Backlog for hele Nexus og alle dets Scrum Teams. Product Owner er ansvarlig for Product Backlog, herunder dens indhold, tilgængelighed og rækkefølge af opgaver. Ved skalering skal Product Backlog forstås på et niveau, hvor afhængigheder kan identificeres og minimeres. For at understøtte dette må Product Backlog items ofte nedbrydes til et niveau kaldet "thinly sliced" funktionalitet. Product Backlog items anses for at være "ready" til Nexus Sprint Planning, når de kan vælges til implementering i Scrum Teams med ingen eller minimale afhængigheder med andre Scrum Teams. Nexus Goal Under Nexus Sprint Planning mødet formuleres et mål for hele Sprintet. Dette kaldes et Nexus Goal. Det er summen af al det arbejde og Sprint Goals for de enkelte Scrum Teams i et Nexus. Nexus skal demonstrere den funktionalitet, det er udviklet for at opnå et Nexus Goal, på Nexus Sprint Review. Nexus Sprint Backlog Et Nexus Sprint Backlog er sammensat af alle Product Backlog items fra Sprint Backlog i de enkelte Scrum Teams. Det bruges til at synliggøre afhængigheder og flow af arbejde i løbet af Sprintet. Den opdateres mindst en gang dagligt, ofte som en del af Nexus Daily Scrum. Integrated Increment Integrated Increment udgør summen af alt integreret arbejde afsluttet af en Nexus. Integrated Increment skal være brugbare og potentielt release bart hvilket betyder, at det skal opfylde definitionen på "Done". Integrated Increment inspiceres på Nexus Sprint Review. Copyright Scrum.org, 2015 All Rights Reserved Page 9 (Version 1.1)
Gennemsigtighed af Artifact Ligesom sin byggesten, Scrum, er Nexus baseret på gennemsigtighed. Et Nexus Integration Team arbejder med Scrum Teams inden for et Nexus og organisationen for at sikre, at gennemsigtighed er tydeligt på tværs af alle artefakter, og at den integrerede tilstand af Increment er bredt forstået. Beslutninger, der træffes på grundlag af tilstanden af Nexus artefakter er kun så effektive som niveauet for gennemsigtigheden af artefakter. Ufuldstændige eller delvise oplysninger vil føre til forkerte eller fejlagtige beslutninger. Virkningen af disse beslutninger kan forøges ved skalering af Nexus. En mangel på fuldstændig gennemsigtighed vil gøre det umuligt at guide en Nexus effektivt for at minimere risici og maksimere værdien. Software skal udvikles, så afhængigheder opdages og løses før teknisk gæld bliver uacceptabel. Uacceptable tekniske gæld forekommer når integrationen gennemføres, og det er uklart, om alle afhængigheder er løst. I disse tilfælde, forbliver de uløste afhængigheder skjult i koden og test base, hvilket sænke den samlede værdi af softwaren. Definition of Done Nexus Integration Team er ansvarlig for en definition af "Done", der kan anvendes til det Integrated Increment der bliver udviklet i hver Sprint. Alle Scrum Teams af et Nexus overholde denne definition af "Done". Increment er "Done", når det er brugbart og potentielt kan releases af Product Owner. En Product Backlog Item kan betragtes som "Done", når funktionaliteten er blevet føjet til produktet og succesfuldt integreret i Incrementet. Alle Scrum Teams er ansvarlige for at udvikle og integrere deres arbejde i et Increment, der opfylder dette. Individuelle Scrum Teams kan vælge at anvende en strengere definition af "Done" inden for deres eget team, men kan ikke anvende mindre strenge kriterier end aftalt for Increment. Slut bemærkninger Nexus er gratis og stilles til rådighed i denne Guide. Som med Scrum framework er Nexus' roles, artifacts, events og rules uforanderlige. Selvom det er muligt kun at anvende dele af Nexus, er resultatet ikke Nexus. Anerkendelse Nexus og Scaled Professional Scrum er i samarbejde udarbejdet af Ken Schwaber, David Dame, Richard Hundhausen, Patricia Kong, Rob Maher, Steve Porter, Christina Schwaber og Gunther Verheyen. Copyright Scrum.org, 2015 All Rights Reserved Page 10 (Version 1.1)