Scrum

Illustrasjon av metodikken i SCRUM

Scrum er et rammeverk laget med henblikk på å utvikle komplekse informasjonssystemer. Det brukes i hovedsak til å utvikle programvarebaserte systemer og benyttes gjerne i kombinasjon med Extreme Programming (XP), men kan i prinsippet brukes til å håndtere alle slags prosjekter av en viss kompleksitet. Teorien er basert på empirisk prosesskontroll og fordrer at man jobber inkrementelt og iterativt og at selve utviklingsjobben utføres av tverrfaglige, selvstyrte team.

Historie

Scrum, inspirert av et begrep i Rugby, ble formelt utviklet som prosjektmetodikk av Jeff Sutherland og Ken Schwaber og ble første gang presentert på OOPSLA '95 i Austin. Scrum er i dag det desidert mest benyttede smidige Agile rammeverk.

Beskrivelse

Scrum definerer et team (Scrum-teamet) som selvdrevet og med store fullmakter til å nå definerte mål for programvareutviklingen. I henhold til denne metodikken er det ikke krav om spesifikasjoner eller detaljert planlegging av arbeidsoppgavene i prosjektgjennomføringen. Typisk gjennomføres et prosjekt i henhold til Scrum i iterasjoner på en uke opp til en måneds lengde – kalt en Sprint. I forkant av en Sprint plukkes det ut et sett med funksjoner som skal implementeres fra en liste av gjeldende krav til prosjektets resultat. Denne kravlisten kalles Product backlog (Produktkø). Listen av krav som skal implementeres i løpet av en gitt Sprint kalles Sprint backlog (Sprintkø). Underveis i prosjektet gjennomføres daglige møter med Scrum-master hvor alle medlemmer av teamet skal være til stede. Møtet, som oftes holdes stående, skal vare omtrent et kvarter og i løpet av denne perioden skal alle gruppens medlemmer gi uttrykk for følgende tre forhold:

• Hva er gjort siden forrige scrum-møte?
• Hva skal gjøres før neste møte?
• Hva har (eventuelt) vært til hinder for at gruppemedlemmet var effektiv i implementeringen av funksjonalitet?

Scrum-masteren har som hovedoppgave å sørge for at disse møtene blir holdt samt at utviklingsgruppen har de best mulige forhold og betingelser for å være effektive. I etterkant av en Sprint avholdes et evalueringsmøte hvor resultatene fra den siste perioden sammenholdes med de krav som ble avtalt implementert i forkant. Dernest forplikter gruppen seg til å implementere et nytt sett med funksjonalitet fra produktkøen.

Rollefordeling

Scrum-prosessen omfatter i utgangspunktet tre ulike roller: Produkteier, Scrum-master og scrum-team.

Produkteieren

Produkteieren representerer gjerne kunden eller brukeren og skal sikre at Scrum-teamet jobber med de rette tingene sett fra et forretningsperspektiv. Produkteieren opprettholder en «backlog», overordnet beskrivelse av krav og ønsker for hele prosjektet. Denne listen omprioriteres konstant. Produkteieren er en person, ikke en gruppe. Grupper kan gi råd i produktutviklingen, men det er personen som har produkteierrollen som tar beslutningene om prioriteringer. Ingen andre enn produkteieren skal bestemme prioriteringene i prosjektet, og alle må respektere hans eller hennes beslutninger. Produkteieren kan være en del av Scrum-teamet, men skal aldri være Scrum-master.

Scrum-master

Scrum-master er en person som fungerer som en portvakt mot Scrum-teamet og skal blant annet sørge for at å fjerne hindringer som kan hindre Scrum-teamet i å levere målet for den inneværende, begrensede tidsperioden.

Scrum-teamet

Scrum-teamet består typisk av 3 til 9 personer med ulik kompetanse, for eksempel designere, utviklere og andre. Disse er ansvarlige for å gjøre selve utviklingsarbeidet og å levere produktet. Teamet organiserer seg selv og har ingen formell leder.

Sprinter

I Scrum jobber man i tidsbokser (iterasjoner) med fast lengde og disse kalles sprinter. En sprint kan maksimum ha en lengde på en måned, og den kan gjerne være kortere. Lengden på sprinten settes av Scrum-teamet i samarbeid med Product Owner. Det blir mer og mer vanlig å kjøre sprinter som går over 2 uker.

Når en sprint starter forplikter teamet seg til å levere det omfanget fra produktkøen de har tro på at de skal klare. Dette omfanget er i utgangspunktet plukket ut av produkteier, som også har satt et sprint-mål. På bakgrunn av den valgte produktkøen definerer teamet alle de oppgavene de må fullføre for å oppnå målet. Dette kalles Sprint Backlog (sprintkø).

Sprinten avsluttes med at teamet demonstrerer det de har laget for utvalgte interessenter og produkteier i et sprint review-møte. Det aller siste man alltid gjør i sprinten er et tilbakeblikk med evaluering av hva som gikk godt, hva som bør forbedres og hvilke tiltak man skal iverksette for å bli bedre. Dette kalles Sprint Retrospective.

Fordeler og ulemper ved Scrum

Fordeler:

• Enklere å tilpasse seg endrede, eksterne faktorer og redusere behovet for å kunne forutsi endringene og framtidige behov.
• Effektivitet og produktivitet blant programmerere som benytter Scrum kan være høyere enn andre metodikker.
• Kunden og sluttbrukeren involveres i større grad i utviklingsprosessen.

Ulemper:

• Scrum gir liten eller ingen mulighet til å fastsette krav og resultat på forhånd.
• Det kan derfor være vanskelig eller utfordrende å selge inn prosjekter gjennomført etter denne metodikken til prosjekteiere som ikke er kjent med eller trygg på metodikken.

Referanser

Den offisielle Scrum Guiden

• Schwaber, Ken. Scrum Development Process. OOPSLA'95 Business Object Design and Implementation Workshop
• Schwaber, Ken (1 February 2004). Agile Project Management with Scrum. Microsoft Press. ISBN 978-0-735-61993-7. 

• Schwaber, Ken; Beedle, Mike (18 February 2002). Agile Software Development with Scrum. Prentice Hall. ISBN 978-0-130-67634-4.