Denne artikel stammer fra det trykte Computerworlds arkiv. Artiklen blev publiceret den CTO d. 4. november 2005.
SAS Institutes danske udviklingsafdeling anvender den agile udviklingsmetode med succes.
Det var en venlig e-mail, som dumpede ind i denne journalists indboks for et par uger siden. Venlig, men dog med et klart budskab:
- Agile udviklingsmetoder er ikke ustrukturerede.
Vor læser havde kastet sig over tastaturet som reaktion på en artikel i Computerworld den 7. oktober, hvor agile udviklingsmetoder blev opstillet som en modsætning til softwarefabrikker.
- Det er ofte, man ser RUP (Rational Unified Process, red.) og agile metoder opstillet som modsætninger. Den traditionelle softwareudvikling bliver præsenteret som veldisciplineret og velordnet, mens agile metoder præsenteres som tilfældig og ustruktureret. Det er ikke tilfældet, forklarer Bent Jensen.
Han er senior software manager hos SAS Institute og chef for en dansk gruppe på 20 personer, der udvikler komponenter til SAS Web Report Studio. SAS Web Report Studio er en videreudvikling af produktet SAS Enterprise Reporter, der begyndte sin udvikling for 10 år siden i Danmark. Da produktet blev et strategisk produkt for SAS Institute, ændrede man produktet til at være webbaseret (deraf navnet SAS Web Report Studio), udviklingsorganisationen blev større, og den danske udviklingsorganisation blev underleverandør til en amerikansk udviklingsorganisation.
I forbindelse med at udviklingsorganisationen blev ændret, skulle danskerne finde en udviklingmetode, som man ville anvende fremover.
- Her kom vi til at stå i et vadested. Hidtil havde vi anvendt en ad hoc-udviklingsmetode, hvor designbeslutninger blev truffet i en lille udviklingsgruppe, der kunne diskutere tingene over et whiteboard. Med en udviklingsorganisation, der voksede og samtidig kom til at bestå af geografisk adskilte enheder, var det nødvendigt med en mere formaliseret udviklingsmodel, siger Bent Jensen.
Spørgsmålet var, om udviklingsorganisationen skulle basere sig på en formel faseopdelt udviklingsmodel, med udarbejdelse af megen systemspecifikation og formelle designdokumenter - eller en mere agil udviklingsmodel med iterative processer. Valget faldt på en agil udviklingsmodel, der består af teknikker fra Extreme Programming og scrum.
- Når vi starter et nyt projekt, starter vi med et møde, hvor de overordnede krav til funktionaliteten fastlægges. Det er amerikanerne, der ejer brugergrænsefladen, og det er dem der bestiller den underliggende funktionalitet hos os, forklarer Bent Jensen.
Amerikanerne sidder fysisk sammen med danskerne ved det første møde.
Derefter går danskerne i gang med at designe et første udkast til funktionaliteten. Eventuelle uklarheder ordnes via telefon, e-mail, instant messaging eller videomøder. Udviklerne begynder hurtigt at udvikle funktionaliteten. Udviklingen følger principperne fra scrum.
- Vi holder daglige møder, hvor udviklerne fortæller, hvad de har lavet siden sidst, hvad de skal i gang med, og hvorvidt der er nogle forhindringer i vejen for dem, siger Bent Jensen.
Selve udviklingen er test-drevet, hvor der laves unit-test af de enkelte kodestumper. Laves der ændringer til koden, eksekveres unit-tests igen. Udviklingen foregår i Java i udviklingsmiljøet Eclipse, hvor unit-testværktøjet Junit anvendes.
Når første version er færdig, afprøver amerikanerne den udviklede funktionalitet. Hvis der er ting, der skal ændres, laves en ny iteration af udviklingsprocessen.
- Det gælder om at bryde tingene ned, så der er noget demonstrerbart efter en måned. Det er vigtigt, at kunden kan se, om han får, hvad han ønsker, siger Bent Jensen og fortsætter:
- Ved planlægningen af udviklingsarbejdet til en ny release anvender vi et princip fra scrum. Vi har en lang liste af ønsket funktionalitet, en backlog af funktionalitet. På et dagsmøde gennemgår vi listen, forklarer Bent Jensen.
Udviklingsarbejdet er såkaldt timeboxed, det vil sige, at der er afsat en afgrænset tidsperiode til udviklingen af den nye release.
- Vi har måske seks måneder til næste release. Vi laver så ‘guesstimater' på, hvor lang tid de enkelte funktioner tager at udvikle. Vi planlægger udviklingsarbejdet med iterationer. Eksempelvis kan vi planlægge, at Funktion A udvikles i måned et, Funktion B udvikles i måned to og så videre. Hvis kunden efter første interation i måned et finder ud af, at der er behov for ændringer til funktionaliteten i funktion A, vil ændringerne implementeres i næste iteration; måned to. Funktion A ændres så, samtidig med at funktion B udvikles, forklarer Bent Jensen.
Opdelingen af udviklingsprocessen i små, overskuelige bidder, gør det nemt at lave løbende opfølgning på planen.
- Ved mere traditionelle udviklingsprocesser finder man først ud af til allersidst - måske i den sidste måned eller de sidste 14 dage, om man overholder tidsplanen, fordi der er så mange ubekendte. Det kan medføre stort overløb af planen. Med de agile metoder er der mulighed for at styre undervejs. Man kan meget tidligt i det samlede projektforløb se, om estimaterne holder. Det giver mulighed for replanlægning, siger Bent Jensen. Han understreger dog, at med de små overskuelige udviklingsbidder, holder estimaterne som regel.
- Selvom det er meget løse estimater, viser vores erfaring, at estimaterne er lige så gode som de estimater, der laves, hvis man bruger to måneder på en detaljeret planlægning og afklaring af krav, siger Bent Jensen.
Udviklingsarbejdet med agile metoder stiller krav til fleksibilitet hos medarbejderne.
- Kernen i processen er, at man lærer gennem hele projektet og meget af tiden ændrer på tingene, siger Bent Jensen.
Det kræver, at udviklerne løbende tilpasser sig planen, der ændres på baggrund af et stadigt feedback.
- Det er et spørgsmål om flow og feedback-loops, som sikrer, at man justerer tingene på stedet. Udviklerne sidder ikke for sig selv og har ansvaret for en meget lille ting og glemmer resten af produktet. Udviklingsarbejdet er meget teamorienteret. Det kræver selvfølgelig, at man opgiver sit ego og fokuserer på helheden. Til gengæld giver det medarbejderne tryghed om, at der laves produkter med kvalitet hele vejen igennem. Det sikrer en fantastisk teamspirit, siger Bent Jensen. Udviklingsprocessen anvendes med modifikationer i resten af SAS Institute.
Men hvordan fungerer den agile udviklingsmodel, hvis man er i et mere traditionelt kunde-leverandør-forhold?
- Det er selvfølgelig nemmere, når vores kunde er i samme virksomhed, som vi selv er. Det er sværere, men ikke umuligt, hvis man har et traditionelt kundekontrakt-forhold, mener Bent Jensen. Han medgiver, at der er tale om en tillidsbaseret model, men mener, at det er nemmere at opfylde kundens krav ved hjælp af en agil udviklingsmetode end ved traditionelle udviklingsmetoder.
- De traditionelle udviklingsmetoder har ofte ført til tvister, fordi de specificerede krav netop ikke har været opfattet på samme måde af kunden og leverandøren. Med de agile metoder får kunde og leverandør hurtigt afstemt deres forventninger, og processen sikrer, at kunden får udviklet den vigtigste funktionalitet først, mener Bent Jensen.
Billedtekst:
Foranderlig - Med de agile metoder er der mulighed for at styre undervejs. Man kan meget tidligt i det samlede projektforløb se, om estimaterne holder, fremhæver Bent Jensen. Foto: Torben Nielsen
