Introduktion til Scrum

Scrums historie

Siden udgivelsen af ​​Winston Royces rapport "Managing the Development of Large Software Systems" i 1970, har mange forsøgt at finde en metode, der kunne eliminere ulemperne ved Waterfall-udviklingsmodellen. Et alternativ til "vandfaldet" var Scrum-metoden, som vil blive diskuteret nu.

Scrum fik sit navn i 1986 fra Takeuchi og Nonakis værk The New Rules for New Product Development. Dette dokument argumenterer for, at den mest effektive måde at nå målet på er at give udviklere en klar handlingsplan.

I 1995 udkom en anden guide, "Softwareudvikling med Scrum," af Sutherland og Schweiber. Denne publikation er siden blevet opdateret flere gange. Nu betragtes det som den vigtigste guide til udviklingen af ​​denne metode. Den aktuelle version af Scrum Guide indeholder oplysninger, der er opdateret i 2020.

Hovedbestemmelserne i Scrum Guiden foreslår, at projektstyringsskabelonen skal tage udgangspunkt i, at udviklere leverer det færdige produkt inden for den aftalte tidsramme - sprints. For en vellykket implementering af Scrum anbefales det at bruge en struktur bestående af flere elementer: roller, begivenheder, regler og artefakter.

Roller i Scrum

Der er tre roller i Scrum, som alle udgør et Scrum-team:

Kunden af ​​softwareproduktet er den vigtigste person i projektet, fordi kun han fuldt ud forstår dets værdi for virksomheden. Kunden forklarer brugernes behov af det fremtidige produkt til udviklerne, men han er ikke ansvarlig for den tekniske del af udviklingsprocessen. Kunden bestemmer også prioriteringen ved oprettelse af bestemte elementer eller funktioner i produktet.

Udviklerne er betroet implementeringen af ​​tekniske opgaver, hvis tværfunktionalitet afhænger af anvendelsesomfanget. Udviklere har travlt med at skabe sprintbacklog, skrive kode, skræddersy projektet til sprintmålet og andre opgaver.

Scrum Master er facilitator for Scrum-teamet. Det yder assistance til kunden og udviklerne. Enkelt sagt er Scrum Master travlt med at kommunikere mellem dem, der ikke er involveret i projektet, og dem, der skriver koden. Nogle gange kommunikerer og koordinerer forskellige teams af kodere i den samme store virksomhed på generalforsamlinger for scrum-mestrene for disse teams.

Arrangementer i Scrum

Der er 5 typer scrum events:

Sprint er den vigtigste del af Scrum. Det omfatter sprintplanlægning, daglige stand-ups (daglig scrum), gennemgang og retrospektiv af spurten.

Sprint planlægning. Alle medlemmer af Scrum-teamet er med til at lægge en plan for den fremtidige sprint. Det er her, at produktideen præsenteres, og hvert teammedlem kan udtrykke sin mening, hvad han synes om dette. Derefter på mødet fastlægges prioriteringer og deadlines annonceres.

Daily Scrum er en daglig kort scrum-begivenhed, der ikke varer mere end 15 minutter. Normalt gøres det for at planlægge arbejdet med indkodere til i dag eller i morgen. På Daily Scrum kan du diskutere aktuelle emner. Alle udviklere involveret i projektet er forpligtet til at deltage i en sådan workshop. Tilstedeværelsen af ​​en Scrum Master er tilladt, men ikke påkrævet.

Sprintgennemgang (Demo) - Vis resultater skabt under spurten. Normalt finder denne begivenhed sted på den sidste fase. Alle interesserede deltager i det.

Sprint Retrospective - diskussion af sprintens resultater. Teammedlemmer deler deres mening om, hvordan de klarede de opgaver, de blev tildelt, og hvordan de kan forbedre resultaterne af arbejdet i fremtiden.

Derudover udføres der nogle gange backlog raffinement - Backlog Refinement. Den diskuterer efterslæb, forberedelse til næste sprint og prioritering af aktuelle opgaver.

Artefakter

Scrum-artefakter er det arbejde, der sker i slutningen af ​​et projekt eller sprint. Der er tre artefakter - produktbacklog, sprintbacklog og stigning. Hver af dem er nødvendige for rettidig levering af software til brugerne. Der er også hjælpeartefakter (brænd ned diagrammer og mere).

Komponenter inkluderet i sprintartefakter:

Produkt backlog - interface og backend funktioner.

En sprint backlog er en liste over opgaver, der skal udføres under en iteration. De aftales inden sprintens start.

Increment - Det samlede antal software-backlog-elementer, der er oprettet under spurten, og værdien af ​​de stigninger, der blev foretaget før det. Det færdige nye tilvækst skal vises inden afslutningen af ​​spurten. Det betyder, at du har en fungerende version, der opfylder scrum-teamets krav.

Produkt backlog vare - den skal udfyldes under sprint iterationen. Som regel er elementet opdelt i flere små opgaver.

Sprintmålet er de opgaver, der skal udføres (opret en efterslæb eller anden opgave).

En sprint burndown er det arbejde, der er tilbage inden afslutningen af ​​en sprint. Nedbrændingsdiagrammet er enten stigende eller faldende. Det hele afhænger af de vanskeligheder, som teammedlemmerne møder, mens de arbejder. Det er ikke en indikator for fremskridt, men kun en måde at løse problemer på og et incitament.

Produktfrigivelse/produktnedbrændingsdiagram er et diagram tegnet af Scrum Master inden slutningen af ​​næste sprint. Den vandrette akse er sprints, den lodrette akse er mængden af ​​tilbageværende arbejde.

Scrum rammeregler

Roller, begivenheder og artefakter er grundlaget for Scrum, men der er andre regler udover dette. Alle af dem øger effektiviteten af ​​arbejdsprocessen. Her er en liste over disse regler:

• Scrum-teamet omfatter softwarekunden, scrummasteren og udviklerne.
• Alle spurter skal have samme længde.
• Efter at have gennemført en spurt begynder arbejdet med en ny med det samme.
• En sprint starter altid med en plan.
• Teammedlemmer har et morgensrum i starten af ​​deres arbejdsdag.
• Hver sprint bliver gennemgået under hver sprint. Dette forbedrer kommunikationen mellem teamet og interessenter.
• Det anbefales ikke at ændre sprintefterslæbet under spurten.

Begrænsninger i Scrum

Ud over de åbenlyse fordele har Scrum også ulemper:

• Scrum fører ofte til et fald i mængden af ​​udført arbejde på grund af manglende fælles deadline.
• Med lav involvering eller manglende vilje til at samarbejde blandt projektdeltagerne er der betydelige chancer for at fejle resultatet.
• Scrum struktur er svær at bruge i store teams, men det er stadig muligt. Der er skaleringsrammer til dette: LeSS, SAFe, Nexus og andre.
• En eller flere medlemmers afgang fra teamet midt i projektet påvirker ikke projektet særlig godt.