Smidig utvikling

Smidig (agile) utvikling er en tilnærming til systemutvikling som vektlegger iterativ og inkrementell utvikling, tett samarbeid med kunden, og evne til å tilpasse seg endringer. Det smidige manifestet (2001) er grunnlaget og uttrykker fire verdier: individer og samspill over prosesser og verktøy, fungerende programvare over grundig dokumentasjon, kundesamarbeid over kontraktsforhandlinger, og respons på endring over å følge en plan.

Manifestet har 12 smidige prinsipper som konkretiserer verdiene. De viktigste å kjenne for eksamen er: (1) Tilfredsstille kunden gjennom tidlige og kontinuerlige leveranser, (2) Ønske endringer velkommen, (3) Lever fungerende programvare hyppig (uker, ikke måneder), (7) Fungerende programvare er det primære målet på fremdrift, (9) Kontinuerlig fokus på teknisk kvalitet, (11) Selvstyrte team, og (12) Reflekter jevnlig over prosessen. På eksamen V2020 var alle 12 prinsippene gitt som vedlegg, og oppgaven ba om å koble dem til DevOps.

Scrum

Scrum er det mest brukte smidige rammeverket og har tre roller:

Produkteier (PO): Ansvarlig for produktkøen (backlog), prioriterer brukerhistorier basert på forretningsverdi, representerer kundens interesser, og bestemmer hva som skal bygges. PO er den ENESTE som bestemmer rekkefølgen på produktkøn.
Scrum Master: Fasiliterer Scrum-prosessen, fjerner hindringer for teamet (impediments), sikrer at Scrum-reglene følges, og beskytter teamet mot forstyrrelser utenfra. Scrum Master er IKKE en prosjektleder -- rollen er en tjenende leder (servant leader).
Utviklingsteam: Selvorganiserende og tverrfaglig team (typisk 3-9 personer) som utfører selve utviklingsarbeidet. Teamet bestemmer selv HVORDAN arbeidet skal gjøres.

Scrum har fire seremonier: Sprint Planning (teamet planlegger hva som skal gjøres i neste sprint basert på produktkøn), Daily Stand-up (daglig statusmote på maks 15 minutter der hvert teammedlem svarer: hva gjorde jeg i går, hva gjør jeg i dag, hva hindrer meg), Sprint Review (demonstrere ferdig arbeid for stakeholders og få tilbakemelding), og Sprint Retrospective (teamet reflekterer over prosessen og identifiserer forbedringer). En sprint varer typisk 2-4 uker og har fast lengde gjennom hele prosjektet.

Scrum-artefakter inkluderer Product Backlog (prioritert liste over all ønskelig funksjonalitet, eid av PO), Sprint Backlog (oppgaver valgt for gjeldende sprint, eid av teamet), og Increment (ferdig, potensiellt leverbar funksjonalitet som oppfyller 'Definition of Done').

Kanban

Kanban er en smidig metode som fokuserer på visualisering av arbeidsflyt gjennom et Kanban-board med kolonner (f.eks. 'A gjøre', 'Under arbeid', 'Kodegjennomgang', 'Testing', 'Ferdig'). I motsetning til Scrum har Kanban ingen faste iterasjoner (sprinter), ingen definerte roller, og ingen forpliktelser til å levere et bestemt omfang i en gitt tidsperiode. I stedet brukes WIP-grenser (Work In Progress) for å begrense antall oppgaver som kan være under arbeid samtidig i hver kolonne. Dette forhindrer flaskehalser og sikrer jevn gjennomstromming.

Forskjeller mellom Scrum og Kanban

Scrum har faste sprinter (2-4 uker), definerte roller (PO, SM, team) og faste seremonier. Kanban har kontinuerlig flyt uten tidsbokser, ingen faste roller og fokuserer på WIP-grenser. Visualisering av progresjon i arbeidsoppgaver er viktig i både Scrum (burndown chart) og Kanban (Kanban-board). På eksamen V2017 ble det testet at visualisering av progresjon er viktig i BÅDE Scrum og Kanban.

Eksempel 1: Daglige stand-up-møter (V2017)

Et utviklingsteam har daglige stand-up-møter kl. 09.00 som ikke fungerer godt. Teamleder, produkteier og andre teammedlemmer vil kutte motene. Potensielle grunner til at stand-up ikke fungerer: motene tar for lang tid (bør være maks 15 min), folk rapporterer tekniske detaljer i stedet for status, noen dominerer samtalen, eller det er for mange deltakere. Fordeler med daglige stand-ups: rask informasjonsdeling, tidlig identifisering av hindringer, synliggjoring av fremdrift, og teamsamhold. Ulemper: kan oppleves som overvaking, tar tid fra utvikling, og kan bli et ritual uten verdi. Alternativ kommunikasjon dersom man kutter motene: asynkron oppdatering via Slack/Teams, møter 2-3 ganger i uken, eller skriftlige statusrapporter i et delt dokument.

Eksempel 2: Retrospektiv (V2017)

Teamet har retrospektiv en gang i maneden, men de samme utfordringene nevnes hver gang. Typer utfordringer teamet kan ha: kommunikasjonsproblemer, teknisk gjeld, uklare krav, for mange avbrytelser, eller manglende testdekning. Problemet er at teamet identifiserer problemer men ikke følger opp med konkrete tiltak. Løsning: bruk 'Start, Stop, Continue'-format for å strukturere diskusjonen, lag konkrete og malbare aksjonstiltak med en navngitt ansvarlig person og en frist, og sjekk status på forrige retrospektivs tiltak i STARTEN av neste retrospektiv. Vurder også å variere formatet (anonym innsamling, dot-voting) for å engasjere hele teamet.

Studieguide: Smidige metoder: Scrum og Kanban