Hvad er agil softwareudvikling?

Centic fortæller om agil udvikling

Hvad er agil softwareudvikling, og hvad betyder det for mig som kunde?

Når Centic udvikler softwareløsninger til – og i samarbejde med – vores kunder, så foregår det inden for det mindset eller paradigme, der hedder agil udvikling.

 

Og hvad er så det?

 

Mange tekster om agil softwareudvikling er fyldt med indforstået fagsprog og er svære at forstå for de fleste, men vi tager her handsken op og prøver at beskrive det, så man ikke behøver en mellemlang IT-uddannelse for at forstå, hvad det handler om.

 

Udvikling af software førhen

Agil udvikling opstod for nogle årtier siden som en reaktion på den dengang fremherskende tilgang, der typisk er kendt som vandfaldsmodellen.

I vandfaldsmodellen kommer projektets aktiviteter efter hinanden, hvor en fase gøres færdig og afløses af den næste:

 

  • Analyse
  • Beskrivelse
  • Estimering
  • Implementering (programmeringen)
  • Test
  • Ibrugtagning

Denne trinvise tilgang har softwarebranchen formentlig overtaget fra andre ingeniørfag, hvor man har arbejdet med konstruktion af fysiske elementer, som skal færdiggøres, før de kan testes i reel brug – som i det helt klassiske eksempel med bygningen af en bro.

 

Men det var i gamle dage. I dag benytter udviklingshuse agil udvikling for at sikre bedre leverancer.

“De seneste årtier er der sket en stor ændring, fra at software var noget, som kun blev brugt af specialister, til noget der nu bruges af os alle sammen hver dag.”

Software skal testes løbende, mens det udvikles

De seneste årtier er der sket en stor ændring, fra at software var noget, som kun blev brugt af specialister, til noget der nu bruges af os alle sammen hver dag. Når løsningerne i overvejende grad skal bruges af mennesker uden teknisk baggrund, bliver det meget afgørende, at det fungerer for dem, og ikke kun for de specialister, der har bygget det.

 

Derfor er det vigtigt, at software bygges, så det stemmer overens med den reelle brugers behov og kompetencer, og i modsætning til en bro, så har software den fordel, at det kan brugertestes i dele. I stedet for at bygge den færdige løsning fra start af, kan man med fordel begynde at fremvise løsningen til brugerne, allerede når man har bygget første del.

 

Den store fordel ved at gøre dette er, at det er meget billigere og nemmere at rette et problem, kort tid efter at det er opstået end at rette det senere, når der er bygget andre funktioner ovenpå. Hvis man undlader at teste undervejs, er det ikke ualmindeligt, at det senere kan være svært at ændre løsningen nok til at gøre den optimal.

 

Agil softwareudvikling betyder derfor først og fremmest, at dem der udvikler løsningerne, afleverer det til test hos dem, der reelt skal bruge det, og at rettelser udføres umiddelbart efter opdagelsen af, at der er truffet en forkert beslutning.

Erfaren IT-projektleder

Agile softwareprojekter

Og hvordan foregår det så i praksis? Lad os sige, at der skal udvikles et logistiksystem.

 

Der er selvfølgelig en liste af overordnede krav (såkaldte epics) omkring alle de ting, det nye system skal gøre nemmere i virksomheden, og for hver epic har man også en liste af ting, som løsningen skal gøre for brugeren. Såkaldte user stories.

 

Eksempelvis kunne man have en epic, der handler om, at systemet skal kunne håndtere lokationer. User stories for denne epic kunne så være: 

 

  • Oprettelse af lokation
  • Redigering og sletning af lokation
  • Visning af lokationer på en liste
  • Sortering af listen med lokationer

Når man så har defineret opgaven ud fra epics og user stories, skal man ikke begynde at tage stilling til detaljerne  så skal man i gang med at kode. Detaljerne skal besluttes af dem, der skal bruge softwaren, hvilket sker undervejs i processen baseret på test af softwareløsningen.

 

Så fremgangsmåden er, at man bygger en lille del og viser den til brugerne – efterfulgt af den næste del. På et tidspunkt kommer man så til, at delen med lokationer skal laves, og når man når dertil, er de andre dele, som skal virke sammen med lokationer, allerede bygget, og man kan nemt lave den nye funktion på en hensigtsmæssig måde.

 

Unødvendige features

En anden fordel ved at bygge løsningen agilt – med trinvis levering og test hos brugerne – er at man kun laver de funktioner, man har brug for, og ikke ender med en masse funktionalitet, som aldrig bliver brugt.

 

Hvis man lægger ud med en omfattende kravspecifikation, vil det være svært for den, der skriver specifikationen – en IT-person og ikke en bruger – at finde ud af, hvad der er nødvendigt og hvad der ikke er. Det undgår man ved at have brugerne med til at definere detaljerne i funktionaliteten undervejs.

“Al erfaring viser, at den agile tilgang til at udvikle softwareløsninger er billigere, mens en fast pris alt for ofte resulterer i dårligere kvalitet, langsommere levering og masser af ekstraregninger.”

Agil udvikling og budgetter

Når en virksomhed skal investere – i en maskine eller et stykke software – vil man selvfølgelig gerne kende den forventede omkostning. Men det betyder ikke, at man skal have det som den primære prioritet at få en fast pris på opgaven.

 

For med fast pris træder man ind i samme logik som den gamle måde at gøre tingene på – hvilket er noget bøvl for alle parter. En fast pris resulterer alt for ofte i dårligere kvalitet, langsommere levering og masser af ekstraregninger.

 

Al erfaring viser, at den agile tilgang til at udvikle softwareløsninger er billigere. Man skal naturligvis stadig styre projektets økonomi og sørge for at skabe sig et overblik over omkostningerne, inden man indtræder i projektet. Men det skal gøres på en anden måde.

 

Det har vi skrevet et separat blogindlæg om. Læs her om budgetstyring i agile udviklingsprojekter.