scrum (utviklingsmetode)

Et Scrum-team er en tverrfaglig arbeidsgruppe som består av tre roller: utviklere, en Scrum-fasilitator og en produkteier.

Utviklerne må ha den kompetansen som kreves for å lage produktet teamet jobber med. Fasilitatoren skal hjelpe (fasilitere) teamet og organisasjonen med teori og praksis på metoden, og sørge for fremdrift. Produkteier skal klargjøre målet for produktet og etablere en prioritert liste («produktkø») over oppgaver som må gjøres.

Et Scrum-team jobber i korte tidsintervaller, typisk 1–4 uker, som kalles en «sprint». Teamet starter med et planleggingsmøte («sprint planning») hvor de tar oppgaver fra produktkøen og bryter ned oppgavene til en «sprintkø» med mindre omfattende oppgaver. Typisk kan dette være å gå fra en brukerhistorie til tekniske oppgaver. Teamet estimerer da omfanget på oppgavene og spesifiserer gjerne hvordan produktet kan testes for de nye oppgavene. Teamet setter seg også et mål for sprinten.

I løpet av sprinten har teamet korte daglige møter («standups») om fremdrift mot målet for sprinten og tar andre møter etter behov. Ved slutten av sprinten organiserer teamet en evaluering («sprint review»), hvor de viser interessenter hva som er gjort og får tilbakemeldinger på produktet. Videre holder de et retrospektiv-møte («sprint retrospective») for å diskutere gjennomføring av sprinten og identifisere forbedringsmuligheter. Sprinten ender med et produkt som er endret sammenlignet med forrige sprint, et «produktinkrement».

I tillegg til produktkø og sprintkø er det vanlig å lage en beskrivelse av en kvalitetsstandard for et produktinkrement eller en brukerhistorie. Det vil si at man lager en «definisjon av ferdig» («definition of done»). Tidligere var det vanlig å også lage et brenndiagram («burndown-chart»), som viser teamets estimat på gjenstående arbeid gjennom sprinten.

Fordeler med Scrum er – som for andre smidige utviklingsmetoder – at metoden gir utviklingsteamet fleksibilitet til å raskt tilpasse seg endringer i krav eller markedsforhold. Retrospektivmøtene gjør at man også får hyppige evalueringer som kan forbedre arbeidet. Metoden krever imidlertid stor grad av selvorganisering og samarbeid, som kan være utfordrende i store prosjekter eller mer hierarkiske strukturer.

Scrum brukes ofte i kombinasjon med ekstremprogrammering (XP).

Scrum legger mer vekt på aspekter ved prosjektledelse, ved planlegging av oppgaver og praksiser for jevnlig å kommunisere tilstand på produkt under utvikling. Ekstremprogrammering legger vekt på mer utviklingsnære praksiser, som å sikre programvarekvalitet ved at to utviklere jobber sammen om å skrive kode i praksisen parprogrammering, og gjennom fokus på testing for eksempel i praksisen test-drevet utvikling.

Videre fokuserer ekstremprogrammering på kommunikasjon i et utviklingsteam gjennom en felles kodestandard og kollektivt eierskap til kode.

Begrepet Scrum stammer fra en artikkel fra 1986 i Harvard Business Review skrevet av japanerne Hirotaka Takeuchi og Ikujiro Nonaka, som beskrev en ny tilnærming til produktutvikling basert på case-studier fra produksjonsbedrifter. De kalte det rugby-metoden, hvor et kryssfunksjonelt team arbeider i flere overlappende faser for økt fleksibilitet og hastighet.

På 1990-tallet utviklet amerikanerne Ken Schwaber og Jeff Sutherland hver sin versjon av metoden, før de slo seg sammen for å forme det som i dag er kjent som Scrum. De publiserte en forskningsartikkel om Scrum i 1995 og bidro til det såkalte smidige manifestet i 2001.

• smidige utviklingsmetoder

• Kniberg, Henrik (2015): Scrum and XP from the Trenches (2nd edition ed.). InfoQ.
• Schwaber, Ken og Sutherland, Jeff (2020): Scrum Guiden – Den definitive guide til Scrum: Spillets regler. Norsk oversettelse av Benjamin Sommer og Geir Amsjø.
• Sommerville, Ian (2016): Software Engineering, Tenth edition ed. Harlow, England: Pearson Education Limited.