Scrums historia
Sedan publiceringen av Winston Royces rapport "Managing the Development of Large Software Systems" 1970 har många försökt hitta en metod som skulle kunna eliminera nackdelarna med Waterfall-utvecklingsmodellen. Ett alternativ till ”vattenfallet” var Scrum-metoden, som kommer att diskuteras nu.
Scrum fick sitt namn 1986 från Takeuchi och Nonakis verk The New Rules for New Product Development. Detta dokument hävdar att det mest effektiva sättet att uppnå målet är att ge utvecklare en tydlig handlingsplan.
1995 dök en annan guide, "Software Development with Scrum", av Sutherland och Schweiber, upp. Denna publikation har sedan dess uppdaterats flera gånger. Nu anses det vara huvudguiden för utvecklingen av denna metod. Den aktuella versionen av Scrum Guide innehåller information uppdaterad 2020.
Huvudbestämmelserna i Scrum Guide föreslår att projektledningsmallen ska baseras på att utvecklare levererar den färdiga produkten inom den överenskomna tidsramen - sprints. För en framgångsrik implementering av Scrum rekommenderas att använda en struktur som består av flera element: roller, händelser, regler och artefakter.
Roller i Scrum
Det finns tre roller i Scrum, som alla utgör ett Scrum-team:
Kunden av mjukvaruprodukten är den viktigaste personen i projektet, eftersom endast han förstår dess värde för verksamheten. Kunden förklarar behoven hos användarna av den framtida produkten för utvecklarna, men han ansvarar inte för den tekniska delen av utvecklingsprocessen. Kunden bestämmer också prioritet när man skapar vissa element eller funktioner i produkten.
Utvecklarna anförtros genomförandet av tekniska uppgifter, vars tvärfunktionalitet beror på tillämpningens omfattning. Utvecklare är upptagna med att skapa sprintbacklog, skriva kod, skräddarsy projektet till sprintmålet och andra uppgifter.
Scrum Master är facilitator för Scrum-teamet. Det ger hjälp till kunden och utvecklarna. Enkelt uttryckt är Scrum Master upptagen med att kommunicera mellan de som inte är involverade i projektet och de som skriver koden. Ibland kommunicerar och samordnar olika team av kodare i samma stora företag på generalmöten för dessa teams scrummasters.
Evenemang i Scrum
Det finns 5 typer av scrum-event:
Sprint är den viktigaste delen av Scrum. Det inkluderar sprintplanering, dagliga stand-ups (daglig scrum), granskning och retrospektiv av sprinten.
Sprintplanering. Alla medlemmar i Scrum-teamet är med och gör upp en plan för den framtida sprinten. Det är här som produktidén presenteras och varje teammedlem kan uttrycka sin åsikt, vad han tycker om detta. Sedan på mötet fastställs prioriteringar och deadlines meddelas.
Daily Scrum är ett dagligt kort scrum-evenemang som inte varar mer än 15 minuter. Vanligtvis görs det för att planera kodarnas arbete för idag eller imorgon. På Daily Scrum kan du diskutera aktuella frågor. Alla utvecklare som är involverade i projektet är skyldiga att delta i en sådan workshop. Närvaron av en Scrum Master är tillåten, men krävs inte.
Sprintrecension (Demo) - Visa resultat skapade under sprinten. Vanligtvis sker denna händelse i slutskedet. Alla intresserade deltar i det.
Sprint Retrospective - diskussion om sprintens resultat. Teammedlemmar delar med sig av sin åsikt om hur de klarade de uppgifter som de tilldelats och hur de kan förbättra resultaten av arbetet i framtiden.
Dessutom utförs ibland eftersläpning - Backlog Refinement. Den diskuterar eftersläpningar, förberedelser för nästa sprint och prioritering av aktuella uppgifter.
Artefakter
Scrum-artefakter är det arbete som sker i slutet av ett projekt eller en sprint. Det finns tre artefakter - produktbacklog, sprintbacklog och inkrement. Var och en av dem behövs för snabb leverans av programvara till användarna. Det finns också extra artefakter (bränn ner diagram och mer).
Komponenter som ingår i sprintartefakter:
Produktbacklog - gränssnitt och backend-funktioner.
En sprintbacklog är en lista över uppgifter som måste göras under en iteration. De är överenskomna innan sprinten börjar.
Inkrement - Det totala antalet eftersläpningar av programvara som skapats under sprinten och värdet av ökningarna som gjordes före den. Det färdiga nya steget måste visas före sprintens slut. Det betyder att du har en fungerande version som uppfyller kraven från scrumteamet.
Produkt eftersläpning - det måste fyllas i under sprint iterationen. Som regel är elementet uppdelat i flera små uppgifter.
Sprintmålet är de uppgifter som behöver slutföras (skapa en eftersläpningspost eller annan uppgift).
En sprint burndown är det arbete som återstår innan slutet av en sprint. Nedbränningsdiagrammet är antingen stigande eller fallande. Allt beror på de svårigheter som teammedlemmarna möter när de arbetar. Det är inte en indikator på framsteg, utan bara ett sätt att lösa problem och ett incitament.
Product Release/Product Burn-Down Chart är ett diagram ritat av Scrum Master före slutet av nästa sprint. Den horisontella axeln är sprints, den vertikala axeln är mängden arbete som återstår.
Scrum ramregler
Roller, händelser och artefakter är grunden för Scrum, men det finns andra regler utöver detta. Alla förbättrar effektiviteten i arbetsprocessen. Här är en lista över dessa regler:
- Scrum-teamet inkluderar mjukvarukunden, scrummaster och utvecklare.
- Alla spurter ska vara lika långa.
- Efter att ha klarat en sprint börjar arbetet med en ny omedelbart.
- En sprint börjar alltid med en plan.
- Teammedlemmar har en morgonscrum i början av sin arbetsdag.
- Varje sprint ses över under varje sprint. Detta förbättrar kommunikationen mellan teamet och intressenter.
- Det rekommenderas inte att ändra sprintbacklog under sprint.
Begränsningar i Scrum
Tillsammans med de uppenbara fördelarna har Scrum också nackdelar:
- Scrum leder ofta till att mängden utfört arbete minskar på grund av bristen på en gemensam deadline.
- Med lågt engagemang eller ovilja att samarbeta bland projektdeltagarna finns det stora chanser att misslyckas med resultatet.
- Scrum-struktur är svår att använda i stora team, men ändå är det möjligt. Det finns skalningsramverk för detta: LeSS, SAFe, Nexus och andra.
- Att en eller flera medlemmar lämnar teamet mitt i projektet påverkar inte projektet särskilt väl.