Løbende udvikling med agil softwareudvikling

Agil udvikling softwareBegrebet agil softwareudvikling er efterhånden på manges læber. Ofte forbindes det med, at der foretages afleveringer til en kunde løbende. Det er i hver fald tit det første som agil softwareudvikling kobles til, når folk skal forklare, hvad det er. Det er måske, fordi det umiddelbart er en konkret ting at nævne. Der er også mange andre aspekter indenfor agil softwareudvikling, som det kunne være relevant at nævne, men i denne artikel dykker vi lidt ned i fænomenet om de løbende afleveringer.

Løbende afleveringer også kaldet iterativ udvikling er ikke et nyt fænomen. Det stammer fra en model udviklet af Bary Böhms i 1986. Den kaldes spiralmodellen og var et alternativ til den efterhånden upopulære vandfaldsmodel. Formålet med spiralmodellen var at prioritere opgaver i forhold til risici. Formålet med agil softwareudvikling er en værdiskabelse for kunden. Der er dog ikke den store forskel på de to modeller i praksis. Leverer man hurtigt værdi til en kunde kan en god del risici afhjælpes i det igangværende projekt.

Den iterative udvikling er nu nok en uundværlig del af det at være agil, og selvom de løbende afleveringer ikke er en del af selve det manifest, der er beskrevet på agil softwareudviklingemanifesto.org så nævnes det ofte i de 12 principper, der er en del af manifestet. Herunder gennemgås nogle af principperne.

Første princip handler om at tilgodese kundens behov ved både tidlige afleveringer og løbende afleveringer af software. Det er et væsentligt aspekt for at vedligeholde tilliden mellem kunden og leverandøren. Tilliden er nemlig central for den agile udviklingsproces. Får en kunde løbende afleveringer, som han eller hun kan se skaber værdi i virksomheden, giver det en tryg forvisning om, at leverandøren er dygtig, og at pengene er godt givet ud. Nogle kunder kan have det svært med at undvære trygheden ved projekter med en fastsat pris. Det gør det ekstra vigtigt for leverandøren at vise kunden, at han eller hun traf det mest fordelagtige valg både af leverandør og metode.

Princip nr. to siger, at den bedste måde til fremdriftsmåling er software, der fungerer. Princippet handler om det at have kontrollen med projektet. Erfaringsmæssigt ved man, at processen med at skabe features mm. ikke er lineær. Den mest omfattende og krævende del af softwareudvikling er faktisk den læringsproces, som pågår hos udviklerne og ikke mindst hos kunden. Ofte ender processen et helt andet sted end oprindelig planlagt. Det er absolut godt, for det sparer kunden for de omkostninger, der er forbundet med først at skulle betale for en feature, der ikke kan bruges ,og derefter betale for en der kan.

Men det gør det svært at sige, hvor i udviklingsprocessen man er, før featuren skaber værdi hos kundens organisation. Indikatoren i agile projekter er derfor udelukkende det realiserede antal features hold op imod de antal features, der totalt forventes.
Et tredje princip handler om, at jo hyppigere der leveres velfungerende software jo bedre. Men der er imidlertid en grænse for hvor hyppige leveringerne skal være. Bliver længden af iterationerne for kort, kan det virke som om, man afleverer for afleveringens skyld alene.

Man kan kun måle effekten og værdien af en feature, hvis den implementeres i organisationen. Til tider kan softwaren dog kræve certificering eller undervisning som gør, at det ikke er muligt at få den ud med korte intervaller. I andre tilfælde vil det ikke være et problem med daglige leveringer.

En misforståelse i forhold til den hyppige afleveringsmetodik er påstanden om, at afleveringerne bliver til ”mini vandfald”, der resulterer i, at man kun taler med kunden ved iterationens starttidspunktet og sluttidspunkt. Det dur dog ikke for det er stadig pengespild, hvis processen kører i en dårlig retning i et par uger. Så uanset hvor korte iterationer, skal man løbende have dialog med kunde og brugere.