Scrum

Antiva satser på Scrum vi benytter Scrum daglig i våre prosjekter, og har høstet god og positiv erfaring med bruk av Scrum. Vi mener Scrum er et godt og moderne rammeverk for organisering av utviklingsprosjekter. Antiva har jobbet med Scrum i siden oppstart, og noen av våre konsulenter har jobbet med Scrum siden ca. 2002. Vi har sertifiserte Scrum Mastere og tilbyr tjenester som Scrum Mastere eller rådgivning ved innføring av Scrum.

Introduksjon til Scrum


Scrum prosjekter grunnleggende manifest

  • Personer og kommunikasjon i stedet for prosesser og verktøy
  • Kjørende programvare i stedet for utdypende dokumentasjon
  • Samarbeide med kunde i stedet for kundeforhandlinger
  • Håndtere endringer framfor følge en plan

Scrum er

  • Resultatorientert
  • Drevet av commitment
  • Er fokusert på kundeverdier
  • Utvikler og respekterer team

Misforståelser med Scrum

Det er en del misforståelser med Scrum.
En av oppfatningene er at det ikke lages dokumentasjon.
Manifestet sier man skal prioritere kjørende programvare i stedet for utdypende
dokumentasjon, men man skal selvlagt lage brukerdokumentasjon, designdokumentasjon, analyser, databasemodeller osv. Scrum er et prosjektrammeverk og behov for dokumentasjon må tilpasses prosjektets størrelse og kompleksitet.

En annen oppfatning er at Scrum ikke passer for store prosjekter. Dette er også feil, Scrum kan skaleres opp, og det er kjørt Scrum prosjekter med over 500 deltagere.

En tredje oppfatning er at Scrum ikke passer for fastprisprosjekter. Dette er feil. Man kan utmerket godt kjøre Scrum med fastprisprosjekter. Det passer vesentlig bedre enn tradisjonell fossefall, da man har langt bedre kontroll på tid og kostnader.

Roller og ansvar

Et Scrum prosjekt har 3 type aktører (roller):

Produkteier

  • Definerer egenskaper og funksjoner til produktet, released dato og innhold
  • Prioriteter egenskaper og funksjoner
  • Setter prioritet til hver iterasjon
  • Aksepterer eller avslår resultatet

Scrum Master

  • Passer på at teamet er komplett og produktiv
  • Bidrar til nært samarbeide mellom ulike kompetanseområder og fjerner barrierer
  • Beskytter teamet fra forstyrrelser utenfra
  • Ser til at Scrum prosessen følges.
  • Deltar i daglig scrum møter, iterasjonsgjennomgang og iterasjonsplanleggingsmøte

Team

  • Normalt 5-9 personer
  • Medlemmene bør jobbe full tid
  • Teamet organiserer seg selv
  • Må inneholde alle disipliner nødvendig for å levere det som er planlagt for en iterasjon
  • Er ansvarlig for å levere planlagt funksjonalitet for en iterasjon

Product Backlog

En av de viktigste oppgaven til produkteier er å prioritere produkt backloggen.
  • Product backlog inneholder en prioritert liste over funksjoner og egenskaper (User Stories).
  • Hver User Story er av verdi for brukerne eller kunden.
  • Prioriteres av produkteier.
  • Reprioritert ved begynnelsen av hver iterasjon.

User Stories

  • Skrives på kort, post-it eller lignende
  • Kan annoteres med notater, estimater etc.
  • Bak på kortet skriver man akseptansetestkriterier.
  • Kort er huskelapp for kommunikasjon - detaljer om innholder klargjøres gjennom samtaler med produkteier
  • En User Story kan være på formen: "Som en [rolle] vil jeg [mål] slik at [begrunnelse]".

Arbeidsgrupper for å skrive User Stories

  • Arbeidsgrupper for å skrive User Stories
  • Brainstorm for å generere så mange User Stories som mulig
  • Ingen prioritering på dette punktet
  • Definer roller hvis mulig
  • Begynn gjerne med en rolle, hva skal denne rollen kunne gjøre?

Sprint / Iterasjoner

Missing Image
Et Scrumprosjekt er inndelt i iterasjoner. En iterasjon går over 2 - 4 uker. Kortere iterasjoner gir større og raskere mulighet for tilpasning, så det kan være fornuftig å starte med 2 ukers iterasjoner. En iterasjon skal levere en mulig leveranseklart produktforbedring. Disse produktforbedringene skal være av høy kvalitet, testet og komplett. Det er et grunnleggende prinsipp i Scrum at man ikke kan forskyve på iterasjonsdatoene, det er da bedre å kutte funksjonalitet i den iterasjonen. Man kan fortsatt ta inn denne funksjonen i en senere iterasjon. Iterasjonsdatoene er "hellig".

Det er et par grunnleggende regler hva gjelder iterasjoner: Teamet commiter seg til å levere teset og potensiell leveranseklar funksjonalitet, men forretningen får ikke gjøre endringer i løpet av en iterasjon. Forretningen kan selvsagt komme med nye User Stories (krav), men ikke User Stories som er under utvikling i en iterasjon.

Møter i Scrum

Scrum har disse sentrale / faste møtene:

Planlegging av en iterasjon - Sprintplanning

Dette møtet holdes helt på begynnelsen (første dagen) av en iterasjon. Møtet har en ramme på fire timer, men kan gjerne være kortere. På møtet deltar teamet, Scrum Master, Produkteier, og evnt. andre personer som kan bidra med avklaringer på de prioriterte funksjonene (User Stories). På møtet skal man:
  • Gjennomgå product backlog, stille spørsmål, få avklaringer.
  • Sette mål for iterasjonen.
  • Plukke prioriterte User Stories
  • Opprette Sprint Backlog (oppgaver) fra de prioriterte User Stories.
  • Overordnet design (hvordan nå målet for iterasjonen)
  • Estimere Sprint Backlog (timer).
Det er ikke nødvendig å fordele Sprint Backlog oppgavene til team medlemmene, dette avklares i teamet selv.

Daglig møte

Hver dag møtes teamet og Scrum Master til et kort 15 minutters stående møte. Møtetidspunktet er fast av bestemt av teamet. Møtet holdes normalt ved Scrum tavlen og hver person på teamet svarer på 3 grunnleggende spørsmål:

  1. Hva gjorde jeg i går (hva jeg oppnådde / leverte)
  2. Hva planlegger jeg å gjøre i dag
  3. Hvilke utfordringer / problemer har jeg

Teammedlemmene "rapporterer" til hverandre, og ikke til Scrum Master. Scrum Master's rolle er å se til at Scrum prosessen følges. Der Scrum Master også er en del av teamet, vil han rapportere til de andre teammedlemmene på samme måte. Under møtet kan hvert teammedlem gjerne referere til oppgaver som står på Scrum tavlen, og oppdatere estimat for gjenstående arbeide, og evnt. flytte oppgaver til neste fase. Alle må møte presis til møtet og møtet skal ikke overstige 15 minutter.
Man skal ikke løse problemer under møtet, kun identifisere de.

Gjennomgang av utført iterasjon - Sprint review

Møtet holdes på slutten av en iterasjon.
  • Teamet presenterer hva det har levert i siste iterasjon.
  • Gjøres i form av demo av nye funksjoner og underliggende arkitektur
  • Uformelt
  • Behøver ikke benytte Power Point eller lignende
  • Hele teamet deltar
  • Produkteier og andre personer etter behov deltar

Tilbakeblikk - Sprint retrospective

  • Drøfter hva som fungerer og hva som ikke fungerer
  • 15 - 30 minutters varighet
  • Gjøres etter hver iterasjon
  • Hele teamet deltar
  • Scrum Master, Produkteier og eventuelt kunde eller andre deltar