Scrum

Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den version , der blev gennemgået den 2. september 2022; checks kræver 27 redigeringer .
Scrum
Officiel side scrum.org
 Mediefiler på Wikimedia Commons

Scrum ( /skrʌm/ [1] ; scrum "  scrum") er en letvægtsramme, der hjælper mennesker, teams og organisationer med at skabe værdi gennem adaptive løsninger på komplekse problemer [2] .

Scrum kan bruges ikke kun inden for softwareudvikling, men også i andre fremstillingsindustrier [3] .

Udover at styre softwareudviklingsprojekter kan Scrum også bruges af softwaresupportteams som en tilgang til softwareudviklingsstyring og vedligeholdelse.

Der bør skelnes mellem Scrum [4] og Agile [5] .

Historie

De primære kilder til Scrum-metodologien var: Toyotas produktionssystem og OODA-cyklussen (OODA-sløjfen eller OODA-sløjfen eller Boyd-sløjfen) til konceptet med at bruge militær luftfart, som omfatter fire komponenter: observere (“observere”) , orientere ("orientere"), beslutte ("beslutte"), handle ("handle"). [6]

Selve tilgangen blev først beskrevet af Hirotaka Takeuchi og Ikujiro Nonaka i The New Product Development Game (Harvard Business Review, januar-februar 1986). De bemærkede, at projekter drevet af små tværfaglige teams har en tendens til systematisk at give bedre resultater, og de forklarede dette som "rugby-tilgangen".

I 1991 omtalte DeGrace og Stahl i deres bog Unholy Problems, Righteous Solutions [7] denne tilgang som scrum , et sportsudtryk opfundet i en artikel af Takeuchi og Nonaka. Ken Schwaber brugte den tilgang, der bragte Scrum til hans virksomhed begyndelsen af ​​1990'erne . Scrum-metoden blev først præsenteret for den brede offentlighed dokumenteret, klart defineret og beskrevet i fællesskab af Schwaber og Jeff Sutherland [6] på OOPSLA'95 [8] i Austin . K. Schwaber og D. Sutherland arbejdede sammen i løbet af de næste år for at bearbejde og beskrive al deres erfaring og bedste praksis for industrien i én helhed i den metodologi, der i dag er kendt som Scrum.

Schwaber gik sammen med Mike Beadle i 2001 for at beskrive metoden i detaljer i Agile Software Development med Scrum [9] .

I 2002 grundlagde Schwaber Scrum Alliance [10] sammen med andre og skabte en række certificerede Scrum-akkrediteringer. Schwaber forlod Scrum Alliance i slutningen af ​​2009 og grundlagde Scrum.org Archived December 10, 2019 at the Wayback Machine , som kuraterer Professional Scrum concurrent accreditation series [11] .

Siden 2009 har et offentligt dokument kaldet The Scrum Guide [12] officielt defineret Scrum. Den er blevet revideret over 5 gange. I 2018 udgav Schwaber og Scrum.org-fællesskabet sammen med ledere fra Kanban-fællesskabet Kanban Guide for Scrum Teams [13] .

Definitioner

Scrum

Scrum (eng. "scrum" - et udtryk fra rugby, betegner starttilstanden for hold, før de kaster bolden ind) - det minimum påkrævede sæt begivenheder, artefakter, roller, som Scrum-udviklingsprocessen er bygget på, hvilket giver mulighed for faste korte perioder af tid, kaldet sprints ( sprints ), for at give slutbrugeren et fungerende produkt med nye forretningsmuligheder, for hvilke den højeste prioritet er bestemt. Metoden er baseret på ideerne i artiklen af ​​Taekuchi og Nonaka " The New New Product Development Game ", såvel som teamwork, svarende til hvordan et hold i rugby arbejder sammen for at nå et fælles mål. Muligheder for implementering i næste sprint fastlægges af teamet ved sprintens begyndelse på Sprintplanlægningsmødet . For at estimere den kommende mængde arbejde i spurten, bruges oftest relative estimater og praksis med at planlægge poker (Planning Poker).

I slutningen af ​​sprintet mødes Scrum-teamet til et sprintgennemgangsmøde (Sprint Review - det gamle navn på Demonstration) med kunden og præsenterer ham for et forretningsprodukttilvækst (en produktversion med et komplet sæt funktioner, der kan allerede være givet til kunden og brugeren til brug), hvilket hun nåede at gøre i en spurt. Målet med Sprint Review er at få feedback fra kunden for at forstå, hvad der skal lægges vægt på i fremtiden, og hvad den næste stigning i forretningsproduktet skal være.

En strengt fastsat kort sprintvarighed (fra 1 til 4 uger) reducerer risici og gør det muligt hurtigt at få feedback fra kunden for at tilpasse produktvisionen.

Sprint

Sprint [14]  er en periode, der er tilstrækkelig til at fuldføre et planlagt sæt Scrum-operationer, hvis formål er at skabe en stigning i et forretningsprodukt. Rigtigt fast i tid. Varigheden af ​​en sprint er fra 1 til 4 uger. Jo kortere spurten er, jo mere fleksibel er udviklingsprocessen, udgivelserne kommer oftere, feedbacken fra kunden kommer hurtigere, der bruges mindre tid på at arbejde i den forkerte retning, men der bruges meget tid på sprintplanlægningsmøder, retrospektiver . På den anden side, med længere sprints, reducerer Scrum-teamet omkostningerne til møder, produktdemonstrationer osv. Forskellige teams vælger længden af ​​sprint i henhold til de særlige forhold i deres arbejde, tværgående teams og krav, ofte ved prøve- og fejl. For at estimere mængden af ​​arbejde i en sprint kan du bruge et foreløbigt estimat, målt i historiepoint. Et foreløbigt skøn over spurtens længde er registreret i projektefterslæbet ( produkt backlog ; se nedenfor).

Artefakter af Scrum

Nedbrændingsdiagram

Et diagram, der viser mængden af ​​udført arbejde og mængden af ​​tilbageværende arbejde i forhold til tiden til at udvikle et projekt, kaldes et nedbrændingsdiagram.

Disse diagrammer skal opdateres dagligt for at vise fremskridt og omkostninger i realtid i arbejdet med sprinten og projektet, tilgængelige for alle medlemmer af Scrum-teamet: Scrum Master og Product Owner.

Sprint burndown diagrammet viser, hvor mange opgaver der er udført, og hvor meget der mangler at blive gjort i den aktuelle sprint.

Projektefterslæb

Projektønskeloggen (projektbacklog) indeholder en liste over funktionalitetskrav, sorteret efter vigtighed, og dermed rækkefølgen af ​​implementering. Elementerne i denne log kaldes user stories ( user stories ) eller backlog items ( backlog items ). Projektefterslæbet er åbent for redigering af alle deltagere i Scrum-processen. Den ansvarlige for at vedligeholde projektefterslæbet er ejeren af ​​Scrum-produktet.

Sprint backlog

Sprint Ønskeliste (Sprint Backlog) - indeholder den funktionalitet, som produktejeren har valgt fra projektets backlog. Alle funktioner er opdelt i opgaver, som hver især evalueres af Scrum-teamet. På Sprint Planning Meeting bruges planlægningspokermetoden af ​​teamet til at estimere mængden af ​​arbejde, der skal gøres for at gennemføre spurten [15] .

Scrum board

Scrum Board er et værktøj til åbent at vise status for det igangværende arbejde i Scrum Teamet. Scrum board består af tre kolonner: "to do" ( to-do ), "i gang" ( i gang ), "done" ( færdig ).

Scrum Boardet indeholder hele omfanget af den Sprint Backlog, som teamet har udvalgt i Sprint Planning til implementering i det aktuelle sprint. Typisk placeres visitkort på tavlen fra top til bund i faldende prioritetsrækkefølge (øverst - vigtigst, nederst - mindst vigtig). Det er en god praksis at dekomponere forretningsopgaver i specifikt arbejde (teknisk, organisatorisk og andet), som teamet skal udføre for at gennemføre forretningsopgaven.

Forretningsopgaver og specifikke arbejdskort bevæger sig fra kolonne til kolonne i overensstemmelse med, hvordan teamet tager dem til udførelse (I gang) og fuldfører (Udført). For at give overblik over forløbet af teamets arbejde, vises "arbejdet fald" efter dag på nedbrændingsdiagrammet.

Oftest bruger teams i begyndelsen af ​​arbejdet tavler med flipover tegnet på ark, mens værkets navne er skrevet på klistermærker og limet til tavlen. Efterhånden som mødet skrider frem, flytter teamet fysisk sedler fra kolonne til kolonne.

Elektroniske tavler bruges også ofte, med lignende mekanismer implementeret i dem. For eksempel Atlassian Jira , Trello eller kaiten [16] .

Sprintmål

Det er en kort beskrivelse af sprintens forretningsmæssige mål. Som en artefakt hjælper sprintmålet teamet med at træffe informerede forretningsbeslutninger. Denne artefakt er nødvendig for, at projektteamet kan træffe en uafhængig beslutning, når de skal finde alternative måder at løse et forretningsproblem på.

Produktforøgelse

Et produkttilvækst er en klar-til-brug del af et produkt, der skal implementeres ved afslutningen af ​​en sprint. Sprint Review (Demonstration)-teamet demonstrerer produkttilvæksten for Scrum Master, Product Owner, kunder og andre interessenter [4] for at modtage feedback fra dem og beslutte om den videre retning af produktudviklingen [17] .

Brugerhistorie

Den påkrævede forretningsfunktionalitet, der tilføjes til projektefterslæbet, omtales ofte som brugerhistorien. Ofte er historiens struktur: "Som bruger <type af bruger>, vil jeg tage <handling> for at få <resultat>." Denne struktur er praktisk, fordi den er tydelig for både udviklere og kunder.

Estimering af den indsats, der kræves for at fuldføre en brugerhistorie (sprintopgaver)

I bogen [6] beskrev Sutherland følgende effektive metode, brugt af ham og bekræftet af erfaring, til at vurdere arbejdsintensiteten ved at udføre sprintopgaver i nogle enheder af arbejdsintensitet - mandetimer og lignende.

Opgaveevaluering udføres af projektudviklerne sammen med Scrum Master og Product Owner. Den korrekte metode til at estimere opgaver er at planlægge poker . Det er vist, at en sådan vurdering af arbejdsindsats er meget mere præcis end de vurderinger, som andre mennesker har foretaget.

Hver udvikler skal give sin egen vurdering af opgavens kompleksitet, uafhængig af andre, ved hjælp af tal fra Fibonacci-serien (1, 2, 3, 5, 8, 13, 20, 40, 100). I stedet for tallene 21, 34, 55 bruges tallene 20, 40, 100. Estimater kan noteres på stykker papir, eller der kan bruges specielle kort til dette (se planlægning af poker ) og skal åbnes samtidig . Denne tilrettelæggelse af evalueringen undgår effekten af ​​forankring .

Hvis alle de værdier, der er valgt af udviklerne, falder inden for et interval på højst tre på hinanden følgende Fibonacci-tal, bruges det gennemsnitlige estimat for alle udviklerne i gruppen som den endelige vurdering af opgaven af ​​gruppen. Hvis de valgte score falder uden for dette interval, skal udviklerne med de højeste og laveste værdier forklare årsagerne til deres valg, hvorefter evalueringsrunderne gentages, indtil sættet af estimater falder inden for intervallet af tre på hinanden følgende Fibonacci-tal. Som praksis viser, hvis varianten med et gennemsnit af estimaterne, der ligger i intervallet større end tre på hinanden følgende Fibonacci-tal, bruges til at danne det endelige skøn over opgavens kompleksitet, så viser resultatet sig at være meget mindre nøjagtigt.

Selvom opgaverne i første omgang, og dermed historierne og projektet som helhed, er estimeret i en bestemt enhed for arbejdsinput, bruges disse estimater efterfølgende som relativ arbejdsinput som point (point) til at bestemme hastigheden (produktiviteten) af Scrum-teamet (Velocity). ).

Det er klart, at ovenstående metode til vurdering af arbejdsintensiteten af ​​individuelle opgaver og projektet som helhed kan bruges ikke kun i Scrum, men også i andre metoder til projektimplementering.

Definition af Done (DoD)

Kriterier, der bestemmer klarheden af ​​en vare fra brugerens backlog.

Scrum team hastighed (Velocity)

Det samlede antal point scoret af Scrum-holdet i den foregående sprint. Denne metrik hjælper holdet med at forstå, hvor mange historier det kan fuldføre i en sprint.

Roller i Scrum-processen

Ifølge Scrum-metoden i produktionsprocessen er det muligt at definere roller, opdelt i to grupper: "grise" og "kyllinger". Siden 2011 har metaforerne om "grise" og "kyllinger" været fraværende i Scrum-manualen, da der ikke er særlige ritualer for kyllinger [18] . Scrum-guiden handler om grise. Disse udtryk blev lånt fra en anekdote: [6]

Grisen går langs vejen. Kyllingen kigger på hende og siger: "Lad os åbne en restaurant!" Grisen kigger på kyllingen og svarer: "God idé, hvad vil du kalde det?" Kyllingen tænker og siger: "Hvorfor ikke kalde det bacon og æg?" "Det duer ikke," svarer grisen, "for så skal jeg hellige mig projektet, og du bliver kun delvist involveret."

Grisene skaber produktet, mens kyllingerne er interesserede, men ikke lige så interesserede – for de er ligeglade med, om projektet lykkes eller ej, det vil ikke påvirke dem meget. Der tages hensyn til kyllingernes krav, ønsker, ideer og indflydelse , men de må ikke involveres direkte i Scrum-projektets forløb.

Kerneroller i Scrum-metoden ("Svin")

Grise indgår fuldt ud i projektet og i Scrum-processen. Scrum Master - afholder møder (Scrum-møder), overvåger overholdelse af alle Scrum-principper, løser konflikter og beskytter teamet mod distraktioner, faciliterer møder, er ansvarlig for registrering, lagring og udstedelse af Scrum-inventar. Denne rolle indebærer ikke andet end den korrekte udførelse af Scrum-processen. Scrum Masteren er således den tjenende leder teamet.

Scrum-mesterens vigtigste værktøj er facilitatorens kuffert , som inkluderer kortæsker, firkantede og runde kort, klæbekort, nåle, markører, en brevpapirkniv, gaffatape , Planning Poker-kort, magneter, sakse, stemmepunkter.

Scrum Product Owner - Repræsenterer slutbrugeres og andre interessenters interesser i produktet .

Udviklingsteam (Scrum Development Team) er et tværgående team af projektudviklere, bestående af specialister med forskellige profiler: testere , arkitekter , analytikere , programmører osv. Teamstørrelsen er fra 5 til 9 personer. Teamet er den eneste fuldt involverede deltager i udviklingen og er ansvarlig for resultatet som helhed. Ingen andre end udviklingsteamet, scrum masteren og produktejeren kan blande sig i udviklingsprocessen under spurten. Teamets tværfunktionalitet giver dig mulighed for at planlægge omkostningerne ved at implementere forretningskrav så effektivt som muligt og levere virkelige forretningsapplikationer i fuld overensstemmelse med skiftende kundekrav på kort tid.

Scrum team er i virkeligheden et samlet billede af et team bestående af et udviklingsteam, en scrum master og en product owner. Teamet er helt selvforsynende og er ikke afhængig af eksterne specialister eller kunder.

Yderligere roller (hjælperoller) i Scrum-metoden ("Kyllinger")

Brugerhistorier

Påkrævede felter

Yderligere felter

Nogle gange bruges yderligere felter i projektefterslæbet, primært for at hjælpe produktejeren med at prioritere produktet.

Større Scrum-møder

Følgende møder bruges i Scrum til at opnå regularitet, udviklingskontrol og samtidig minimere antallet af møder, der ikke er foruddefineret i Scrum [20] .

Sprint planlægningsmøde

Afholdes i begyndelsen af ​​hver sprint.

Hele den mængde arbejde, der skal udføres i løbet af spurten, er planlagt på dette møde. Planen skal være resultatet af arbejdet i alle medlemmer af Scrum-teamet.

Mødets varighed bestemmes af sprintens længde, holdets erfaring og andre faktorer, men bør ikke overstige 8 timer. Disse tidslinjer overvåges af ScrumMaster.

Sprint Planlægningsmøde besvarer spørgsmål som:

Det første spørgsmål afgøres i fællesskab. Produktejeren diskuterer de mål, der skal gennemføres for spurten, i betragtning af produktbacklog, tidligere produkttilvækst osv., tilføjer nye User Stories til backloggen og fjerner afsluttede. Udviklingsteamet forsøger at forudsige den funktionalitet, der vil blive udviklet i løbet af spurten. Desuden bør alle medlemmer af Scrum Teamet i fællesskab forstå og evaluere alt arbejdet i den kommende sprint.

For at planlægge en sprint korrekt skal du overveje følgende:

Kun udviklingsteamet arbejder med det andet spørgsmål. Da sprintmålet allerede er defineret, skal udviklingsteamet forstå præcis, hvordan det kan opnås. De beslutter, hvordan de vil implementere den planlagte funktionalitet for at få et nyt færdigt produkttilvækst pr. sprint.

Udviklingsteamet starter typisk med systemdesign og det arbejde, der skal til for at konvertere sprintbacklog til et produkttilvækst. Det arbejde, der er planlagt til de tidlige dage af spurten, er mere detaljeret, ofte opdelt i bidder af en dag eller mindre mod slutningen af ​​mødet. Udviklingsteamet organiserer selvstændigt arbejdet i sprintbacklog, både under sprintplanlægningen og efter behov under sprintet.

Under hensyntagen til udviklingsteamets mening kan Product Owner afklare de udvalgte opgaver-mål fra backlog eller danne en kompromisløsning med dem. Hvis udviklerne beslutter, at der er for meget eller for lidt arbejde, så kan de og produktejeren genoverveje de valgte opgave-mål. Udviklingsteamet kan også invitere andre eksperter til at give teknisk eller faglig rådgivning.

I slutningen af ​​mødet forklarer udviklingsteamet produktejeren og Scrum Master, hvordan de vil arbejde selvstændigt for at nå sprintmålene.

Dagligt Scrum møde

Sådanne møder afholdes af udviklingsteamet, med eventuel deltagelse af produktejeren og Scrummasteren, hver dag på samme sted og på samme tid, og varer ikke mere end 15 minutter. På disse møder planlægger udviklingsteamet arbejdet for dagens arbejdsdag. Disse møder strømliner teamwork og øger produktiviteten ved at gennemgå det arbejde, der er blevet udført siden den forrige Daily Scrum og planlægge det kommende arbejde.

Disse daglige møder er med til at se, hvordan arbejdet skrider frem mod opnåelsen af ​​sprintmålet. De øger sandsynligheden for, at udviklingsteamet når de opstillede mål. Under møderne skal udviklingsteamet forstå, hvordan det skal organisere sig sammen for at nå sprintens mål og implementere den planlagte stigning.

Strukturen af ​​sådanne møder bestemmes af udviklingsteamet, hvis det er nødvendigt og når det er relevant, kan strukturen på møderne ændres, mens hovedfokus bør være på at nå sprintmålet, dog er der obligatoriske regler:

Udviklingsteamet eller teammedlemmerne mødes ofte umiddelbart efter Daily Scrum til mere dybdegående diskussioner eller for at skræddersy eller omplanlægge resten af ​​arbejdet.

Scrum Masteren garanterer disse møder, men udviklingsteamet er ansvarligt for at køre den daglige Scrum. Scrum Master træner også udviklingsteamet til at holde den daglige Scrum inden for 15 minutter og skal sikre, at mødet ikke bliver forstyrret.

Formålet med sådanne møder er at forbedre teamkommunikationen, reducere antallet af yderligere møder, identificere fremtidige risici og vanskeligheder og lette hurtig beslutningstagning.

Dette er det vigtigste middel til at kontrollere udviklingsteamets arbejde.

Sprint anmeldelse

Udført i slutningen af ​​spurten for at kontrollere produktstigningen og justere efterslæbet om nødvendigt. Under gennemgangen af ​​sprintens resultater deltager Scrum Teamet og alle interessenter. Dette uformelle møde og præsentationen af ​​inkrementet er beregnet til at modtage feedback og udvikle samarbejdet.

Sprintoversigten indeholder følgende elementer:

Resultatet er et opdateret efterslæb, der definerer mål for de næste spurter. Efterslæbet kan tilpasses som helhed for at møde nye muligheder.

Retrospektivt møde (Sprint Retrospective)

Formålet med det retrospektive møde er at udvikle forslag til forbedring af processen (procedurer, teknikker, operationer) for projektimplementering. I løbet af en retrospektiv analyse af det forgangne ​​sprint, dannes en plan for forbedring af projektgennemførelsesprocessen til næste sprint. Mødet afholdes efter gennemgang af sprintresultaterne inden planlægning af næste sprint og bør ikke tage mere end 3 timer. Overvåger fremdriften af ​​Scrum Master-mødet.

Hovedformålene med mødet er:

Scrum Master opfordrer teamet til at komme med forslag til forbedring af effektiviteten af ​​udviklingsprocessen. Under hver sprint retrospektiv bør teamet lede efter og foreslå måder og midler til at forbedre arbejdsprocesser.

Ved slutningen af ​​sprint-tilbageblikket bør teamet identificere forbedringsforslag til implementering i næste sprint. Mens sådanne forslag kan implementeres til enhver tid, giver sprintretrospektivet mulighed for at fokusere på at analysere holdets interaktioner og tilpasse det til de aktuelle forhold.

Aflysning af en sprint

En sprint kan aflyses, hvis sprintmålet er forældet. Kun Product Owner har ret til at aflyse en sprint [21] .

Yderligere Scrum-møder

Disse møder er muligvis ikke en del af den overordnede Scrum-arbejdsgang, men de finder bestemt sted i nogle situationer. De bruges, når der er mere end 7-11 udviklere, det vil sige flere end den anbefalede størrelse på Scrum-teamet.

Scrum of Scrums

Hvis holdet er mere end 11 personer, så er holdet større end den anbefalede Scrum-størrelse. Scrum of Scrums [22] er blevet foreslået for at udvide Scrum .

Derefter er holdet opdelt i flere Scrum-hold. Hver har sin egen Scrum Master og Product Owner.

Teams udfører Daily Scrum.

Efter det daglige Scrum møde er der et Scrum of Scrums (SoS [23] ) stævne. Det betyder følgende. Der vælges en repræsentant fra hvert hold. Repræsentanter er fordelt på 5-9 personer. Hvert team får tildelt en Chief Scrum Master [24] og en Chief Scrum Product Owner [25] blandt de Scrum Masters og Product Owners, der er involveret i projektet. Et team af repræsentanter fra forskellige Scrum Teams kaldes Scrum of Scrums Team [26] . I denne sammensætning afholdes et 15-minutters stående stævne af Scrum of Scrums (SoS) eller Meta Scrum eller Scaled Daily Scrum (SDS) [27] .

Ken Schwaber anbefaler at lave Scrum of Scrums hver dag [28] .

Nogle Scrum of Scrums-hold gør dog ikke hver dag, men 2-3 gange om ugen [28] . Dette er i strid med Scrums grundlæggende principper og er et klassisk eksempel på ScrumBut [29] [30] . Dette giver dig ikke mulighed for at drage fuld fordel af Scrum [31] .

Scrum of Scrums giver flere Scrum Teams mulighed for at diskutere arbejde med fokus på fælles områder og gensidig integration. Chief Scrum Master stiller alle medlemmer af Scrum of Scrum-teamet fire spørgsmål [28] , de første tre spørgsmål gentager de daglige Scrum-spørgsmål:

Med Scrum of Scrums-metoden kan du fortsætte med at øge antallet af udviklere. Hvis Scrum of Scrums ikke dækker hele holdet, kan et Scrum of Scrum of Scrums (Scrum-3, SoSoS) [32] , Scrum of Scrum of Scrum of Scrums (Scrum-4, SoSoS [33] ) [34] møde afholdes og så videre [35] . Det seneste MetaScrum hedder Executive Meta Scrum(EMS) [36] eller Executive Action Team(EAT) [37] . Denne tilgang gør det muligt at organisere arbejdet for 4096 mennesker på kun en time [34] .

Rækkefølgen af ​​Scrum of Scrums er den samme som Daily Scrum [26] :

Efterslæb bestilling (Grooming)

Efterslæbet er organiseret, så udviklingsteamet og produktejeren kan [38] :

Andre Scrum-skaleringsteknikker

Ud over den klassiske Scrum of Scrums (SoS)-metode, LeSS [39] [40] [41] [42] (fra 2 til 8 hold), Nexus [43] , RAGE [44] , DAD [45] , APM [46 ] ] [47] , SAFe [48] . Til meget store projekter bruges LeSS Huge [40] (8+ kommandoer) i stedet for LeSS . Kun SoS [49] og Nexus [50] metoderne blev udviklet af Sutherland og Schwaber [40] og undervises i CSM og PSM certificeringskurser.

Scrum træning og certificering

I Scrum spiller en kvalificeret Scrum Master, Scrum Product Owner og Scrum Team en afgørende rolle. Scrum Founders and Certified Trainers (CST®) tilbyder kurser for at certificere Scrum-professionelle. Et obligatorisk grundlag for alle er Scrum Masterens færdigheder. Dernæst kommer specialiseringen i Scrum Master, Scrum Product Owner og Scrum Developer (medlem af Scrum Teamet). De, der består eksamen, får udstedt certifikater: Certified ScrumMaster (CSM®), Certified Scrum Product Owner (CSPO®), Certified Scrum Developer (CSD®), Professional Scrum Master (PSM™), Professional Scrum Product Owner (PSPO™) , Professional Scrum Developer (PSD™). De, der ønsker at forbedre viden og færdigheder i Scrum yderligere, kan efter grundkurserne CSM, CSPO fra Scrum ALLIANCE og bestå eksamen på dem, som har mindst 1 års erfaring i deres Scrum-rolle, tage Advanced Certified Scrum Master (A) -CSM), Advanced Certified Scrum Product Owner, Advanced Certified Scrum Developer [51] . For udviklere er der et separat sæt af kurser relateret til TDD , DevOps osv. [52] . De, der har gennemført CSM, CSPO, CSD, A-CSM, A-CSPO, A-CSD kurser og bestået deres eksamener og har mindst 3 års erfaring i den relevante Scrum-rolle, får lov til at tage CSP®-SM, CSP® -PO-kurser, CSP-D® [53] . Som en del af scrum.org-certificeringen har kurser også flere niveauer: PSM-I, PSM-II, PSM-III, PSPO-I, PSPO-II, PSPO-III [54] .

Yderligere uddannelse er mulig med udstedelse af et Scrum trænercertifikat - Certified Scrum Trainer (CST®) eller Professional Scrum Trainer (PST™).

CST-certificering er åben for personer med en CSP-SM- eller CSP-PO- eller CSP-D-certificering og mindst 5 års erfaring i en relevant Scrum-rolle [55] .

PST-certificeringen anerkender Scrum Master Trainers (PSSMT), Product Owner Trainers (PSPOT) og Development Team Trainers (PSDT) [56] [57] [58] . Train-the-trainer (TTT) optagelse og certificering kræver:

Scrum-certificeringen er gyldig i to år. I løbet af disse to år skal et vist antal Scrum Education Units (SEU®) rekrutteres for at forny certifikatet for de næste to år [59] . Scrum Education Units tildeles for at gennemføre Scrum-kurser, deltage i Global Scrum Gathering℠ [60] og Regional Scrum Gathering℠ [61] , undervise i Scrum og andre aktiviteter, der har til formål at forbedre dine Scrum-færdigheder [59] . Sådan et system viser, at din Scrum viden er up-to-date, og du er altid klar til at anvende den og give den videre til andre. Dette øger værdien af ​​et Scrum-certifikat markant. Scrum Education Units tildeles som følger: 1 times Scrum-træning (deltagelse i indsamling, undervisning, deltagelse i et webinar osv.) er lig med 1 SEU®. Fornyelse af et certifikat kræver:

Hvis der er flere certifikater, beregnes antallet af SEU®, der kræves til fornyelse, ved hjælp af en speciel lommeregner: [62] .

Ikke ligefrem Scrum

Scrumbut

ScrumBut er kun brugen af ​​en del af Scrums principper, samtidig med at man bevarer overbevisningen om at arbejde på Scrum [29] [30] . Dette forhindrer dig ikke kun i at udnytte Scrum [29] fuldt ud , men det forringer også ydeevnen sammenlignet med det fuldstændige fravær af en metodik.

Undersøgelser har vist, at ScrumBut reducerer det årlige overskud fra 400 % til 0-35 % [31] . Samtidig blev produktiviteten af ​​arbejdet ifølge "vandfaldet" taget til 100%, og ifølge Scrum til 400%. En stor undersøgelse af årsagerne til og konsekvenserne af ScrumBut er udført i værket "ScrumBut in Professional Software Development" [63] .

Klassiske eksempler på ScrumBut [29] :

Et stort antal ScrumBut-eksempler findes på Scrum Alliance-webstedet, Scrum ALLIANCE® [64] .

Scrum And

Ud over ScrumBut overveje ScrumAnd [65] . ScrumAnd anses for at bruge Scrum og andre bedste praksisser. Det kan dog være svært at skelne ScrumBut fra ScrumAnd [66] . For eksempel stiller de spørgsmålet: vi har en sprint på 6 måneder, er det ScrumBut eller ScrumAnd? Forfatterne af [66] tilskriver dette utvetydigt ScrumBut og giver en metode til at skelne mellem ScrumBut og ScrumAnd. Det skal huskes, at Scrum-metoden er selvforsynende, og både ScrumBut og ScrumAnd fører til et fald i effektiviteten af ​​forretningsapplikationsudviklingsprocessen. [67] .

Noter

  1. ↑ "scrum" engelsk-russisk oversættelse . lingvo.abbyyonline.com. Hentet: 4. maj 2016.
  2. ↑ Schwaber Ken, Sutherland Jeff. Scrum Guide (november 2020).
  3. ↑ Arkiveret kopi . Hentet 19. oktober 2018. Arkiveret fra originalen 20. oktober 2018.
  4. ↑ 1 2 5 nøgleværktøjer i SCRUM-metoden (27. april 2017). Hentet 21. oktober 2018. Arkiveret fra originalen 2. oktober 2019.
  5. ↑ Agile - en agil tilgang til projektledelse (4. november 2016). Hentet 21. oktober 2018. Arkiveret fra originalen 3. oktober 2019.
  6. ↑ 1 2 3 4 Jeff Sutherland. SCRUM. Revolutionerende projektledelsesmetode = SCRUM. Kunsten at udføre det dobbelte arbejde på den halve tid. - Mann, Ivanov og Ferber, 2016. - 288 s. - ISBN 978-5-00057-722-6 .
  7. ↑ Leslie Hulet Stahl: Wicked Problems, Righteous Solutions: A Catalog of Modern Engineering Paradigms Yourdon Press Computing Series, 1990 (første udgave), ISBN 0-13-590126-X
  8. ↑ OOPSLA 2006 . Dato for adgang: 26. januar 2010. Arkiveret fra originalen 25. juni 2010.
  9. ↑ Schwaber, Ken; Beedle, Mike. Agil softwareudvikling med Scrum  (neopr.) . - Prentice Hall , 2002. - ISBN 0-13-067634-9 .
  10. ↑ Maximini, Dominik. Scrum-kulturen: Introduktion af agile metoder i organisationer. Ledelse for professionelle  // Cham: Springer. - 8. januar 2015. Hentet 25. august 2016 .. - S. 26 . — ISSN 9783319118277 .
  11. ↑ Partogi, Joshua. Certificeret Scrum Master vs Professional Scrum Master // Lean Agile Institute. — 7. juli 2013. Hentet 10. maj 2017.
  12. ↑ Ken Schwaber; Jeff Sutherland. Scrum-guiden. — Scrum.org, Hentet 27. oktober 2017..
  13. ↑ Scrum.org introducerer Scrum med Kanban-kursus, der muliggør større gennemsigtighed blandt udviklingsteams (hentet 2. marts 2018). Hentet 22. maj 2019. Arkiveret fra originalen 18. november 2018.
  14. ↑ Sprint - ryk; kaste; kort løb.
  15. ↑ Ken Schwaber. Agile projektledelse med Scrum . - Microsoft Press, 2004. - 163 s. — ISBN 073561993X .
  16. ↑ Visuel projekt- og teamledelse @ Kaiten . Hentet 15. marts 2021. Arkiveret fra originalen 22. januar 2021.
  17. ↑ Hvad er Scrum - Agile for begyndere . Hentet 20. oktober 2018. Arkiveret fra originalen 21. oktober 2018.
  18. ↑ Høns og grise . Hentet 23. juli 2019. Arkiveret fra originalen 23. januar 2017.
  19. ↑ Acceptkriterier for krav i Agile . Devprom ALM. Hentet 3. april 2016. Arkiveret fra originalen 1. april 2016.
  20. ↑ Scrum Guide | Scrum guider . scrumguides.org. Hentet 3. juni 2020. Arkiveret fra originalen 16. juni 2020.
  21. ↑ Arkiveret kopi . Hentet 15. marts 2021. Arkiveret fra originalen 14. januar 2021.
  22. ↑ (PDF) Scrum of Scrums-løsning til store teams ved hjælp af Scrum-metoden . Hentet 21. oktober 2018. Arkiveret fra originalen 21. oktober 2018.
  23. ↑ Scrum of Scrums (SoS) Definition | innovation . Hentet 21. oktober 2018. Arkiveret fra originalen 21. oktober 2018.
  24. ↑ Rolle som Chief Scrum Master | SCRUMstudy Blog . Hentet 21. oktober 2018. Arkiveret fra originalen 25. oktober 2018.
  25. ↑ Endava . Hentet 21. oktober 2018. Arkiveret fra originalen 21. oktober 2018.
  26. ↑ 1 2 Scrum of Scrums møde - Manifest . Hentet 21. oktober 2018. Arkiveret fra originalen 21. oktober 2018.
  27. ↑ Jeff Sutherland lancerer Scrum@Scale Guide | Henny Portmans blog . Hentet 21. oktober 2018. Arkiveret fra originalen 21. oktober 2018.
  28. ↑ 1 2 3 Scrum Alliance-medlemsindsendte informationsartikler (link utilgængeligt) . Hentet 21. oktober 2018. Arkiveret fra originalen 21. oktober 2018. 
  29. ↑ 1 2 3 4 Hvad er ScrumBut? | Scrum.org . Hentet 21. oktober 2018. Arkiveret fra originalen 21. oktober 2018.
  30. ↑ 1 2 ITKaiZenClub "Scrum, men..." eller typiske problemer ved implementering af Scrum, 8. februar | GØR DU
  31. ↑ 1 2 (PDF) Scrum+:: Er det "ScrumBut" eller "ScrumAnd" . Hentet 21. oktober 2018. Arkiveret fra originalen 21. oktober 2018.
  32. ↑ Scrum-teamet og Scrum of Scrums . Hentet 21. oktober 2018. Arkiveret fra originalen 21. oktober 2018.
  33. ↑ Agile organisation med Scrum@Scale, Vimar Spa et rigtigt eksempel
  34. ↑ 1 2 Agile i militær hardware. Hvordan SAAB Gripen blev verdens mest omkostningseffektive militærfly Arkiveret 20. oktober 2018 på Wayback Machine / Sutherland og Joe Justice , 2017 
  35. ↑ Scaling Agile Series Del 2: Et kig på to af fire populære Agile Scaling Frameworks: SoS og LESS - Gorilla Logic . Hentet 21. oktober 2018. Arkiveret fra originalen 21. oktober 2018.
  36. ↑ The Executive MetaScrum | AgileGenesis . Hentet 15. marts 2021. Arkiveret fra originalen 18. april 2021.
  37. ↑ Executive Action Team - Scrum Inc. Hentet 15. marts 2021. Arkiveret fra originalen 28. februar 2021.
  38. ↑ "Looking for a Backlog Comb Blog of Proactive Business (link unavailable) . Dato for adgang: 8. december 2018. Arkiveret den 27. december 2018. 
  39. ↑ Large-Scale Scrum (LeSS) - Alexey Krivitsky - Agile Coach og Scrum Trainer . Hentet 2. november 2018. Arkiveret fra originalen 4. november 2018.
  40. ↑ 1 2 3 Hvordan skalerer man Agile? | åbne systemer. DBMS | Forlaget "Åbne systemer" . Hentet 2. november 2018. Arkiveret fra originalen 4. november 2018.
  41. ↑ Introduktion til LeSS - Large Scrum (LeSS) . Hentet 4. november 2018. Arkiveret fra originalen 5. november 2018.
  42. ↑ MINDRE - Scrum i skala - ScrumTrek Blog . Hentet 4. november 2018. Arkiveret fra originalen 5. november 2018.
  43. ↑ Nexus-vejledningen | Scrum.org . Hentet 4. november 2018. Arkiveret fra originalen 5. november 2018.
  44. ↑ RAGE | Skalerede agile transformationer | proces | cPrime . Hentet 4. november 2018. Arkiveret fra originalen 4. november 2018.
  45. ↑ Arkiveret kopi (link ikke tilgængeligt) . Hentet 4. november 2018. Arkiveret fra originalen 5. november 2018. 
  46. ↑ Agile projektledelse - hvad og hvorfor | APM . Hentet 4. november 2018. Arkiveret fra originalen 5. november 2018.
  47. ↑ Agil projektledelse med Scrum . Hentet 4. november 2018. Arkiveret fra originalen 5. november 2018.
  48. ↑ Arkiveret kopi (link ikke tilgængeligt) . Hentet 4. november 2018. Arkiveret fra originalen 5. november 2018. 
  49. ↑ Scrum of Scrums | Scrum.org . Hentet 2. november 2018. Arkiveret fra originalen 4. november 2018.
  50. ↑ Nexus-vejledningen | Scrum.org . Hentet 2. november 2018. Arkiveret fra originalen 5. november 2018.
  51. ↑ Advanced Certified ScrumMaster (A-CSM℠) certificering . Hentet 15. marts 2021. Arkiveret fra originalen 17. marts 2021.
  52. ↑ Kursussøgning - Scrum Alliance
  53. ↑ Certificeret Scrum Professional ScrumMaster® (CSP-SM) certificeringskursus . Hentet 15. marts 2021. Arkiveret fra originalen 17. marts 2021.
  54. ↑ Scrum Master-certificering fra Scrums hjem . Hentet 15. marts 2021. Arkiveret fra originalen 3. marts 2021.
  55. ↑ Ansøgningsproces for Certified Scrum Trainer (CST) . Hentet 19. oktober 2018. Arkiveret fra originalen 20. oktober 2018.
  56. ↑ PSD Trainer udvælgelsesproces og ansøgning | Scrum.org . Hentet 19. oktober 2018. Arkiveret fra originalen 20. oktober 2018.
  57. ↑ PSPO-trænerudvælgelsesproces og ansøgning | Scrum.org . Hentet 19. oktober 2018. Arkiveret fra originalen 20. oktober 2018.
  58. ↑ PSM Trainer udvælgelsesproces og ansøgning | Scrum.org . Hentet 19. oktober 2018. Arkiveret fra originalen 20. oktober 2018.
  59. ↑ 1 2 Scrum Education Units® (SEU®) Credits for Training . Hentet 15. marts 2021. Arkiveret fra originalen 20. april 2021.
  60. ↑ Global Scrum Gathering-begivenhedsinformation og sponsorering . Hentet 15. marts 2021. Arkiveret fra originalen 4. marts 2021.
  61. ↑ Scrum Alliance regionale Scrum-møder . Hentet 15. marts 2021. Arkiveret fra originalen 28. januar 2021.
  62. ↑ Agile og Scrum træning og certificering | Scrum Alliance . Hentet 15. marts 2021. Arkiveret fra originalen 21. april 2021.
  63. ↑ Arkiveret kopi . Hentet 21. oktober 2018. Arkiveret fra originalen 21. oktober 2018.
  64. ↑ Scrum Alliance-medlemsindsendte informationsartikler (link ikke tilgængeligt) . Hentet 21. oktober 2018. Arkiveret fra originalen 21. oktober 2018. 
  65. ↑ "ScrumAnd"-holdningen (kræver omtanke og disciplin) | Scrum.org . Hentet 15. marts 2021. Arkiveret fra originalen 14. april 2021.
  66. ↑ 1 2 (PDF) Scrum+:: Er det “ScrumBut” eller “ScrumAnd” . Hentet 21. oktober 2018. Arkiveret fra originalen 21. oktober 2018.
  67. ↑ https://www.researchgate.net/publication/254048455_Scrum_Is_it_ScrumBut_or_ScrumAnd

Se også

Links

Litteratur

  Gå til Wikidata-elementet  I bibliografiske kataloger