6.3 Scrum

Slike utviklingsmetoder, det vil si der man planlegger først og utfører arbeidet senere, kalles for fossefallsmetoder. Navnet viser til at man ikke kan angre på valgene man har tatt, litt som når man rafter ned en elv og har passert en foss. Da er det umulig å snu og gå tilbake! Hvis for eksempel et team som jobbet med å kode, fant ut at det hadde vært smartere å designe brukeropplevelsen litt annerledes, var det utenkelig å gå tilbake og rette opp i dette. Siden de hadde brukt så mye tid på å planlegge, ville det ha vært for dyrt å endre planene.

Fossefallsmetoder deler arbeidet inn i oppgaver som skal gjøres i en bestemt rekkefølge: først analyse og planlegging, deretter design og programmering og til slutt testing.

SMIDIGE UTVIKLINGSMETODER

Fordi prosjekter der man brukte en fossefallsmetode, ofte ble forsinket og endte med et lite brukervennlig produkt, ble det etter tusenårsskiftet vanligere å bruke såkalte smidige utviklingsmetoder (agile software development på engelsk). Disse metodene hadde vært i emning i flere tiår, men det var først på dette tidspunktet de slo gjennom.

Målet med smidige utviklingsmetoder er å utvikle et lite, fungerende produkt så fort som mulig og deretter forbedre produktet litt etter litt. I stedet for å legge vekt på den første planleggingen satser oppdragsgiveren og teamet på å ha en løpende dialog. Det er ikke slik at de ikke planlegger i det hele tatt – de planlegger bare i kortere steg.

I kapittel 3 lærte du om hvordan vi gradvis kan forbedre brukeropplevelsen basert på tilbakemeldinger fra brukerne. Smidige utviklingsmetoder kan sies å følge den samme prosessen, bortsett fra at de omfatter hele produktet, ikke bare brukeropplevelsen.

I smidige utviklingsmetoder foregår arbeidet med planlegging, utvikling, testing og evaluering i kortere intervaller kalt iterasjoner eller sprinter. Med en slik metode vil en enkel utgave av produktet være klar tidlig i prosjektet. Produktet blir deretter gradvis forbedret. Teamet får hyppige tilbakemeldinger fra oppdragsgiver og brukere.

Planlegge Iterasjon

Utvikle og teste Evaluere

EKSTRASTOFF

Oppdragsgivere valgte fossefallsprosjekter fordi det virket lurt

Det høres kanskje rart ut at fossefallsmetodene ble brukt over en så lang periode når resultatene var så dårlige. Hvis vi ser det fra oppdragsgivernes perspektiv, er det derimot ikke så rart. Oppdragsgiverne har som regel et budsjett, og da er det naturlig at de velger metoder som både gir dem en garanti om totalkostnadene og en sluttdato for når produktet skal være ferdig. Dessuten brukes fossefallsmetoder i prosjekter i andre bransjer, og det burde jo også være et tegn på at de er effektive.

DISKUTER

Fossefallsmetoder har blitt brukt til å bygge hus, sy klesplagg, bygge skip og ganske mye annet i hundrevis av år. Hvorfor tror du at slike metoder ikke passer like godt når man skal utvikle dataprogrammer? Eller tror du at det er mulig å bruke fossefallsmetoder og likevel lykkes?

FORDELENE MED SMIDIGE UTVIKLINGSMETODER

For oppdragsgivere kan det være litt skummelt å si ja til smidig utvikling, der de verken får oppgitt en sluttdato eller totalkostnadene. I stedet er det som å sette på et taksameter og håpe at man får noe man ønsker seg. Men oppdragsgiverne er også garantert noen fordeler:

•Brukerne får et produkt mye raskere. Produktet er ikke ferdig, men det kan brukes til noe. • Produktet blir som regel mye bedre fordi utviklerne kan justere produktutviklingen basert på tilbakemeldinger fra brukerne. • Hvis oppdragsgiverne ikke er fornøyd med resultatene (og kontrakten med utviklerne gir rom for det), kan de stoppe prosjektet eller ansette nye utviklere før de har brukt for mye penger.

Først etter ganske mange mislykkede fossefallsprosjekter – og en lang rekke vellykkede smidige prosjekter – var oppdragsgivere villig til å inngå kontrakter der de godtok smidig utvikling. I dag brukes smidige utviklingsmetoder i de fleste IT-prosjekter, mens fossefallsprosjekter hører til sjeldenhetene.

En sprinter står på startstreken. Han vet nøyaktig hva han skal gjøre, og hva målet er. I smidige utviklingsmetoder brukes ordet sprint om en arbeidsperiode.

Scrum er den mest kjente smidige metoden. Metoden innebærer at produktet utvikles gradvis, og utviklingen av produktet er organisert i kortere perioder, såkalte sprinter. Sprintene som gjentas jevnlig. I dette delkapittelet skal vi se nærmere på scrumsprinten.

SPRINT: KJERNEN I SCRUM

En sprint har en fast lengde på mellom én og fire uker. Hver sprint består av fire steg (de tre begrepene i kursiv vil bli forklart senere i delkapittelet):

1. Sprintplanlegging: Teamet blir enige om hvilke programmeringsoppgaver de skal fullføre i løpet av sprinten. Dette målet kalles for sprintmålet. Oppgavene finner de i backloggen. 2. Daglig arbeid (også kjent som daglig scrum): Teammedlemmene tar på seg én og én oppgave og løser dem. Teamet har minst ett kort møte hver arbeidsdag, et såkalt standupmøte.. 3. Sprintgjennomgang: Teamet demonstrerer produktet for interessentene i et fysisk eller digitalt møte og får tilbakemeldinger og tips til hva de bør gjøre i neste sprint. Interessentene kan også komme med nye ideer til produktet.

Dersom det er mulig, tas den nye versjonen av produktet i bruk. Denne gjennomgangen skjer gjerne én–to dager før sprinten er over. 4. Retrospektiv: Teamet har et møte der de evaluerer og reflekterer over hva som gikk bra og dårlig i sprinten som nettopp er over, og kommer med forslag til hvordan de kan bli bedre.

I delkapittel 6.5 får du et eksempel på hvordan vi gjennomfører en sprint. Nå skal vi se nærmere på noen av de sentrale scrumbegrepene.

Alle som har noe med sluttproduktet å gjøre

Interessentene

INTERESSENTENE

Interessentene (stakeholders på engelsk) er en håndfull mennesker som representerer alle som har en interesse i produktet, for eksempel de som skal bruke det, og de som betaler for det. Interessentene veileder teammedlemmene under utviklingen av produktet, slik at brukerne og oppdragsgiveren får det produktet de ønsker seg.

Som nevnt ovenfor deltar interessentene i sprintgjennomgangen, så teamet og interessentene snakker sammen minst én gang hver sprint. Teamet kan også ta kontakt med interessentene underveis i sprinten, for eksempel hvis det er noe de lurer på. Interessentene kan også bidra med å finne deltakere til en brukertest. Teamet bør også snakke med interessentene før de starter den første sprinten.

Det er ulike grunner til at interessentene vil bidra i produktutviklingen. Noen blir med fordi de skal bruke produktet og vil påvirke brukeropplevelsen. Andre er med for å passe på at produktet oppfyller ulike krav, for eksempel økonomiske eller juridiske bestemmelser. De sier fra hvis funksjonene som planlegges, er altfor omfattende eller bryter loven. De kan også komme med innspill til måter man kan tjene mer penger på.

Backloggen Meningsutveksling om det som lages

Teamet

Styrer

Produkteieren

For å være interessent må man ha • tid til å delta i sprintgjennomgangene, gjerne i flere måneder • • fremover god kjennskap til hele eller deler av problemet som skal løses motivasjon og et ønske om å bidra til at produktet blir vellykket

EKSTRASTOFF

Å finne interessenter som representerer brukerne

Ofte lager man produkter som skal skal hjelpe brukerne med med å gjøre en del av jobben deres. Slike produkter kan for eksempel være systemer for å loggføre medisiner på et sykehjem, systemer for å registrere utlånte bøker i et bibliotek eller programvaren til et kassaapparat i en butikk. Når man lager et produkt som interessentene skal bruke i jobben, pleier det å være lett å få folk til å stille: Brukerne og brukernes arbeidsgiver vil gjerne ha et så godt produkt som mulig, og derfor får interessentene gjerne fri fra andre forpliktelser for å delta i sprintgjennomgangene. Mange IT-produkter har derimot brukere som ikke skal bruke produktet i jobben, men som selv har valgt å bruke det. I slike tilfeller er det mye vanskeligere å få faktiske brukere til å delta. Sett at det var du som ble bedt om å stille som interessent til en app du bruker på fritiden. Selv om du hadde hatt lyst, hadde skolen eller arbeidsgiveren din neppe gitt deg fri flere ganger i måneden for å møte teamet som utvikler appen. Når man utvikler et produkt som brukerne selv velger å bruke, pleier man å velge en ansatt hos oppdragsgiveren til å representere brukerne. Dette bør være en som kjenner brukerne godt, for eksempel en kundeansvarlig eller en markedsansvarlig. Det er en stor fordel om man også finner en faktisk bruker som er kunnskapsrik, motivert og har tid til å delta.

EKSEMPEL

Interessenter for et søknadsskjema hos NAV

Sett at et team har fått i oppgave av NAV å lage et digitalt søknadsskjema for foreldrepenger. Da kan interessentenel bestå av følgende personer: • Ole, saksbehandler hos NAV. Ole er valgt fordi han jobber med saksbehandling til daglig og skal bruke systemet til slutt. Han er også nybakt far, så han har brukt det gamle søknadsskjemaet på papir. Dermed klarer han til en viss grad å se systemet med perspektivet til en utenforstående. • Nina, jurist hos NAV. Nina er valgtt fordi hun kjenner regelverket og kan si om det er lovlig å lage en viss funksjon eller ikke. • Pekka, direktør for foreldrepengeavdelingen i NAV. Pekka er valgt som representant for oppdragsgiveren (administrasjonen i NAV). Pekka kan blant annet komme med innspill om økonomi, for eksempel om Oles ønsker lar seg gjennomføre innenfor budsjettet.

EKSEMPEL

Interessenter for en app for førerkortopplæring

Trafikkskolen Tut og kjør AS har lyst til å lage en app for elever som skal ta førerkortet, slik at de kan lære seg det de trenger for å bestå teoriprøven. Interessentene består av følgende personer: • Maria, forretningsansvarlig for Tut og kjør AS. Hun kommer med innspill om hvordan man kan tilpasse appen for å tjene penger. • Gisle, trafikklærer med tjue års erfaring og ansatt i Tut og kjør AS. Gisle er ekspert på vegtrafikkloven.

Han har også pedagogisk erfaring fra jobben sin. • Peder, 17 år gammel og en av Gisles elever. Tut og kjør AS spanderer én kjøretime på ham for hver sprintgjennomgang han deltar i – en ganske god deal. Peder representerer elevene. Han har god kjennskap til hva som er populært blant produktets målgruppe.

BACKLOGGEN

Når teamet møter interessentene, hender det at det dukker opp ønsker og ideer for produktet som skal utvikles. Disse ønskene blir så skrevet ned og lagret i teamets backlogg. Backloggen er en liste, for eksempel et regneark, der ønskene sorteres i prioritert rekkefølge. Ønskene som har høyest prioritet, plasseres øverst i backloggen.

Det er vanlig å skrive ned ønskene som såkalte brukerhistorier. En brukerhistorie er et ønske uttrykt som noe en spesifikk type bruker kunne ønske seg. Brukerhistorien er skrevet på en fast form, for eksempel slik: «Som <type bruker> vil jeg kunne <utføre en gitt handling>, slik at <overordnet mål>.» Med en fast form blir det lettere å prioritere ønskene opp mot hverandre og sørge for at alle brukergrupper er ivaretatt.

Under sprintplanleggingen i starten av hver sprint plukker teammedlemmene så mange ønsker fra toppen av backloggen som de tror at det er realistisk å utvikle i løpet av sprinten. Dette blir sprintmålet.