georg strøm bloghoved

Agile projekter af nød og lyst

Af 3

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

Kommentarer (3)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Bent Jensen

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

Det er en udbredt misforståelse, at agil udvikling først og fremmest fravær af specifikationer og design. Det er rigtigt at man ofte undlader at specificere i detajler, fordi det ikke er nødvendigt i nogle typer af projekter, men det er ikke noget der ligger i agile metoder som sådan.

Det, der kendetegner agile metoder er derimod at detaljerne specificeres på det tidspunkt der er brug for dem, og at man indbygger hurtig feedback i alle dele af processen. Ved komplekse systemer - måske særligt ved udvikling af komplekse systemer, er feedback og tidlig integration afgørende for både udviklingshastighed og robusthed af løsningen.

Der er derfor også langt fra den "code and fix" metode man benyttede i IT-projekter for 50 år siden og den meget disciplinerede praksis som kendetegner "rigtig" agil udvikling som den praktiseres af de bedste virksomheder i dag.

  • 4
  • 0
#2 Deleted User

Et interessant indlæg, men tror nu ikke alle påstandene holder!

Har godt nok ikke erfaring med rutefly og rumfærger men kun med sateliter og der har man ganske rigtigt en vandfalds tilgang til udviklings processen, hvilket jeg vil mene dels er fordi det er en meget konservativ branche.

Desuden er det når det kommer til stykket ikke et rigtigt vandfald alligevel! Det er sågar bygget ind i de standarder man bruger at krav- specifikationer kan blive opdateret at man kan have "change request" "request for wavier" osv.

Så jeg tror at grunden til at det som regel lykkes er fordi det SKAL virke, og at der i den branche er et kæmpe overhead af dokumentation af hvordan alt er testet og hvordan krav ændre sig mm.

Og hjørnestenen i at sikre at det lykkes er test og atter test, desuden er der en del eksempler på at en test kampagne er blevet stoppet og en hardware eller software enhed er send tilbage til leverandøren med ønske om diverse ændringer.

Der er med andre ord rigeligt med feedback i den måde store og kritiske systemer udvikles på, det er bare langsom og vel dokumenteret feedback, derefter er man så grundig at man ikke fejler man bliver bare forsinket. (hvis der nogen der kan nævne et fly eller rumfærge lignende projekt der ikke blev et par år forsinket vil jeg godt høre om det).

Når det så er sagt er der naturligvis mange særdeles skarpe hjerne i fly og rum industrien og vær sikker på de er bevist om at der er plads til forbedring, og nok med tiden og langsomme forsigtige skridt vil overføre visse agile ideer.

  • 0
  • 0
#3 Anders Dinsen

Georg, jeg synes du her har fundet et vigtigt perspektiv, der viser en afgørende forskel mellem agile udviklingsmodeller og top-down/vandfald: For tit tales der kun om spild i processen og produktkvalitet, men det er godt at du viser at der er andre faktorer i spil.

Og netop forudsigelighed er en afgørende kvalitet ved top-down baserede metoder, og forudsigelighed er i sig selv en vigtig parameter i mange projekter, uanset om den medfører lidt (eller megen) spild i processen.

/Anders

  • 0
  • 0
Log ind eller Opret konto for at kommentere
Job fra Jobfinder
Tip redaktionen