Agile Software Development  

Captator tilslutter sig "The Agile Manifesto", et manifest underskrevet af bagmændene til flere udviklingsmetoder (bla. eXtreme Programming). Disse udviklingsmetoder værdsætter nogle fælles mål, som manifestet understreger.

Manifest for adræt software udvikling
"Vi forsøger at finde bedre måder at udvikle software på,
ved selv at være udførende og ved at hjælpe andre.
Gennem dette arbejde, har vi fundet frem til
at værdsætte følgende værdier"
Det individuelle individ og samarbejde frem for metoder og værktøjer
Fungerende software frem for omfattende dokumentation
Samspil med kunden  frem for kontraktforhandlinger
Reaktion på forandring frem for at følge en plan

Baggrund for manifestet:

Software udvikling har siden de tidlige dage i 60'erne voldt problemer. Der har været mange succesfulde projekter, men mindst lige så mange fiaskoer.

Op gennem 60'erne, 70'erne og 80'erne kom mange teknikker til. De skulle sikre at forarbejdet til større software projekter var i orden - så kunne intet vel gå galt? Vi fik struktureret programmering, struktureret design, struktureret analyse, struktureret kravsspecifikationer mm. Alle disse teknikker blev indkorporeret i vandfaldsmodellen. Denne model er faseopdelt, en fase afsluttes før den næste indledes. Faserne kunne være: forstudie, kravsanalyse, programanalyse, designfase, programmeringsfase, testfase, idriftsættelse.

Efterhånden som kompleksiteten steg og projekterne blev større, blev udviklingstiden så lang, at nyudviklede systemer, der var udset til at være banebrydende, var baseret på halvforældet teknologi, havde specifikationer, der viste sig slet ikke at være til gavn for slutbrugerne samt mange af de andre klassiske "uheldigheder".

I sidste halvdel af 80'erne og op gennem 90'erne blev objektorientering udnævnt til det store vidunder. Der var mange bud på objektorienterede metoder og notationer frem til midt i 90'erne. I 1997 blev UML (Unified Modelling Language) standardiseret. Herefter blev UML hurtigt den udbredte notation for beskrivelse af objektorienterede systemer.

Men i midt 90'erne var der stadig mange bud på hvorledes en udviklingsmetode burde se ud. Man var enige om at en moderne udviklingsmetode skulle være inkrementiel/iterativ. I modsætning til vandfaldsmodellen deles et projekt op i mange mindre dele, hvor hver enkelt del af systemet gøres færdig, før der tages hul på næste del. Derudover var der meget stor variation over hvordan man skulle gribe det an.

Fra midt i 90'erne begyndte der at dukke metoder op, der i stedet for at være meget processtungt baserede sig mere på samarbejdet mellem de enkelte individer i et softwareudviklingsprojekt. Fra at den enkelte udvikler blot var en ressource i en plan så blev han/hun gjort "til et menneske". Det er de enkelte personer i et projekt, der ofte gør udfaldet om projektet går godt eller skidt, i langt højere grad end den metode, der benyttes.

Disse metoder blev under et kaldt "letvægtsmetoder" og omfattede: eXtreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming.

Der er mange ligheder mellem disse metoder, men man kunne godt tvivle på at personerne bag metoderne nogensinde kunne blive enige om noget som helst. Når man hørte dem debattere på konferencer, var der ihverttilfælde mange ting, de ikke var enige om.

Foranlediget af et møde mellem nogle af bagmændende til Extreme Programming blev de fleste af personerne bag de før omtalte letvægtsmetoder samlet i en hytte i februar 2001. De brugte 2 dage sammen til at prøve at finde fælles fodfæste. Dette arbejde resulterede i manifestet og et nyt og bedre navn, frem for "letvægts metoderne" blev fællesbetegnelsen for metoderne omdøbt til "Agile Software Development" - de adrætte metoder.

Manifestet for adræt softwareudvikling er oversat til dansk af Captator, se den originale engelske tekst på "The Agile Manifesto"'s hjemmeside.