Agile projekter af nød og lyst

Jan Stage – professor i datalogi ved Aalborg Universitet – er citeret for at agile metoder er bedst til simple eller usikre projekter, mens en mere top-down agtig tilgang er nødvendig for kritiske projekter.

Imidlertid overser han at erfaring og modenhed spiller en afgørende rolle for om det overhovedet er muligt at bruge en vandfaldsmodel, hvor kravene er specificeret i detaljer før selve udviklingen starter.

For et år siden beskrev jeg, hvordan lærergruppen hvor jeg arbejder havde lavet en scrumbaseret uddannelse. Her efter sommerferien indførte vi så i stedet et fast skema. Det var ikke fordi vores opgaver havde ændret sig, men fordi vi i det mellemliggende år havde gjort så mange erfaringer, at vi kunne lave en planlægning ovenfra og ned som alt iberegnet gør arbejdet lettere og videre forudsigeligt.

Hvis vi går halvtreds år tilbage, kørte de fleste IT-projekter reelt som en eller anden form for agil udvikling, hvor udviklerne fortsatte med at lave ændringer til systemet fungerede tilfredsstillende. En væsentlig årsag var nok manglende erfaringer. På samme måde kan vi betragte udviklingen af mobiltelefoner over en række generationer som en agil udvikling. Hver ny generation afdækker nye muligheder og behov, så ingen kan forudse udviklingen over en årrække.

Et firma som ruller mindre web-sites ud til forskellige firmaer med samme teknologi og stort set samme struktur, vil uvilkårligt ved det første møde stille de afgørende spørgsmål om firmaets behov. Derefter kan de komme med et forslag, som i høj grad er en top-down approach. Faktisk er det de relativt simple projekter, hvor det er lettest at samle så mange erfaringer, at det er muligt at effektivisere og standardisere en top-down styret udvikling.

Jan Stage nævner rutefly og rumfærgen som eksempler på komplekse systemer, hvor det er nødvendigt med et top-down design. Spørgsmålet er bare, om ikke top-down designet og sikkerheden, som gør at vi trygt kan sætte os op i et rutefly, begge er resultat af flyfabrikkernes erfaringer, som gør at de kender problemerne og kan styre den komplekse udvikling.

Petroski beskriver processen omkring designet af et rutefly, og hvordan den gradvist er udviklet siden 1940'erne. Han beskriver også – meget interessant - de uventede havarier af både de britiske Cometfly som var de første med trykkabiner, og de uventede havarier af Airbus fly som var de første med fly-by-wire. I begge tilfælde var designprocessen den samme, men der var sket et skift til en ny teknologi som flyfabrikanterne savnede erfaringer med.

I sådan en situation, er det nærmest umuligt at lave et top-down design som fungerer. Her er en mere agil og eksperimenterende metode måske ligefrem en fordel, selv for noget så komplekst som dele af et rutefly.

Det samme gælder nok for rumfærgen, der startede med et top-down approach og sluttede både som en fiasko og som et ufrivilligt eksempel på agilt design, når uventede problemer skulle rettes undervejs. Her var der tale om et helt sæt af revolutionære teknologier, hvor konstruktørerne savnede erfaringer.

Agile metoder er gode til eksperimenter, og de er uundgåelige, når ledelsen savner erfaringer med tilsvarende projekter. Desuden er der nogle mindre faglige grunde til at vælge dem. Det kan være mere motiverende for udviklere, når de undervejs kan påvirke forløbet og indholdet i deres arbejde, i stedet for blot at skulle lave hvad der står i planen.

Leverandøren kan også have en interesse i at undgå en langvarig kravproces, og i stedet hurtigt gå i gang med en agil udvikling, så det er muligt at skrive arbejdstimer på projektet for de udviklere, der ellers koster firmaet penge mens de venter på at komme i gang. Det har jeg set et eksempel på.

Jan Stage er citeret i artiklen: http://www.version2.dk/artikel/agile-metoder-bedst-til-usikre-og-simple-...

Mit indlæg om scrum-baseret undervisning står på: http://www.version2.dk/blog/en-scrum-baseret-it-uddannelse-16901

Henry Petroski: Invention by Design How Engineers Get from Thought to Thing. 1996