Scrum

Fra Wikipedia, den frie encyklopedi
Gå til: navigasjon, søk
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[rediger | rediger kilde]

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[rediger | rediger kilde]

Scrum definerer et team (Scrum-teamet) som selvdrevet og med store fullmakter til å nå definerte mål for programvareutviklingen. Målene nåes gjennom å utvikle konkrete, små produktinkrementer i iterasjoner på 1-4 uker. De funksjonene man skal utvikle for å nå målene legges i en liste kalt Product Backlog (Produktkø). Denne er alltid levende, elementene er grovestimerte og ligger alltid i prioritert rekkefølge. Hvert inkrement som lages blir gjenstand for inspeksjon der man evaluerer resultatet og sørger for å lære. I Scrum kalles iterasjonene Sprinter. Det første man gjør i en Sprint er å plukke ut det sett med funksjoner som skal implementeres fra toppen av Produktkøen. For hver av disse funksjonene lager man så oppgavelister og ender så opp med en "Sprint backlog". Underveis i Sprinten gjennomføres daglige møter der team-medlemmene koordinerer arbeidet seg imellom. Møtet, som oftes holdes stående, skal vare maksimum et kvarter og i løpet av denne perioden skal alle team-medlemmene 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?

Det siste man gjør i Sprinten er å demonstrere det inkrementet som ble laget til noen utvalgte interessenter. Dette kalles Sprint review. Hensikten med dette er å få tilbakemeldinger fra de som har behovene og få verdifulle innspill til forbedringer basert på det som demonstreres. Etter dette gjennomfører hele Scrum teamet et tilbakeblikk-møte ("sprintreflesjon") der man samler erfaringer fra siste Sprint og finner måter å jobbe litt mer effektivt på i neste Sprint.

Roller[rediger | rediger kilde]

De som gjør alt nødvendig arbeid kalles Scrum-teamet. Scrum-teamet består av Produkteier, Scrum-master og Utviklingsteamet.

Produkteieren[rediger | rediger kilde]

Produkteieren eier visjonen og representerer interessentene (dette kan være interne og eksterne kunder, brukere ledere, innkjøpere etc..) og skal sikre at Scrum-teamet til enhver tid jobber med de rette tingene sett fra et forretningsperspektiv. Produkteieren er ansvarlig for at Product Backlogen til enhver tid er estimert, prioritert og tilgjengelig for interessentene og utviklingsteamet. 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. Produkteieren kan være en del av Scrum-teamet, men skal aldri være Scrum-master.

Scrum-master[rediger | rediger kilde]

Scrum-master er ansvarlig for at Utviklingsteamet lærer seg å selvorganisere, at Produkteier forstår sin rolle og at samspillet mellom disse fungerer godt. Scrum-master er ansvarlig for at man hele tiden forbedrer arbeidsformen og at refleksjonsmøtene fører til forbedring. Om det er nødvendig må Scrum-master beskytte Utviklingsteamet mot for mye forstyrrelser.

Utviklingsteamet[rediger | rediger kilde]

Dette teamet er tverrfaglig og består typisk av 3 til 9 personer. Det er helt avgjørende at teamet innehar all kompetansen som er nødvendig for å lage produktinkrementene. Bare på den måten vil de kunne jobbe optimalt som selvorganisert team. Teamet tar kollektivt ansvar for å skape mest mulig verdier for interessentene.

Sprinter[rediger | rediger kilde]

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 produkteier. 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 sprintrefleksjon.

Fordeler og ulemper ved Scrum[rediger | rediger kilde]

Fordeler:

  • Enklere å tilpasse seg endrede, eksterne faktorer og redusere behovet for å kunne forutsi endringene og framtidige behov.
  • Enklere å håndtere kompleksitet gjennom at man samarbeider tverrfaglig og at teamet høster lærdom av resultatet av hver Sprint.
  • Det vil være mindre behov for oppfølging og styring, og dermed langt mer effektivt enn tradisjonelle metoder.
  • 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, så om man har full kontroll på kravene og løsningen gir ikke Scrum noen gevinst.
  • Scrum vil utfordre tradisjonelle organisasjoner kraftig, og dette kan føre til turbulens og sterk motstand.
  • Ikke alle team vil selvorganisere og ta kollektivt eierskap, og derfor hviler det et stort ansvar på Scrum-master som må ha kunnskap nok til å detektere dette problemet og forsøke å bøte på det.

Referanser[rediger | rediger kilde]