Agil udvikling vs vandfald: hvad passer til dit projekt?

Agil udvikling vs vandfald er i virkeligheden et spørgsmål om hvornår du beslutter hvad der skal bygges. I vandfaldsmodellen ligger alt fast før den første linje kode bliver skrevet, mens agil udvikling bygger i korte runder og justerer planen undervejs. Til de fleste mindre webprojekter er det ærlige svar ingen af delene i ren form, men en fast ramme for pris og omfang med agil udførelse inden for rammen.

Jeg starter selv større opgaver med et betalt forprojekt til fast pris, så jeg er ikke helt neutral. Derfor har jeg også skrevet ærligt om hvornår den model ikke passer.

Den korte version

Min tommelfingerregel: Kan du beskrive det færdige resultat præcist i dag, og vil beskrivelsen stadig holde om tre måneder, så kan vandfald fungere. Er du i tvivl om bare én af delene, så byg i korte runder. De fleste mindre projekter lander et sted midt imellem, og det vender jeg tilbage til længere nede.

Vil du se hvor valget af arbejdsform passer ind i hele forløbet, så har jeg skrevet en guide til softwareudvikling fra idé til drift.

Hvad er vandfaldsmodellen?

Vandfaldsmodellen er den klassiske måde at styre et udviklingsprojekt på: én fase ad gangen, og hver fase skal være færdig før den næste begynder. Først afdækkes kravene, så designes løsningen, så kodes den, så testes den, og til sidst sættes den i drift. Arbejdet løber nedad som et vandfald, deraf navnet.

Modellen bliver ofte sporet tilbage til en artikel af Winston Royce fra 1970. Det pudsige er at Royce selv kaldte den rene, trinvise udgave risikabel, fordi test først sker til sidst, og ordet vandfald brugte han slet ikke. Wikipedia har en fin gennemgang af modellens historie. Alligevel blev den standard i store it-projekter i årtier.

Vandfald har styrker som tilhængere af agil udvikling tit overser:

• Du kender prisen og leveringsdatoen før du skriver under.
• Alle har læst og godkendt det samme dokument, så der er mindre plads til uenighed om hvad der er aftalt.
• Den passer til organisationer hvor budgetter skal godkendes på forhånd, og hvor en ændring kræver en ny beslutning højere oppe.

Prisen for den tryghed er at alle beslutninger bliver truffet på det tidspunkt hvor du ved mindst. Du skal gætte på hvordan brugerne vil bruge systemet, før nogen har prøvet det. Gætter du forkert, opdager du det først når budgettet er brugt. Skal du i gang med en grundig beskrivelse, så se min guide til at skrive en kravspecifikation.

Hvad er agil udvikling?

Agil udvikling er en samlebetegnelse for metoder hvor du bygger i korte runder, viser resultatet og retter planen til ud fra det du har lært. Udtrykket stammer fra Agile Manifesto fra 2001, hvor en gruppe udviklere blandt andet skrev at de vægter fungerende software højere end omfattende dokumentation, og at reagere på forandring højere end at følge en plan.

Den mest kendte metode er Scrum. Ifølge Scrum Guide arbejder teamet i sprints (faste arbejdsrunder) på en måned eller mindre, og én person, produktejeren, bestemmer rækkefølgen i den prioriterede liste. I mindre projekter er det ofte dig der har den rolle, også selvom ingen kalder dig produktejer.

En runde ser typisk sådan ud:

1. Du og udvikleren vælger de vigtigste opgaver fra toppen af listen.
2. Udvikleren bygger dem færdige, inklusive test.
3. Du ser og prøver resultatet på en testserver.
4. I retter listen til ud fra det du har set, og næste runde starter.

Opgaverne bliver ofte beskrevet som user stories: korte beskrivelser af hvad en bruger skal kunne, og hvorfor. Jeg har skrevet om hvordan du skriver user stories som udvikleren forstår.

Agil betyder ikke at der ikke er en plan. Det betyder at planen bliver opdateret når du ved mere. Et projekt uden mål, budget og prioriteret liste er ikke agilt. Det er bare ustyret.

Fast ramme og agil udførelse: det der virker i mindre projekter

De fleste der køber software, vil have to ting som lyder modstridende: en fast pris og muligheden for at skifte mening undervejs. Det kan godt lade sig gøre, hvis du skelner mellem rammen og indholdet.

Rammen ligger fast. Budget, deadline, målet med projektet og de få funktioner der skal være med før systemet kan bruges. Det er vandfaldsdelen, og den bliver aftalt før der kodes.

Indholdet er fleksibelt. Alt det andet står i en prioriteret liste. Udvikleren bygger fra toppen, du ser resultatet løbende, og når du får en ny idé, bytter du den ind i stedet for noget af samme størrelse. Bliver der for lidt plads, er det bunden af listen der ryger, ikke kvaliteten eller deadlinen.

Aftalen er enkel: Du kan ikke få mere for samme pris, men du kan få noget andet. Det er bedre end vandfaldets tillægstilbud, hvor hver ændring bliver en forhandling, og bedre end ren timepris, hvor du først kender regningen til sidst. Forskellen på de to prismodeller har jeg skrevet mere om i fast pris eller timepris.

Modellen kræver et godt udgangspunkt, ellers bliver rammen et gæt. Derfor starter jeg større opgaver med et betalt forprojekt til fast pris, hvor målet, de vigtigste funktioner og den tekniske retning bliver afklaret, før der bliver sat en pris på resten.

Hvornår hver model ikke passer

Den blandede model passer ikke til alt, og de to rene modeller har hver deres faldgruber. Her er de situationer hvor de typisk koster dig penge.

Hvornår vandfald ikke passer

• Når du bygger noget nyt som brugerne ikke har prøvet før. En MVP (første, enkle version af et produkt) er et eksperiment, og et eksperiment kan ikke specificeres færdigt på forhånd.
• Når forretningen eller markedet ændrer sig hurtigere end projektet varer.
• Når du har svært ved at læse en kravspecifikation og se for dig hvordan systemet bliver at bruge. Mange godkender et dokument og bliver overraskede når de ser skærmbillederne.
• Når en fuld specifikation koster en stor del af det budget der skulle bruges på at bygge.

Hvornår agil ikke passer

• Når budgettet er låst, og du skal vide præcis hvad du får for pengene. Ren agil på timepris giver dig ikke det svar.
• Når du ikke har tid til at være med. Agil kræver at nogen hos dig ser resultatet, svarer på spørgsmål og prioriterer, typisk et par timer om ugen. Uden det sidder udvikleren og gætter.
• Når kravene faktisk ligger fast, fx en integration til et kendt API, en eksport i et format som en myndighed bestemmer, eller en opgave der er beskrevet i detaljer i et udbud. Så giver korte runder mest ekstra møder.

Hvornår den blandede model ikke passer

• Når opgaven er lille, fx et par dages arbejde. Så er et forprojekt og en prioriteret liste mere administration end opgaven fortjener. Bed i stedet om en fast pris på en kort, skriftlig beskrivelse.
• Når det der skal med før lancering, alene koster mere end budgettet. Det løser ingen arbejdsform. Skær ned i den liste, eller hæv budgettet, før der bliver skrevet kode.

Sådan aftaler du en fast ramme med agil udførelse

Arbejdsformen står og falder med aftalen. Sådan vil jeg anbefale at du sætter den op:

1. Skriv målet i én sætning. Hvad skal være anderledes når systemet er i drift? "Kunderne kan selv booke og betale" er et mål. "En ny platform" er ikke.
2. Del funktionerne i tre bunker: skal med før lancering, bør med, og kan vente. Vær hård ved den første bunke, for det er den der bestemmer prisen.
3. Aftal rammen skriftligt: budget, deadline, indholdet af den første bunke, og hvordan ændringer bliver håndteret. Min tommelfingerregel er at holde 15-20 % af budgettet fri til det du først opdager undervejs.
4. Aftal en fast rytme for demoer, fx hver eller hver anden uge, hvor du selv prøver det der er bygget.
5. Byt i stedet for at tilføje. Kommer der en ny idé ind, ryger noget af samme størrelse ud eller over på listen til næste version.
6. Kræv at hver runde efterlader noget der virker og er testet, så du kan stoppe projektet uden at stå med en halvfærdig bunke kode. Det kræver blandt andet automatiserede tests, som også betaler sig i små projekter.

Næste skridt

Start med at svare ærligt på to spørgsmål: Hvor sikker er du på hvad der skal bygges? Og hvor meget tid har du til at være med undervejs? Er svarene "meget sikker" og "næsten ingen", så er en klassisk fast pris på en grundig specifikation det rigtige valg. I næsten alle andre tilfælde vil jeg anbefale en fast ramme med en prioriteret liste.

Du kan se hvordan jeg prissætter opgaver på min side med priser. Har du allerede et oplæg eller en kravspecifikation, så send den gerne med når du skriver.

Ofte stillede spørgsmål

Er Scrum og agil udvikling det samme?+

Nej. Agil er en samlebetegnelse for en måde at gribe udvikling an på, mens Scrum er én konkret metode med faste roller, sprints og møder. Kanban er en anden udbredt metode, hvor opgaver bliver trukket én ad gangen fra en tavle uden faste runder. I mindre projekter bruger man ofte en let udgave: korte runder, en prioriteret liste og jævnlige demoer, uden alle Scrums møder.

Hvor lange skal runderne være i et lille projekt?+

En til to uger er et godt udgangspunkt i mindre projekter. Scrum Guide siger en måned eller mindre, men med lange runder går der for lang tid før du ser noget og kan rette kursen. Er runderne for korte, går en for stor del af tiden med planlægning og demoer i forhold til det der bliver bygget.

Skal jeg have en kravspecifikation til et agilt projekt?+

Ja, men en kortere en. Du skal stadig beskrive målet, brugerne, de vigtigste funktioner og eventuelle krav til integrationer, sikkerhed og data. Det du kan springe over, er detaljerede beskrivelser af hver skærm og hver regel. Dem er det billigere at finde ud af undervejs, når du kan se og prøve systemet.

Hvad sker der hvis budgettet slipper op før alt er bygget?+

Med en fast ramme og en prioriteret liste står du med et system der virker og har de vigtigste funktioner. Det der mangler, er bunden af listen, og den kan du tage stilling til senere: som en ny fase, som løbende udvikling eller slet ikke. I et rent vandfaldsprojekt kan du derimod stå med noget der er næsten færdigt, men ikke kan bruges.