BLOG
SOFTWARETEST

Blog: Den agile bageform og de formelle kontraktformer

Så blev det tid til næste kapitel om den agile bageform - set med testerens briller.

[13. april 2016] Ofte hører jeg kommentarer som "vi kan ikke lave agil udvikling, for vi har den her store K02 kontrakt vi skal følge, så vi er nødt til at køre rent vandfald". Det er da også rigtigt, at f.eks K02 lægger op til at gennemføre projekter efter vandfaldsmodellen snarere end en agil udviklingsmodel, og det er da også en af grundene til, at man har defineret K03 kontrakten, der skal benyttes til agile udviklingsprojekter. K03 har jeg dog endnu ikke haft praktisk erfaring med, men du kan finde artikler med gennemgang af kontrakten hos blandt andet Version2. Selvom man sidder i en kontekst, med standardkontrakter der lægger op til vandfaldsudvikling, er det ikke helt umuligt at gennemføre et projekt med fokus på en række af de agile principper. Og det er dette fokus dagens blogpost vil have. Der er altså ikke tale om det man måske vil kalde en "ren agil udvikling", men en udvikling der fokuserer på at inddrage de agile principper der er praktisk mulige.

For et par år siden stødte jeg for første gang ind i udtrykket Water-SCRUM-fall, og syntes egentlig det var en meget god måde at illustrere en af de løsninger man kan have, i forhold til disse formelle kontrakter. Projektet vil starte som vandfald: Man har formel kontraktindgåelse med defineret krav specifikation og diverse bilag omkring projektet, blandt andet tidsplaner, prøvebilag m.v. 

Efter kontraktens indgåelse skal systemet udvikles, og det er her I med fordel kan vende fokus mod en mere iterativ/inkrementel udvikling (f.eks agile), og lave udviklingen baseret på de agile principper, som korte feedback loops, kontinuerlig fokus på test og løbende feedback på det udviklede fra forretningen. Såfremt I har valgt en tilgang med delleverancer. F.eks hver 3.måned vil I inde i inkrementet have brudt opgaven ned og defineret produktbacklog, I har gennemført inkrementet som en række sprints, hvert startende med sprintplanning og afsluttet med sprintreview og retrospektiv - og med fokus på potentielt driftklar kvalitet.

Når inkrementet nærmer sig sin afslutning, hopper I tilbage i vandfaldsmodellen igen, idet kontrakten som oftest vil have en række testfaser/afprøvningsforløb defineret, der skal gennemføres med kunden som en del af afleveringsforretningen. Her flyttes fokus til accept af det samlede system (eller den del I har lavet i inkrementet) og den efterfølgende idriftssættelse.

Så hvorfor lave den der SCRUM del i midten, i stedet for at køre en ren vandfaldstilgang til projektet? Set med mine øjne er der et par helt klare fordele ved at dele projektet op i mindre portioner i form af sprints:

  • Følelse af fremdrift. Når vi hele tiden har fokus på at løse den aftalte opgave indenfor 2-4 uger, er der en klar følelse af fremdrift. Hver dag når vi står ved taskboardet og giver status, får man fornemmelsen af hvad der er fokus på, og hvad vi løber efter.
  • Løbende test. I stedet for kun at have formelle testfaser i slutningen af projektet, har vi nu fokus på at få testet hver enkelt opgave i backloggen, efterhånden som den bliver udviklet - det er en del af definition of done.
  • Sikring af kundefokus. Da vi ved afslutningen af hvert sprint demonstrerer resultatet af sprintet, har vi mulighed for at få løbende feedback fra kunden. Er vi på rette vej? Dette afhænger naturligvis af kundens villighed til at deltage.
  • Løbende integration. I stedet for big-bang integration af software fra flere teams til sidst, har vi løbende integration og kan løbende sikre, at kodebasen ikke kompromitteres.

Her er det vigtigt at teamet husker, at fokus ikke kun er på test af de individuelle user stories. Man skal have sikret at den nødvendige testdokumentation er til rådighed for testfaserne; testplaner, testspecifikationer og testcases. I løbet af sprintet har du måske testet exploratory på de enkelte user stories, og der er lavet automatiske tests til din regressionstest. Men du skal sideløbende sikre, at der bliver udviklet de nødvendige accepttestspecifikationer der skal benyttes ved afleveringsforretningen. Denne opgave løber altså parallel med testen, der foregår som en integreret del af udviklingen i sprintet. 

Konceptet kan naturligvis også gennemføres selvom leverancen ikke er delt op i mindre delleverancer - altså kun har den komplette leverance til kunden til sidst - men det stiller krav til kunden om at være mere involveret, og lave uformelle "godkendelser" af funktionalitet løbende for at sikre, at man er på sporet og dermed kan rette til løbende, fremfor at gemme dette til sidst. 

Så det er ikke umuligt at implementere agile principper selvom man skal operere indenfor rammerne af en formel kontrakt som f.eks K02, men det skal sikres at man supplerer med de aktiviteter der er nødvendige, for at gennemføre de formelle afleveringsforretninger. 

Gitte Ottosen
Gitte Ottosen
Managing Consultant
+45 39778711
todo todo