13/08-15   -   Blog

Hvorfor er agil udvikling det oplagte valg til web i dag?

De agile metoder har gennem de senere år gennemgået en forandrings- og tilpasningsproces. Fra at være en række enkeltstående metoder, med hver deres svorne tilhængere, er de nu i højere grad et almindeligt anerkendt sæt af teknikker, værktøjer og praksis, som skal kombineres og tilpasses den enkelte virksomheds produkter og kultur.

Det betyder også, at de fleste, uanset udgangspunkt, kan opnå store fordele i form af bedre styring af projekter og højere kvalitet i slutresultatet. Jeg vil i dette blogindlæg forsøge at kortlægge, hvorfor agil udvikling er det oplagte valg, når du arbejder med softwareudvikling, og hvorfor vi er fortalere for agil udvikling i Adapt.

Hvorfor har I ikke faste priser?
Det er et af de spørgsmål jeg støder på, når jeg møder kunder, som ikke er vant til at arbejde agilt. I Adapt arbejder vi ikke med faste priser, men derimod med estimater. Det er der flere årsager til.

Det er ingen hemmelighed, at udvikling af webløsninger kan være en kompliceret proces. Vi plejer at sige, at vi ofte ved mest om et projekt, når det er slut, og mindst når det begynder. Det kan være svært at forstå for kunden, men det er netop derfor, at vi arbejder agil.

Vi bliver klogere undervejs i processen, efterhånden som vi får mere data og graver dybere ned i selve udviklingsfasen. Det er ofte her, at der kan dukke ny viden op, som vi umuligt kunne have forudset. Derfor undgår vi at holde fast i nogle dårlige beslutninger, som er er taget mens vi havde mindst viden om projektet, men har mulighed for at skifte retning undervejs i samarbejde med kunden.

Hvordan ved vi så hvornår projektet er færdigt?
"Det er svært at spå - især om fremtiden"! Da vi hele tiden skal være i stand til at skifte retning, og vi bliver klogere, kan det naturligvis også betyde, at vi opdager at vores projekter tager længere eller kortere tid end vi havde forventet. Derfor arbejder vi med at estimere vores opgaver ved hjælp af et internationalt anerkendt begreb kaldet Story Points i stedet for timer. Story Points fortæller noget om, hvor komplekse vores opgaver er når vi sammenligner dem.

Lad mig prøve at give et eksempel. Vi har 2 opgaver i et projekt illustreret som to legofigurer (se billede nedenfor). Hvis jeg spørger, hvor lang tid det tager at bygge de to figurer, så vil mange nok have svært ved at give et eksakt estimat -især på modellen til venstre, da den tydeligvis er relativt kompleks.

Men spørger jeg i stedet for hvilken en af disse to LEGO modeller, der ville tage længst tid at bygge, så vil svaret være indlysende. Det er selvfølgelig modellen til venstre. Hvis jeg derefter spørger, hvor meget længere det vil tage at bygge den store Lego figur, sammenlignet med huset til højre, så kan man nogenlunde koge det ned til om det tager x2, x4, x8, x16 eller x32.

Det er umuligt du vil kunne svare bedre på spørgsmålet, når du ikke er nået længere hen i processen med at bygge den, uden at skulle bruge en masse tid på at analysere opgaven. Det vil vi gerne undgå!

Så hellere begynde at bygge huset og se hvor lang tid vi bruger på det, og så har vi en faktor vi kan gange op med for at få en ide om, hvor lang tid den komplekse opgave tager. Og selvom denne faktor vi ganger med er relativt upræcis, så viser det sig, at det udligner sig i projektet når man har mange opgaver. Det betyder, at det forecast vi leverer faktisk rammer ganske godt det antal timer vi behøver.

61 % bliver aldrig brugt
En anden grund til, at vi ikke ønsker at arbejde med gammeldags fast-pris-projekter er, at du signer af på en kontrakt og så bygger det som står i kontrakten - også selv om du undervejs finder ud af, at det er en dårlig ide. Vi arbejder iterativt, og starter altid med at udvikle det, som vi finder frem til skaber mest værdi for din forretning og dine brugere. En undersøgelse fra Standish Group har vist, at hvis der udvikles alle de ting, som virksomhederne beder om i et webprojekt, så bliver 61% af løsningen eller funktionaliteterne slet ikke brugt.

Det er disse 61%, som vi gerne vil undgå at skulle udvikle bare fordi at de står i et scope i en fastpris-kontrakt.

For os handler det om at prioritere værdien for dine brugere vs. kompleksiteten af det du ønsker udviklet. Det er ærgerligt at have brugt oceaner af tid på at udvikle en funktionalitet, som efterfølgende ender med slet ikke at blive brugt. Derfor er den agile udviklingsproces oplagt, fordi vi hele tiden bliver klogere undervejs i processen og får løbende mere viden.

Du er med i hele processen
For at de agile principper kan fungere i praksis er det vigtigt, at der er et tæt samarbejde med os og kunden. Vi er ikke to samarbejdspartnere, men derimod et samlet team. Hele teamet deltager lige fra UX'ere, designere, udviklere og projektledere - og ikke mindst dig som kunde. Det betyder, at du er med under hele processen, og kan også give os besked, hvis vi er på vej i den forkerte retning. Det giver et vigtigt medejerskab på projektet for begge parter, og at vi løfter opgaven i samlet flok.

I den forbindelse arbejder vi med user stories i stedet for blot at løse en kravspecifikation. En user story er kort sagt en ikke-teknisk definering af den funktionalitet, som ønskes løst. Når vi arbejder med user stories er der en klar forståelse af, hvad der bliver lavet. Med en kravspecifikation kan der nemt være forskellige oplevelser af, hvad det er der skal laves.

Eksempel på hvordan vi arbejder med user stories
Hvis en kunde f.eks. ønsker at få udviklet en online lærerportal, hvor et af kravene handler om, at der skal være en tabel over de dårligste elever i klassen. I kravspecifikationen vil der måske stå noget a la dette:

"Der skal være en tabel, der indeholder elevernes navn, elevens sidste karakter og elevens nye karakter. Det skal være muligt at sortere på kolonnen "ny karakter", og elever hvor karakteren ikke er registreret skal markeres med rød".

Når vi arbejder med user stories omskriver vi kundernes krav, så det i stedet kunne lyde således:

"Som lærer skal jeg kunne se en oversigt over elevernes karakterer, så jeg altid har et overblik over, hvilke elever der klarer sig dårligst".

Med ovenstående user story er det langt mere tydeligt, hvad der forventes af opgaven, og den er forståelig for alle. En bruger ønsker at foretage en specifik handling for at opnå et mål. Det er nemlig vigtigt for os at forstå målet, så vi kan gennemskue hvad værdien er for kunden. Det gør det også nemmere at prioritere opgaverne.

Endvidere giver det f.eks. udvikleren mulighed for at tænke frit, og dermed komme med alternative måder at løse opgaven på, og i mange tilfælde løse opgaven både bedre, hurtigere og smartere. I dette tilfælde kunne udvikleren evt. foreslå kunden, om det ikke var bedre med en liste, der altid indeholder en liste over de 5 elever, der klarer sig dårligst.

Tillid, samarbejde, fleksibilitet, tilpasningsevne og gennemsigtighed
Mange svor fortsat til den klassiske vandfaldsmodel, da de fleste godt kan lide en venstre-højre-model, hvor du løbende ser forbedringer. Derudover signalerer en klassisk proces også, at der er styr på projektet, hvilket skaber en vis tryghed og stabilitet ind i en udviklingsfase.

Det kan jeg godt forstå - men det er en falsk tryghed. I virkeligheden kunne jeg godt tænke mig, at det handlede om samarbejde og tillid. Det skal især ses i kontraktens fokus på kunden, hvor det ikke burde handle om benhård økonomi, men derimod om samarbejde og hvad er det for en overordnet opgave vores kunde ønsker at løse med en ny online platform.

Med andre ord er mentaliteten hos mange kunder lige nu defineret ud fra, at alt i kontrakten skal overholdes ned til mindste komma, og hvis det ikke er tilfældet, så anser man meget hurtigt projektet som forfejlet. Men kontrakten er skrevet på det tidspunkt i et projekt, hvor vi ved mindst.

I en agil proces kan succeskriterier stadigvæk være skarpe, men de baserer sig blot mere på hvad det er for en ændring, at brugernes adfærd vi ønsker at opnå, frem for at vi har en lang liste over features, som vi SKAL have med når vi går live.

Et grundlæggende problem ved anvendelsen af den klassiske vandfaldsmodel til udvikling er, at specifikation, design og konstruktion ofte ikke kan besluttes og planlægges på forhånd. Produkt- vision, krav og behov, mål og teknologi kan ændres uforudsigeligt undervejs i udviklingsforløbet når nye idéer opstår, der kommer påvirkninger fra konkurrenter og fra markedet eller der gøres teknologiske opdagelser.

Derfor er vores anbefaling, at hvis du ønsker at opnå succes i en dynamisk verden, skal fokus være på tillid, samarbejde, fleksibilitet og ikke mindst tilpasningsevne, snarere end den intense up front planlægning, der er karakteristisk for klassisk vandfaldsudvikling.