Introduksjon til Scrum

Scrums historie

Siden utgivelsen av Winston Royces rapport "Managing the Development of Large Software Systems" i 1970, har mange forsøkt å finne en metodikk som kan eliminere ulempene ved Waterfall-utviklingsmodellen. Et alternativ til «fossen» var Scrum-metoden, som vil bli diskutert nå.

Scrum fikk navnet sitt i 1986 fra Takeuchi og Nonakis verk The New Rules for New Product Development. Dette dokumentet argumenterer for at den mest effektive måten å nå målet på er å gi utviklere en klar handlingsplan.

I 1995 dukket det opp en annen guide, "Software Development with Scrum," av Sutherland og Schweiber. Denne publikasjonen har siden blitt oppdatert flere ganger. Nå regnes det som hovedveiledningen for utviklingen av denne metoden. Den nåværende versjonen av Scrum Guide inneholder informasjon oppdatert i 2020.

Hovedbestemmelsene i Scrum Guide tilsier at prosjektstyringsmalen bør baseres på at utviklere leverer det ferdige produktet innenfor avtalt tidsramme – sprints. For vellykket implementering av Scrum anbefales det å bruke en struktur som består av flere elementer: roller, hendelser, regler og artefakter.

Roller i Scrum

Det er tre roller i Scrum, som alle utgjør et Scrum-team:

Kunden av programvareproduktet er den viktigste personen i prosjektet, fordi bare han fullt ut forstår verdien for virksomheten. Kunden forklarer behovene til brukerne av det fremtidige produktet til utviklerne, men han er ikke ansvarlig for den tekniske delen av utviklingsprosessen. Kunden bestemmer også prioritet ved opprettelse av enkelte elementer eller funksjoner i produktet.

Utviklerne er betrodd implementeringen av tekniske oppgaver, hvis tverrfunksjonalitet avhenger av anvendelsesomfanget. Utviklere er opptatt med å lage sprintbacklog, skrive kode, skreddersy prosjektet til sprintmålet og andre oppgaver.

Scrum Master er tilrettelegger for Scrum-teamet. Det gir bistand til kunden og utviklerne. Enkelt sagt er Scrum Master opptatt med å kommunisere mellom de som ikke er involvert i prosjektet og de som skriver koden. Noen ganger kommuniserer og koordinerer forskjellige team av programmerere i samme store selskap på generalforsamlinger til scrum-mestrene til disse lagene.

Arrangementer i Scrum

Det er 5 typer scrum-arrangementer:

Sprint er den viktigste delen av Scrum. Det inkluderer sprintplanlegging, daglige stand-ups (daglig scrum), gjennomgang og retrospektiv av sprinten.

Sprintplanlegging. Alle medlemmene i Scrum-teamet er med på å lage en plan for fremtidens sprint. Det er her produktideen presenteres og hvert teammedlem kan si sin mening, hva han synes om dette. Så på møtet blir prioriteringer fastsatt og frister kunngjort.

Daily Scrum er et daglig kort scrum-arrangement som ikke varer mer enn 15 minutter. Vanligvis gjøres det for å planlegge arbeidet med kodere for i dag eller i morgen. På Daily Scrum kan du diskutere aktuelle saker. Alle utviklere som er involvert i prosjektet er pålagt å delta på en slik workshop. Tilstedeværelsen av en Scrum Master er tillatt, men ikke nødvendig.

Sprintgjennomgang (Demo) – Vis resultater opprettet under sprinten. Vanligvis finner denne begivenheten sted på sluttfasen. Alle interesserte deltar i det.

Sprint Retrospective - diskusjon av sprintens resultater. Teammedlemmer deler sin mening om hvordan de taklet oppgavene de ble tildelt og hvordan de kan forbedre resultatene av arbeidet i fremtiden.

I tillegg utføres noen ganger etterslepsforbedring - Backlog Refinement. Den diskuterer etterslep, forberedelse til neste sprint og prioritering av aktuelle oppgaver.

Gjenstander

Scrum-artefakter er arbeidet som skjer på slutten av et prosjekt eller en sprint. Det er tre artefakter - produktetterslepet, sprintrestansen og inkrementet. Hver av dem er nødvendig for rettidig levering av programvare til brukere. Det er også hjelpeartefakter (brenn ned diagrammer og mer).

Komponenter inkludert i sprintartefakter:

Produktetterslep - grensesnitt og backend-funksjoner.

En sprintbacklog er en liste over oppgaver som må gjøres under en iterasjon. De avtales før sprintstart.

Inkrement - Det totale antallet programvareetterslep-elementer som ble opprettet under sprinten og verdien av økningene som ble gjort før den. Det ferdige nye trinnet må vises før slutten av sprinten. Dette betyr at du har en fungerende versjon som oppfyller kravene til scrum-teamet.

Produktbacklog-element - det må fullføres under sprint-iterasjonen. Som regel er elementet delt inn i flere små oppgaver.

Sprintmålet er oppgavene som skal fullføres (opprette en backlog-post eller annen oppgave).

En sprint burndown er arbeidet som gjenstår før slutten av en sprint. Nedbrenningsdiagrammet er enten stigende eller synkende. Alt avhenger av vanskelighetene som teammedlemmer møter mens de jobber. Det er ikke en indikator på fremgang, men bare en måte å løse problemer på og et insentiv.

Product Release/Product Burn-Down Chart er et diagram tegnet av Scrum Master før slutten av neste sprint. Den horisontale aksen er sprints, den vertikale aksen er mengden arbeid som er igjen.

Scrum rammeregler

Roller, hendelser og artefakter er grunnlaget for Scrum, men det finnes andre regler i tillegg til dette. Alle av dem øker effektiviteten i arbeidsprosessen. Her er en liste over disse reglene:

• Scrum-teamet inkluderer programvarekunden, scrum-mesteren og utviklerne.
• Alle spurter skal være like lange.
• Etter å ha fullført en sprint, begynner arbeidet med en ny umiddelbart.
• En sprint starter alltid med en plan.
• Teammedlemmer har en morgenscrum ved starten av arbeidsdagen.
• Hver sprint blir gjennomgått under hver sprint. Dette forbedrer kommunikasjonen mellom teamet og interessenter.
• Det anbefales ikke å endre sprintetterslepet under sprint.

Begrensninger i Scrum

Sammen med de åpenbare fordelene har Scrum også ulemper:

• Scrum fører ofte til en nedgang i mengden arbeid som utføres på grunn av manglende felles tidsfrist.
• Med lavt engasjement eller manglende vilje til å samarbeide blant prosjektdeltakerne, er det store sjanser for å mislykkes med resultatet.
• Scrum-struktur er vanskelig å bruke i store team, men likevel er det mulig. Det finnes skaleringsrammer for dette: LeSS, SAFe, Nexus og andre.
• Avgang av ett eller flere medlemmer fra teamet midt i prosjektet påvirker ikke prosjektet særlig godt.