JAOO, Århus: "Tro ikke på dem, der siger, at det er nemt at anvende agile metoder."
Ordene kommer fra Henrik Kniberg, der beskriver sig selv som Agile coach og Javamand.
Det er efterhånden 7½ år siden at det agile manifest blev skrevet. Siden da har de agile tanker spredt sig og en række store virksomheder anvender udviklingsmetoder som Scrum, XP og andre der alle er baseret på den agile tankegang.
Det simple er svært
Principperne bag den agile tankegang er simple og enkle.
Det gælder om at levere kode, der lever op til forretningens behov. Koden skal udvikles i samarbejde med forretningen i små iterative udviklingsforløb, så ændringer i behov hurtigt opsamles og udviklingsplanen løbende kan ændres.
Det lyder simpelt, men det kan være svært at leve op til i praksis.
Ikke mindst fordi udviklere stadig er vant til at tænke i den traditionelle vandfaldsmodel.
Et tankesæt der betyder, at agile metoder stadig mødes med mange indvendinger, når man går igang med et agilt udviklingsprojekt.
Selvom det kan være besværligt, så anbefaler Henrik Kniberg på det kraftigste udviklere til at gå igang med de agile metoder.
Pessimisten og optimisten
I sin præsentation "What's hard about being an agile developer" på JAOO-konferencen gennemgik
Henrik Kniberg en række typiske indvendinger mod agile teknikker og gav eksempler på, hvordan de kan imødegås.
Et vigtigt element i et agilt projekt er retrospectives. Her evaluerer man løbende projektet og opsamler gode såvel som dårlige erfaringer med henblik på at gøre projektarbejdet bedre.
Pessimisten vil typisk sige, at den slags tager tid; tid der betyder, at man ikke kan kode.
Optimisten ser det som en mulighed for hele tiden at optimere udviklingsarbejdet og derved minimere spildtid.
Kontinuerlig kunde-feedback
En andet vigtigt element i agil udvikling er et tæt samarbejde med kunden.
For at undgå at et system ikke lever op til en kundes forventninger og behov, skal resultatet - kørende kode, ikke designdokumenter og lignende - af hver enkelt af de små korte udviklingsforløb præsenteres for kunden.
Her vil pessimisten indvende, at det tager tid med al den demonstration af delfunktionalitet og samtale med kunden. Tid der betyder, at man ikke kan kode.
Den optimistiske ser dog demoerne som en mulighed for at vise sit arbejde til nogle, der giver kvalificeret sparring og sammen kan udvikleren og kunden nå frem til det system, som kunden ønsker.
Så tag dog og bestem dig!
Et resultat af de mange demoer og samtaler med kunden er, at kravene til systemet løbende vil ændre sig. Derfor skal man være indstillet på løbende at ændre plan.
Her vil pessimisten brokke sig over, at kunden ikke kan bestemme sig, og at en detaljeret specifikation fra starten er bedre. De mange ændringer tager tid væk fra kodningen.
Optimisten ser derimod fremgangsmåden som den bedste for at ramme det som kunden ønsker: Et system, der opfylder kundens behov.
Henrik Kniberg sammenligner den traditionelle udviklingsproces, hvor man ufravigeligt følger en stor kravspecifikation fra start til slut ved kodningen af et system som at forsøge at ramme et bevægeligt mål med en kanonkugle.
I modsætning til det, så er en agil udviklingsproces mere som et målsøgende missil.
Vi har ikke tid til møder, vi skal kode
Der er en del møder i den agile udviklingsproces, hvilket kan frustrere udviklere.
"Møder er kedelige" og "vi skulle kode i stedet for" er nogle af de negative holdninger.
Modargumenterne til det er, at møder kun er kedelige, hvis de er ineffektive og at man ikke behøver en masse kode, men den rigtige kode. Møderne er med til at sikre, at man kun laver den nødvendige kode.
Ifølge Henrik Kniberg vil møderne typisk tage 5-10 procent af tiden, hvilket giver masser af tid til kodning.
Fokus på ren og simpel kode
I agil udvikling er det koden, der tæller. Man kan have nok så mange velskrevne analyse og design-dokumenter; hvis ikke koden er velfungerende, så har man fejlet.
Et mål for agil udvikling er simpel og "ren" kode. Det betyder, at koden ikke alene skal kunne bestå unit-test og andre test. Koden skal være nem at forstå, der må ikke være dubletter af koden og minimal kode er ønskværdigt.
Det betyder, at man jævnligt skal rydde op i koden, for at undgå at den bliver kompleks og uforståelig. Her er refaktorering et vigtigt element i den agile udvikling.
Pessisimisten vil typisk mene, at der ikke er tid til at holde koden ren. Modargumentet er, at ren kode er enkelt at holde ren og vedligeholde, hvorimod komplekse og uforståelige programmer er et helvede at vedligeholde.
"If it ain't broken, don't fix it" er et andet argument for ikke at refaktorere kode. Risikoen for at introducere fejl er for stor, lyder det fra pessimisten.
Her er modargumentet at automatiserede test som unit-test er med til at sikre, at refaktorering ikke introducerer fejl.
Endelig er der den opgivende holdning:"Det nytter ikke, hele kodebasen er noget lort alligevel."
Her er det ekstremt vigtigt at der ryddes op, da det øjensynligt står meget slemt til med koden.
Det kan gøre ondt, men vær ærlig
Henrik Kniberg oplevede at blive kaldt ind på et projekt, der var i vanskeligheder.
Projektet var et big-bang projekt, der havde deadline lurende et par måneder fremme.
Reelt havde projektet ingen ide om, hvor langt man var fra målet. Udviklerne betragtede deres opgaver som værende færdige, når de mente, at koden var færdigudviklet og koden checket ind i repositoriet.
Der var ingen test som integrationstest eller feedback fra kunden.
Ved at etablere en backlog over udeståender og ved at begynde at måle på den egentlige fremdrift i projektet, viste det sig, at systemet først kunne være færdig et år senere.
"Det er vigtigt at bevare tilliden i krisesituationer og det opnås bedst ved at være ærlig. De dårlige nyheder skal hellere fortælles tidligt frem for sent i forløbet," mener Henrik Kniberg.
Ved at ændre på planen, skære i scope og indføre trinvise releases af systemet, blev det samlede system leveret med 5 måneders forsinkelser i stedet for et helt år.
Det var en hård proces, men det var det værd i sidste ende.
