Jeg har efterhånden hørt mange folk bruge ordet agil softwareudvikling som et synonym for løbende afleveringer til kunden – eller i hvert fald nævne løbende afleveringer som det første, når de skal beskrive, hvad agil softwareudvikling går ud på.
Det er selvfølgelig dejlig konkret og nemt at forklare, men der findes mange andre – og ifølge min mening også mere relevante – aspekter af agil softwareudvikling.
Løbende afleveringer til kunden – eller iterativ udvikling – er egentligt ikke noget nyt, men stammer fra Bary Böhms spiralmodel fra 1986, som var en reaktion på den udskældte vandfaldsmodel.
Mens Spiralmodellen prioriterede opgaver ud fra risici, så har agil softwareudvikling fokus på at skabe værdi for kunden.
I praksis er der dog ikke den store forskel, da det med hurtigt at levere værdi til kunden kan afhjælpe en masse risici i et projekt.
Hvis man skal være grov, kan man endda påstå, at den iterative del af agil softwareudvikling bare er et specialtilfælde af Spiralmodellen.
Omvendt er iterativ udvikling nok en nødvendig forudsætning for at være agil. Hvis man læser det agile manifest [agilemanifesto.org], er løbende afleveringer ikke en del af selve manifestet, men bliver refereret i 3-4 af de 12 principper der ligger bag:
“Vores højeste prioritet er at stille kunden tilfreds gennem tidlige og løbende afleveringer af værdifuld software”
Det første princip er et ret vigtigt værktøj for at opretholde den tillid mellem kunde og leverandør, som er central for, at en agil udvikling kan finde sted.
Når kunden løbende får afleveringer, som giver værdi i organisationen, så er kunden også mere tryg ved, at leverandøren lever op til de forventninger, der er, og at de penge, som projektet koster, giver værdi.
For nogle kunder er det grænseoverskridende at give afkald på trygheden ved fastprisprojekter, og det er derfor vigtigt hurtigt at vise, at det var det rigtige valg – både i forhold til metode og leverandør.
“Fungerende software er den primære måde at måle fremdrift på”
Det andet princip handler om at have kontrol med et projekt.
Erfaring har vist, at det at producere features eller værdiskabende funktionalitet ikke bare er en lineær proces, men at den største og sværeste del af det at lave software faktisk er den læringsproces, der foregår – både blandt udviklere og hos kunden.
Mange gange ender man andre steder, end det man oprindelige planlagde – hvilket er en god ting, da kunden sparer omkostningerne ved først at betale for en ubrugelig feature og derefter skal til at betale for den rigtige.
Det er derfor meget svært at forudsige, hvor langt man er i udviklingen, før featuren har givet den ønskede værdi i organisationen.
Dette er grunden til, at den vigtigste indikator, man har i agile projekter, er antallet af features, der er realiseret, i forhold til det forventede totale antal features.
“Løbende levering af velfungerende software, jo hyppigere des bedre”
Jo oftere, man skaber værdi for kunden, og jo mere finkornet et styringsværktøj, man har, jo bedre.
Men der er dog en nedre grænse for, hvornår længden af iterationerne bliver for korte, så man ikke bare afleverer for afleveringens skyld.
For at kunne måle, om en feature har den ønskede værdi, er det nødvendigt at kunne udrulle/implementere den i organisationen.
I nogle situationer kræver det for eksempel undervisning eller certificering af softwaren, som gør det urealistisk at release hver måned, mens andre situationer giver mulighed for at levere nye features dagligt.
Jeg har i hvert fald været på et par militære og sundhedsprojekter, hvor det vist var godt, at der ikke blev udrullet nye features hvert 14. dag.
En anden misforståelse omkring hyppige afleveringer er, at man så bare laver det om til “mini vandfald”, hvor man kun snakker med kunden i starten og slutningen af iterationen.
To uger i en forkert retning er stadig spild af penge, så selv om man har korte iterationer, er det stadig nødvendigt med løbende samarbejde med kunden og brugerne i stedet for trial and error-udvikling.
“Agile processer fremmer bæredygtig udvikling. Systemejere, udviklere og brugere bør til enhver tid kunne opretholde et fast udviklingstempo”
Dette princip ser måske ikke ud til at have noget med iterativ udvikling at gøre, men det er måske det bedste argument for at have korte iterationer.
Der sker oftest det, når man har lange iterationer, at folk får rigtig travlt til sidst og arbejder længe.
I starten af det næste iteration slapper de igen af for så atter at have travlt i slutningen.
Hvis man derimod hele tiden har en aflevering inden for overskuelig fremtid, finder man en mere konstant arbejdsrytme, som muliggør en mere bæredygtig arbejds- og fritidsfordeling.
Som nævnt er agil og iterativ udvikling ikke synonymer, selv om det oftest er de aspekter, man nævner, når agil softwareudvikling skal forklares.
Iterativ udvikling er sandsynligvis en nødvendighed for at være agil, men ikke det fundamentale.
Men hvad er det så, jeg synes, der er adskiller agil softwareudvikling fra de tidligere udviklingsprocesser?
Den forklaring får du i en kommende klumme.
Og kan vi så ikke lige droppe argumentet om, at agil udvikling er en reaktion på vandfaldsmodellen – der har været mange procesmodeller i mellemtiden!
Annonce: