Klunga

Den aktuella versionen av sidan har ännu inte granskats av erfarna bidragsgivare och kan skilja sig väsentligt från versionen som granskades den 2 september 2022; kontroller kräver 27 redigeringar .
Klunga
Officiell sida scrum.org
 Mediafiler på Wikimedia Commons

Scrum ( /skrʌm/ [1] ; scrum "  scrum") är ett lätt ramverk som hjälper människor, team och organisationer att skapa värde genom adaptiva lösningar på komplexa problem [2] .

Scrum kan användas inte bara inom mjukvaruutveckling utan även inom andra tillverkningsindustrier [3] .

Förutom att hantera mjukvaruutvecklingsprojekt kan Scrum även användas av mjukvarusupportteam som ett tillvägagångssätt för hantering och underhåll av mjukvaruutveckling .

En skillnad bör göras mellan Scrum [4] och Agile [5] .

Historik

De primära källorna till Scrum-metoden var: Toyotas produktionssystem och OODA-cykeln (OODA-slingan, eller OODA-slingan eller Boyd-slingan) för konceptet att använda militärflyg, som inkluderar fyra komponenter: observera (“observera”) , orientera (”orientera”), besluta (”bestämma”), agera (”agera”). [6]

Själva tillvägagångssättet beskrevs först av Hirotaka Takeuchi och Ikujiro Nonaka i The New Product Development Game (Harvard Business Review, januari-februari 1986). De noterade att projekt som drivs av små multidisciplinära team tenderar att systematiskt ge bättre resultat, och de förklarade detta som "rugbymetoden".

1991 hänvisade DeGrace och Stahl, i sin bok Unholy Problems, Righteous Solutions, [7] till detta tillvägagångssätt som scrum , en sportterm myntad i en artikel av Takeuchi och Nonaka. Ken Schwaber använde metoden som förde Scrum till hans företag början av 1990 -talet. Scrum-metoden presenterades först för allmänheten dokumenterad, tydligt definierad och beskriven gemensamt av Schwaber och Jeff Sutherland [6] vid OOPSLA'95 [8] i Austin . K. Schwaber och D. Sutherland arbetade tillsammans under de kommande åren för att bearbeta och beskriva all deras erfarenhet och bästa praxis för branschen till en helhet, i den metod som idag kallas Scrum.

Schwaber gick samman med Mike Beadle 2001 för att beskriva metoden i detalj i Agile Software Development with Scrum [9] .

2002 grundade Schwaber Scrum Alliance [10] tillsammans med andra och skapade en serie certifierade Scrum-ackrediteringar. Schwaber lämnade Scrum Alliance i slutet av 2009 och grundade Scrum.org Archived December 10, 2019 at the Wayback Machine , som kurerar den professionella Scrum-ackrediteringsserien [11] .

Sedan 2009 har ett offentligt dokument kallat The Scrum Guide [12] officiellt definierat Scrum. Den har reviderats över 5 gånger. Under 2018 publicerade Schwaber och Scrum.org-communityt, tillsammans med ledare från Kanban-communityt, Kanban-guiden för Scrum-team [13] .

Definitioner

Scrum

Scrum (eng. "scrum" - en term från rugby, betecknar starttillståndet för lagen innan de kastar in bollen) - den minsta nödvändiga uppsättningen av händelser, artefakter, roller som Scrum-utvecklingsprocessen är uppbyggd på, vilket tillåter fasta korta perioder tid, kallade sprints ( sprints ), för att förse slutanvändaren med en fungerande produkt med nya affärsmöjligheter för vilka högsta prioritet är fastställd. Metodiken är baserad på idéerna som uttrycks i artikeln av Taekuchi och Nonaka " The New New Product Development Game ", såväl som lagarbete, liknande hur ett lag arbetar tillsammans för att uppnå ett gemensamt mål inom rugby. Möjligheter till genomförande i nästa sprint bestäms av teamet i början av sprinten på Sprintplaneringsmötet . För att uppskatta den kommande mängden arbete i sprinten används oftast relativa uppskattningar och praxis att planera poker (Planning Poker).

I slutet av sprinten träffas Scrum-teamet på ett sprintrecensionsmöte (Sprint Review - det gamla namnet på Demonstration) med kunden och presenterar honom för ett företagsprodukttillskott (en produktversion med en komplett uppsättning funktioner som kan redan ges till kunden och användaren för användning), vilket hon lyckades göra i en sprint. Målet med Sprint Review är att få feedback från kunden för att förstå vad som behöver betonas i framtiden, och vad nästa steg av affärsprodukten bör vara.

En strikt fast kort sprinttid (från 1 till 4 veckor) minskar riskerna och gör det möjligt att snabbt få feedback från kunden för att anpassa produktvisionen.

Sprint

Sprint [14]  är en tidsperiod som är tillräcklig för att slutföra en planerad uppsättning Scrum-operationer, vars syfte är att skapa en ökning av en affärsprodukt. Styvt fixerad i tiden. Längden på en sprint är från 1 till 4 veckor. Ju kortare spurten är, desto mer flexibel är utvecklingsprocessen, releaserna kommer ut oftare, feedbacken från kunden kommer snabbare, mindre tid går åt till att jobba åt fel håll, men mycket tid går åt till sprintplaneringsmöten, retrospektiv. . Å andra sidan, med längre sprints, minskar Scrum-teamet kostnaderna för möten, produktdemonstrationer etc. Olika team väljer sprintens längd efter detaljerna i deras arbete, tvärfunktionella team och krav, ofta genom prov och fel. För att uppskatta mängden arbete i en sprint kan du använda en preliminär uppskattning, mätt i storypoäng. En preliminär uppskattning av sprintens längd registreras i projektbacklog ( produktbacklog ; se nedan).

Artefakter av Scrum

Burndown diagram

Ett diagram som visar hur mycket arbete som gjorts och hur mycket arbete som återstår i förhållande till tiden för att utveckla ett projekt kallas ett burndown-diagram.

Dessa diagram måste uppdateras dagligen för att visa framsteg och kostnader i realtid i arbetet med sprinten och projektet, tillgängliga för alla medlemmar i Scrum-teamet: Scrum Master och Product Owner.

Sprint burndown diagrammet visar hur många uppgifter som har slutförts och hur mycket som återstår att göra i den aktuella sprinten.

Projekteftersläpning

Projektönskeloggen (projektbacklog) innehåller en lista över funktionalitetskrav, ordnade efter vikt, och följaktligen implementeringsordningen. Objekten i denna logg kallas user stories ( user stories ) eller backlog items ( backlog items ). Projektbackloggen är öppen för redigering av alla deltagare i Scrum-processen. Den person som ansvarar för att upprätthålla projektbackloggen är ägaren av Scrum-produkten.

Sprint backlog

Sprint Önskelista (Sprint Backlog) - innehåller den funktionalitet som valts av produktägaren från projektbackloggen. Alla funktioner är uppdelade i uppgifter, som var och en utvärderas av Scrum-teamet. På Sprint Planning Meeting används planeringsmetoden för poker av teamet för att uppskatta hur mycket arbete som behöver göras för att slutföra spurten [15] .

Scrum board

Scrum Board är ett verktyg för att öppet visa upp statusen för det pågående arbetet i Scrum-teamet. Scrum board består av tre kolumner: "att göra" ( att göra ), "pågår" ( pågår ), "klar" ( klar ).

Scrum Board innehåller hela omfattningen av Sprint Backlog som teamet har valt ut i Sprint Planning för implementering i den aktuella sprinten. Vanligtvis placeras visitkort på tavlan uppifrån och ned i fallande prioritetsordning (överst - viktigast, botten - minst viktigt). Det är en god praxis att dekomponera affärsuppgifter i specifikt arbete (tekniskt, organisatoriskt och annat) som teamet behöver utföra för att genomföra affärsuppgiften.

Affärsuppgifter och specifika arbetskort flyttas över hela linjen från kolumn till kolumn i enlighet med hur teamet tar dem för utförande (pågår) och slutför (klar). För att ge insyn i framstegen i teamets arbete visas "arbete minskar" per dag på Burndown-diagrammet.

Oftast använder team i början av arbetet tavlor med blädderblock ritade på ark, medan namnen på arbetet skrivs på klistermärken och limmas på tavlan. Allt eftersom mötet fortskrider flyttar teamet fysiskt klisterlappar från kolumn till kolumn.

Elektroniska kort används också ofta, med liknande mekanismer implementerade i dem. Till exempel Atlassian Jira , Trello eller kaiten [16] .

Sprintmål

Det är en kort beskrivning av affärsmålet med sprinten. Som en artefakt hjälper sprintmålet laget att fatta välgrundade affärsbeslut. Denna artefakt är nödvändig för att projektgruppen ska kunna fatta ett oberoende beslut när de hittar alternativa sätt att lösa ett affärsproblem.

Produktökning

Ett produktinkrement är en färdig att använda del av en produkt som måste implementeras i slutet av en sprint. Sprint Review (demonstration)-teamet demonstrerar produktökningen för Scrum Master, produktägare, kunder och andra intressenter [4] för att få feedback från dem och besluta om den vidare inriktningen av produktutvecklingen [17] .

Användarberättelse

Den nödvändiga affärsfunktionaliteten som läggs till projektbackloggen kallas ofta för användarberättelsen. Ofta är berättelsens struktur: "Som användare <typ av användare> vill jag ta <åtgärd> för att få <resultat>." Denna struktur är bekväm eftersom den är tydlig för både utvecklare och kunder.

Uppskattning av ansträngningen som krävs för att slutföra en användarberättelse (sprintuppgifter)

I boken [6] beskrev Sutherland följande effektiva metod, använd av honom och bekräftad av erfarenhet, för att bedöma arbetsintensiteten för att utföra sprintuppgifter i vissa enheter av arbetsintensitet - mantimmar och liknande.

Uppgiftsutvärdering utförs av projektutvecklarna tillsammans med Scrum Master och Product Owner. Den korrekta metoden för att uppskatta uppgifter är att planera poker . Det visar sig att en sådan bedömning av arbetsinsatsen är mycket mer korrekt än de bedömningar som andra människor gör.

Varje utvecklare måste ge sin egen bedömning av uppgiftens komplexitet, oberoende av andra, med hjälp av siffror från Fibonacci-serien (1, 2, 3, 5, 8, 13, 20, 40, 100). Istället för siffrorna 21, 34, 55 används siffrorna 20, 40, 100. Uppskattningar kan antecknas på papper, eller specialkort kan användas för detta (se planering av poker ) och måste öppnas samtidigt . Denna organisation av utvärderingen undviker effekten av förankring .

Om alla värden som valts av utvecklarna faller inom ett intervall på högst tre på varandra följande Fibonacci-tal, används den genomsnittliga uppskattningen av alla utvecklare i gruppen som den slutliga bedömningen av uppgiften av gruppen. Om de valda poängen faller utanför detta intervall, måste utvecklarna med de högsta och lägsta värdena förklara skälen till sitt val, varefter utvärderingsomgångarna upprepas tills uppsättningen av uppskattningar faller inom intervallet av tre på varandra följande Fibonacci-tal. Som praxis visar, om varianten med medelvärdesberäkning av uppskattningarna som ligger i intervallet större än tre på varandra följande Fibonacci-tal används för att bilda den slutliga uppskattningen av uppgiftens komplexitet, så visar sig resultatet vara mycket mindre exakt.

Även om uppgifterna, och följaktligen, berättelserna och projektet som helhet, initialt uppskattas i en viss enhet för arbetsinsats, används dessa uppskattningar senare som relativ arbetsinsats som poäng (poäng) för att bestämma hastigheten (produktiviteten) för Scrum-teamet (Velocity). ).

Uppenbarligen kan ovanstående metodik för att bedöma arbetsintensiteten för enskilda uppgifter och projektet som helhet användas inte bara i Scrum, utan även i andra metoder för projektgenomförande.

Definition av Done (DoD)

Kriterier som bestämmer beredskapen för en artikel från användarens eftersläpning.

Scrum teamhastighet (Velocity)

Det totala antalet poäng som Scrum-teamet gjorde i föregående sprint. Detta mått hjälper teamet att förstå hur många berättelser det kan slutföra i en sprint.

Roller i Scrum-processen

Enligt Scrum-metodiken i produktionsprocessen är det möjligt att definiera roller, uppdelade i två grupper: "grisar" och "kycklingar". Sedan 2011 har metaforerna "grisar" och "kycklingar" saknats i Scrum-manualen, eftersom det inte finns några speciella ritualer för kycklingar [18] . Scrum-guiden handlar om grisar. Dessa termer är lånade från en anekdot: [6]

Grisen går längs vägen. Kycklingen tittar på henne och säger: "Låt oss öppna en restaurang!" Grisen tittar på kycklingen och svarar: "Bra idé, vad vill du kalla den?" Kycklingen tänker och säger: "Varför inte kalla det Bacon och ägg?" "Det går inte", svarar grisen, "för då måste jag ägna mig helt åt projektet, och du kommer bara vara delvis involverad."

Grisarna skapar produkten, medan kycklingarna är intresserade, men inte lika intresserade – eftersom de inte bryr sig om om projektet är lyckat eller inte kommer det inte att påverka dem särskilt mycket. Kycklingarnas krav, önskemål, idéer och inflytande beaktas, men de får inte vara direkt involverade i Scrum-projektets gång.

Kärnroller i Scrum-metoden ("Pigs")

Grisar ingår fullt ut i projektet och i Scrum-processen. Scrum Master - genomför möten (Scrum-möten), övervakar efterlevnaden av alla Scrum-principer, löser konflikter och skyddar teamet från distraktioner, underlättar möten, ansvarar för att registrera, lagra och utfärda Scrum-inventering. Denna roll innebär inget annat än att Scrum-processen genomförs korrekt. Således är Scrum Master den tjänande ledaren laget.

Huvudverktyget för Scrum-mästaren är handledarens resväska , som inkluderar kortlådor , fyrkantiga och runda kort, klibbiga kort, nålar, markörer, en papperskniv, tejp , Planning Poker-kort, magneter, saxar, röstningspunkter.

Scrum Product Owner - Representerar slutanvändarnas och andra intressenters intressen i produkten .

Utvecklingsteam (Scrum Development Team) är ett tvärfunktionellt team av projektutvecklare, bestående av specialister med olika profiler: testare , arkitekter , analytiker , programmerare , etc. Teamstorleken är från 5 till 9 personer. Teamet är den enda helt involverade deltagaren i utvecklingen och ansvarar för resultatet som helhet. Ingen annan än utvecklingsteamet, scrummastern och produktägaren kan störa utvecklingsprocessen under sprinten. Teamets tvärfunktionalitet gör att du kan planera kostnaderna för att implementera affärskrav så effektivt som möjligt och leverera verkliga affärsapplikationer i full överensstämmelse med förändrade kundkrav på kort tid.

Scrum team är i själva verket en samlad bild av ett team som består av ett utvecklingsteam, en scrum master och en produktägare. Teamet är helt självförsörjande och är inte beroende av externa specialister eller kunder.

Ytterligare roller (biroller) i Scrum-metoden ("Kycklingar")

Användarberättelser

Obligatoriska fält

Ytterligare fält

Ibland används även ytterligare fält i projektbackloggen, främst för att hjälpa produktägaren att prioritera produkten.

Stora Scrum-möten

Följande möten används i Scrum för att uppnå regelbundenhet, utvecklingskontroll, och samtidigt minimera antalet möten som inte är fördefinierade i Scrum [20] .

Sprintplaneringsmöte

Hålls i början av varje sprint.

Hela mängden arbete som måste slutföras under sprinten planeras på detta möte. Planen bör vara resultatet av arbetet av alla medlemmar i Scrum-teamet.

Längden på mötet bestäms av sprintens längd, lagets erfarenhet och andra faktorer, men bör inte överstiga 8 timmar. Dessa tidslinjer övervakas av ScrumMaster.

Sprint Planning Meeting svarar på frågor som:

Den första frågan avgörs gemensamt. Produktägaren diskuterar målen som ska slutföras för sprinten, med tanke på produktstocken, tidigare produktökningar, etc., lägger till nya User Stories till eftersläpningen och tar bort slutförda sådana. Utvecklingsteamet försöker förutse vilken funktionalitet som kommer att utvecklas under sprinten. Alla medlemmar i Scrum-teamet bör också gemensamt förstå och utvärdera allt arbete under den kommande sprinten.

För att planera en sprint korrekt, överväg följande:

Endast utvecklingsteamet arbetar med den andra frågan. Eftersom sprintmålet redan är definierat måste utvecklingsteamet förstå exakt hur det kan uppnås. De bestämmer hur de ska implementera den planerade funktionaliteten för att få en ny färdig produktökning per sprint.

Utvecklingsteamet börjar vanligtvis med systemdesign och det arbete som krävs för att omvandla sprintbackloggen till ett produktökning. Arbetet som planeras för de första dagarna av sprinten är mer detaljerat, ofta uppdelat i bitar på en dag eller mindre mot slutet av mötet. Utvecklingsteamet organiserar självständigt arbetet i sprintbackloggen, både under sprintplaneringen och efter behov under sprint.

Med hänsyn till utvecklingsteamets åsikt kan produktägaren klargöra de utvalda uppgifterna-målen från backloggen eller bilda en kompromisslösning med dem. Om utvecklarna bestämmer sig för att det är för mycket eller för lite arbete, då kan de och produktägaren ompröva de valda uppgifternas mål. Utvecklingsteamet kan också bjuda in andra experter för att ge tekniska eller ämnesmässiga råd.

I slutet av mötet förklarar utvecklingsteamet för produktägaren och Scrum Master hur de ska arbeta självständigt för att nå sprintmålen.

Dagligt Scrum-möte

Sådana möten hålls av utvecklingsteamet, med eventuellt deltagande av produktägaren och Scrummastern, varje dag på samma plats och vid samma tid, som inte varar mer än 15 minuter. Vid dessa möten planerar utvecklingsteamet arbetet för dagens arbetsdag. Dessa möten effektiviserar teamarbetet och ökar produktiviteten genom att se över det arbete som har gjorts sedan föregående Daily Scrum och planera för det kommande arbetet.

Dessa dagliga möten hjälper till att se hur arbetet fortskrider mot att nå sprintmålet. De ökar sannolikheten för att utvecklingsteamet når de uppsatta målen. Under mötena ska utvecklingsteamet förstå hur det ska organisera sig tillsammans för att uppnå sprintens mål och genomföra den planerade ökningen.

Strukturen på sådana möten bestäms av utvecklingsteamet, vid behov och när så är lämpligt kan strukturen på mötena ändras, medan huvudfokus bör ligga på att nå sprintmålet, dock finns det obligatoriska regler:

Utvecklingsteamet eller teammedlemmarna träffas ofta direkt efter Daily Scrum för mer djupgående diskussioner eller för att skräddarsy eller omplanera resten av arbetet.

Scrum Master garanterar dessa möten, men utvecklingsteamet ansvarar för att driva det dagliga Scrum. Scrum Master utbildar också utvecklingsteamet att hålla Daily Scrum inom 15 minuter och måste se till att mötet inte störs.

Syftet med sådana möten är att förbättra teamkommunikationen, minska antalet ytterligare möten, identifiera framtida risker och svårigheter och underlätta snabbt beslutsfattande.

Detta är det viktigaste sättet att kontrollera utvecklingsteamets arbete.

Sprint recension

Genomfördes i slutet av sprinten för att kontrollera produktökningen och justera eftersläpningen vid behov. Under granskningen av sprintens resultat deltar Scrum Team och alla intressenter. Detta informella möte och presentation av inkrementet är avsett att få feedback och utveckla samarbetet.

Sprintöversikten innehåller följande delar:

Resultatet är en uppdaterad eftersläpning som definierar målen för de kommande spurterna. Eftersläpningen kan anpassas som helhet för att möta nya möjligheter.

Retrospektivt möte (Sprint Retrospective)

Syftet med det retrospektiva mötet är att ta fram förslag för att förbättra processen (förfaranden, tekniker, operationer) för projektgenomförande. I samband med en retrospektiv analys av den gångna sprinten, bildas en plan för att förbättra processen för projektgenomförande inför nästa sprint. Mötet hålls efter genomgång av sprintresultaten innan nästa sprint planeras och bör inte ta mer än 3 timmar. Övervakar utvecklingen av Scrum Master-mötet.

Huvudmålen med mötet är:

Scrum Master uppmuntrar teamet att ge förslag för att förbättra effektiviteten i utvecklingsprocessen. Under varje sprintretrospektiv bör teamet leta efter och föreslå sätt och medel för att förbättra arbetsprocesserna.

I slutet av sprinttillbakablicken bör teamet identifiera förbättringsförslag för implementering i nästa sprint. Även om sådana förslag kan implementeras när som helst, ger sprintretrospektivet en möjlighet att fokusera på att analysera teamets interaktioner och anpassa det till de rådande förhållandena.

Avbrytande av en sprint

En sprint kan ställas in om sprintmålet är inaktuellt. Endast Produktägaren har rätt att avbryta en sprint [21] .

Ytterligare Scrum-möten

Dessa möten kanske inte är en del av det övergripande Scrum-arbetsflödet, men de äger verkligen rum i vissa situationer. De används när det finns fler än 7-11 utvecklare, det vill säga fler än den rekommenderade storleken på Scrum-teamet.

Scrum of Scrums

Om teamet är fler än 11 ​​personer är teamet större än den rekommenderade Scrum-storleken. Scrum of Scrums [22] har föreslagits för att utöka Scrum .

Sedan är teamet uppdelat i flera Scrum-team. Var och en har sin egen Scrum Master och produktägare.

Lag genomför Daily Scrum.

Efter det dagliga Scrum-mötet är det ett Scrum of Scrums (SoS [23] ) rally. Det betyder följande. En representant väljs från varje lag. Representanter är uppdelade på 5-9 personer. Varje team tilldelas en Chief Scrum Master [24] och en Chief Scrum Product Owner [25] bland Scrum Masters och produktägare som är involverade i projektet. Ett team av representanter från olika Scrum Teams kallas Scrum of Scrums Team [26] . I denna komposition hålls ett 15-minuters stående rally av Scrum of Scrums (SoS) eller Meta Scrum eller Scaled Daily Scrum (SDS) [27] .

Ken Schwaber rekommenderar att du gör Scrum of Scrums varje dag [28] .

Vissa Scrum of Scrums-lag gör dock inte varje dag, utan 2-3 gånger i veckan [28] . Detta bryter mot Scrums grundläggande principer och är ett klassiskt exempel på ScrumBut [29] [30] . Detta tillåter dig inte att dra full nytta av Scrum [31] .

Scrum of Scrums låter flera Scrum-team diskutera arbete, med fokus på gemensamma områden och ömsesidig integration. Chief Scrum Master ställer fyra frågor till alla medlemmar i Scrum of Scrum-teamet [28] , de tre första frågorna upprepar de dagliga Scrum-frågorna:

Med Scrum of Scrums metodik kan du fortsätta att öka antalet utvecklare. Om Scrum of Scrums inte täcker hela laget kan ett Scrum of Scrum of Scrums (Scrum-3, SoSoS) [32] , Scrum of Scrum of Scrum of Scrums (Scrum-4, SoSoS [33] ) [34] möte hållas och så vidare [35] . Den senaste MetaScrum kallas Executive Meta Scrum(EMS) [36] eller Executive Action Team(EAT) [37] . Detta tillvägagångssätt gör det möjligt att organisera arbetet för 4096 personer på bara en timme [34] .

Ordningen för Scrum of Scrums är densamma som Daily Scrum [26] :

Eftersläpning (Grooming)

Eftersläpningen är organiserad så att utvecklingsteamet och produktägaren kan [38] :

Andra Scrum-skalningstekniker

Förutom den klassiska Scrum of Scrums (SoS)-metoden, LeSS [39] [40] [41] [42] (från 2 till 8 lag), Nexus [43] , RAGE [44] , DAD [45] , APM [46 ] ] [47] , SAFe [48] . För mycket stora projekt används LeSS Huge [40] (8+ kommandon) istället för LeSS . Endast SoS [49] och Nexus [50] metoderna utvecklades av Sutherland och Schwaber [40] och lärs ut i CSM och PSM certifieringskurser.

Scrum utbildning och certifiering

I Scrum spelar en kvalificerad Scrum Master, Scrum Product Owner och Scrum Team en avgörande roll. Scrum Founders and Certified Trainers (CST®) tillhandahåller utbildningar för att certifiera Scrum-proffs. En obligatorisk grund för alla är kompetensen hos Scrum Master. Därefter kommer specialiseringen i Scrum Master, Scrum Product Owner och Scrum Developer (medlem i Scrum Team). De som klarar provet får certifikat: Certified ScrumMaster (CSM®), Certified Scrum Product Owner (CSPO®), Certified Scrum Developer (CSD®), Professional Scrum Master (PSM™), Professional Scrum Product Owner (PSPO™) , Professionell Scrum-utvecklare (PSD™). De som vill ytterligare förbättra kunskaperna och färdigheterna i Scrum kan efter grundkurserna CSM, CSPO från Scrum ALLIANCE och klara provet på dem, som har minst 1 års erfarenhet av sin Scrum-roll, ta Advanced Certified Scrum Master (A) -CSM), Advanced Certified Scrum Product Owner, Advanced Certified Scrum Developer [51] . För utvecklare finns det en separat uppsättning kurser relaterade till TDD , DevOps , etc. [52] . De som har genomfört CSM, CSPO, CSD, A-CSM, A-CSPO, A-CSD-kurser och klarat sina tentor och har minst 3 års erfarenhet i den relevanta Scrum-rollen får ta CSP®-SM, CSP® -PO-kurser, CSP-D® [53] . Som en del av scrum.org-certifieringen har kurser även flera nivåer: PSM-I, PSM-II, PSM-III, PSPO-I, PSPO-II, PSPO-III [54] .

Vidareutbildning är möjlig med utfärdande av ett Scrum-tränarcertifikat - Certified Scrum Trainer (CST®) eller Professional Scrum Trainer (PST™).

CST-certifiering är öppen för personer med en CSP-SM- eller CSP-PO- eller CSP-D-certifiering och minst 5 års erfarenhet av en relevant Scrum-roll [55] .

PST-certifieringen erkänner Scrum Master Trainers (PSSMT), Product Owner Trainers (PSPOT) och Development Team Trainers (PSDT) [56] [57] [58] . Tillträde och certifiering till Train-the-trainer (TTT) kräver:

Scrum-certifieringen är giltig i två år. Under dessa två år måste ett visst antal Scrum Education Units (SEU®) rekryteras för att förnya certifikatet för de kommande två åren [59] . Scrum Education Units tilldelas för att ha genomfört Scrum-kurser, deltagit i Global Scrum Gathering℠ [60] och Regional Scrum Gathering℠ [61] , undervisning i Scrum och andra aktiviteter som syftar till att förbättra dina Scrum-färdigheter [59] . Ett sådant system visar att din Scrum-kunskap är uppdaterad och du är alltid redo att tillämpa den och förmedla den till andra. Detta ökar värdet av ett Scrum-certifikat avsevärt. Scrum Education Units delas ut enligt följande: 1 timmes Scrum-träning (deltagande i insamling, undervisning, deltagande i ett webbseminarium, etc.) är lika med 1 SEU®. För att förnya ett certifikat krävs:

Om det finns flera certifikat beräknas antalet SEU® som krävs för förnyelse med hjälp av en speciell kalkylator: [62] .

Inte precis Scrum

Scrumbut

ScrumBut är användningen av endast en del av principerna för Scrum, samtidigt som man behåller övertygelsen om att arbeta med Scrum [29] [30] . Detta hindrar dig inte bara från att dra full nytta av Scrum [29] , utan det försämrar också prestandan jämfört med den totala avsaknaden av en metodik.

Studier har visat att ScrumBut minskar årliga vinster från 400 % till 0-35 % [31] . Samtidigt togs produktiviteten i arbetet enligt "vattenfallet" till 100% och enligt Scrum till 400%. En stor studie av orsaker och konsekvenser av ScrumBut genomförs i arbetet "ScrumBut in Professional Software Development" [63] .

Klassiska exempel på ScrumBut [29] :

Ett stort antal ScrumBut-exempel finns på Scrum Alliances webbplats, Scrum ALLIANCE® [64] .

Scrum And

Förutom ScrumBut överväg ScrumAnd [65] . ScrumAnd anses använda Scrum och andra bästa praxis. Det kan dock vara svårt att skilja ScrumBut från ScrumAnd [66] . Till exempel ställer de frågan: vi har en sprint på 6 månader, är det ScrumBut eller ScrumAnd? Författarna till [66] tillskriver detta otvetydigt ScrumBut och tillhandahåller en metod för att skilja mellan ScrumBut och ScrumAnd. Man bör komma ihåg att Scrum-metoden är självförsörjande, och både ScrumBut och ScrumAnd leder till en minskning av effektiviteten i utvecklingsprocessen för affärsapplikationer. [67] .

Anteckningar

  1. ↑ "scrum" engelsk-ryska översättning . lingvo.abbyyonline.com. Hämtad: 4 maj 2016.
  2. ↑ Schwaber Ken, Sutherland Jeff. Scrum Guide (november 2020).
  3. ↑ Arkiverad kopia . Hämtad 19 oktober 2018. Arkiverad från originalet 20 oktober 2018.
  4. ↑ 1 2 5 nyckelverktyg för SCRUM-metoden (27 april 2017). Hämtad 21 oktober 2018. Arkiverad från originalet 2 oktober 2019.
  5. ↑ Agilt - ett agilt förhållningssätt till projektledning (4 november 2016). Hämtad 21 oktober 2018. Arkiverad från originalet 3 oktober 2019.
  6. ↑ 1 2 3 4 Jeff Sutherland. KLUNGA. Revolutionerande projektledningsmetod = SCRUM. Konsten att göra dubbelt så mycket på halva tiden. - Mann, Ivanov och 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örsta upplagan), ISBN 0-13-590126-X
  8. ↑ OOPSLA 2006 . Datum för åtkomst: 26 januari 2010. Arkiverad från originalet den 25 juni 2010.
  9. ↑ Schwaber, Ken; Beedle, Mike. Agil mjukvaruutveckling med Scrum  (neopr.) . - Prentice Hall , 2002. - ISBN 0-13-067634-9 .
  10. ↑ Maximini, Dominic. Scrum-kulturen: Introduktion av agila metoder i organisationer. Management for Professionals  // Cham: Springer. - 8 januari 2015. Hämtad 25 augusti 2016 .. - S. 26 . — ISSN 9783319118277 .
  11. ↑ Partogi, Joshua. Certifierad Scrum Master vs Professional Scrum Master // Lean Agile Institute. — 7 juli 2013. Hämtad 10 maj 2017.
  12. ↑ Ken Schwaber; Jeff Sutherland. Scrum-guiden. — Scrum.org, Hämtad 27 oktober 2017..
  13. ↑ Scrum.org introducerar kursen Scrum med Kanban, vilket möjliggör större transparens bland utvecklingsteam (hämtad 2 mars 2018). Hämtad 22 maj 2019. Arkiverad från originalet 18 november 2018.
  14. ↑ Sprint - ryck; kasta; kortsiktigt.
  15. ↑ Ken Schwaber. Agil projektledning med Scrum . - Microsoft Press, 2004. - 163 sid. — ISBN 073561993X .
  16. ↑ Visuell projekt- och teamledning @ Kaiten . Hämtad 15 mars 2021. Arkiverad från originalet 22 januari 2021.
  17. ↑ Vad är Scrum - Agile för nybörjare . Hämtad 20 oktober 2018. Arkiverad från originalet 21 oktober 2018.
  18. ↑ Höns och grisar . Hämtad 23 juli 2019. Arkiverad från originalet 23 januari 2017.
  19. ↑ Godkännandekriterier för krav i Agile . Devprom ALM. Hämtad 3 april 2016. Arkiverad från originalet 1 april 2016.
  20. ↑ Scrum Guide | Scrum guider . scrumguides.org. Hämtad 3 juni 2020. Arkiverad från originalet 16 juni 2020.
  21. ↑ Arkiverad kopia . Hämtad 15 mars 2021. Arkiverad från originalet 14 januari 2021.
  22. ↑ (PDF) Scrum of Scrums-lösning för stora team som använder Scrum-metodik . Hämtad 21 oktober 2018. Arkiverad från originalet 21 oktober 2018.
  23. ↑ Scrum of Scrums (SoS) Definition | innovation . Hämtad 21 oktober 2018. Arkiverad från originalet 21 oktober 2018.
  24. ↑ Rollen som Chief Scrum Master | SCRUMstudieblogg . Hämtad 21 oktober 2018. Arkiverad från originalet 25 oktober 2018.
  25. ↑ Endava . Hämtad 21 oktober 2018. Arkiverad från originalet 21 oktober 2018.
  26. ↑ 1 2 The Scrum of Scrums möte - Manifest . Hämtad 21 oktober 2018. Arkiverad från originalet 21 oktober 2018.
  27. ↑ Jeff Sutherland lanserar Scrum@Scale Guide | Henny Portmans blogg . Hämtad 21 oktober 2018. Arkiverad från originalet 21 oktober 2018.
  28. ↑ 1 2 3 Scrum Alliance-medlemsskickade informationsartiklar (länk ej tillgänglig) . Hämtad 21 oktober 2018. Arkiverad från originalet 21 oktober 2018. 
  29. ↑ 1 2 3 4 Vad är ScrumBut? | Scrum.org . Hämtad 21 oktober 2018. Arkiverad från originalet 21 oktober 2018.
  30. ↑ 1 2 ITKaiZenClub "Scrum, men..." eller typiska problem vid implementering av Scrum, 8 februari | GÖR DU
  31. ↑ 1 2 (PDF) Scrum+:: Är det "ScrumBut" eller "ScrumAnd" . Hämtad 21 oktober 2018. Arkiverad från originalet 21 oktober 2018.
  32. ↑ Scrum-teamet och Scrum of Scrums . Hämtad 21 oktober 2018. Arkiverad från originalet 21 oktober 2018.
  33. ↑ Agile organisation med Scrum@Scale, Vimar Spa ett verkligt exempel
  34. ↑ 1 2 Agile i militär hårdvara. Hur SAAB Gripen blev världens mest kostnadseffektiva militära flygplan Arkiverad 20 oktober 2018 på Wayback Machine / Sutherland och Joe Justice , 2017 
  35. ↑ Scaling Agile Series Del 2: En titt på två av fyra populära ramverk för Agile Scaling: SoS och LESS - Gorilla Logic . Hämtad 21 oktober 2018. Arkiverad från originalet 21 oktober 2018.
  36. ↑ The Executive MetaScrum | AgileGenesis . Hämtad 15 mars 2021. Arkiverad från originalet 18 april 2021.
  37. ↑ Executive Action Team - Scrum Inc. Hämtad 15 mars 2021. Arkiverad från originalet 28 februari 2021.
  38. ↑ "Looking for a Backlog Comb Blog of Proactive Business (länk ej tillgänglig) . Datum för åtkomst: 8 december 2018. Arkiverad 27 december 2018. 
  39. ↑ Storskalig Scrum (Mindre) - Alexey Krivitsky - Agile tränare och Scrum-tränare . Hämtad 2 november 2018. Arkiverad från originalet 4 november 2018.
  40. ↑ 1 2 3 Hur skalar man agilt? | öppna system. DBMS | Förlag "Öppna system" . Hämtad 2 november 2018. Arkiverad från originalet 4 november 2018.
  41. ↑ Introduktion till mindre - storskalig scrum (LeSS) . Hämtad 4 november 2018. Arkiverad från originalet 5 november 2018.
  42. ↑ MINDRE - Scrum i skala - ScrumTrek Blog . Hämtad 4 november 2018. Arkiverad från originalet 5 november 2018.
  43. ↑ Nexus-guiden | Scrum.org . Hämtad 4 november 2018. Arkiverad från originalet 5 november 2018.
  44. ↑ RAGE | Skalade agila transformationer | process | cPrime . Hämtad 4 november 2018. Arkiverad från originalet 4 november 2018.
  45. ↑ Arkiverad kopia (länk ej tillgänglig) . Hämtad 4 november 2018. Arkiverad från originalet 5 november 2018. 
  46. ↑ Agil projektledning - vad och varför | APM . Hämtad 4 november 2018. Arkiverad från originalet 5 november 2018.
  47. ↑ Agil projektledning med Scrum . Hämtad 4 november 2018. Arkiverad från originalet 5 november 2018.
  48. ↑ Arkiverad kopia (länk ej tillgänglig) . Hämtad 4 november 2018. Arkiverad från originalet 5 november 2018. 
  49. ↑ Scrum of Scrums | Scrum.org . Hämtad 2 november 2018. Arkiverad från originalet 4 november 2018.
  50. ↑ Nexus-guiden | Scrum.org . Hämtad 2 november 2018. Arkiverad från originalet 5 november 2018.
  51. ↑ Advanced Certified ScrumMaster (A-CSM℠)-certifiering . Hämtad 15 mars 2021. Arkiverad från originalet 17 mars 2021.
  52. ↑ Kurssökning - Scrum Alliance
  53. ↑ Certifierad Scrum Professional ScrumMaster® (CSP-SM) certifieringskurs . Hämtad 15 mars 2021. Arkiverad från originalet 17 mars 2021.
  54. ↑ Scrum Master-certifiering från Scrums hem . Hämtad 15 mars 2021. Arkiverad från originalet 3 mars 2021.
  55. ↑ Ansökningsprocess för certifierad Scrum Trainer (CST) . Hämtad 19 oktober 2018. Arkiverad från originalet 20 oktober 2018.
  56. ↑ PSD Trainer Urvalsprocess och ansökan | Scrum.org . Hämtad 19 oktober 2018. Arkiverad från originalet 20 oktober 2018.
  57. ↑ PSPO Trainer Urvalsprocess och ansökan | Scrum.org . Hämtad 19 oktober 2018. Arkiverad från originalet 20 oktober 2018.
  58. ↑ PSM Trainer Urvalsprocess och ansökan | Scrum.org . Hämtad 19 oktober 2018. Arkiverad från originalet 20 oktober 2018.
  59. ↑ 1 2 Scrum Education Units® (SEU®) poäng för utbildning . Hämtad 15 mars 2021. Arkiverad från originalet 20 april 2021.
  60. ↑ Global Scrum Gathering Event Information & sponsring . Hämtad 15 mars 2021. Arkiverad från originalet 4 mars 2021.
  61. ↑ Scrum Alliance Regionala Scrum-sammankomster . Hämtad 15 mars 2021. Arkiverad från originalet 28 januari 2021.
  62. ↑ Agile och Scrum Training & Certifiering | Scrum Alliance . Hämtad 15 mars 2021. Arkiverad från originalet 21 april 2021.
  63. ↑ Arkiverad kopia . Hämtad 21 oktober 2018. Arkiverad från originalet 21 oktober 2018.
  64. ↑ Scrum Alliance-medlemsskickade informationsartiklar (länk ej tillgänglig) . Hämtad 21 oktober 2018. Arkiverad från originalet 21 oktober 2018. 
  65. ↑ "ScrumAnd"-hållningen (kräver eftertanke och disciplin) | Scrum.org . Hämtad 15 mars 2021. Arkiverad från originalet 14 april 2021.
  66. ↑ 1 2 (PDF) Scrum+:: Är det “ScrumBut” eller “ScrumAnd” . Hämtad 21 oktober 2018. Arkiverad från originalet 21 oktober 2018.
  67. ↑ https://www.researchgate.net/publication/254048455_Scrum_Is_it_ScrumBut_or_ScrumAnd

Se även

Länkar

Litteratur

  Gå till Wikidata-objektet  I bibliografiska kataloger