Agile metoder bedst til usikre og simple projekter

Ved komplekse og forudsigelige udviklingsprojekter er vandfaldsmodellen med fast kravspecifikation den bedste garanti for, at de enkelte dele af systemet fungerer sammen.

Mens agile udviklingsmodeller som Scrum nyder interesse fra blandt andet offentlige institutioner, fordi de agile metoder giver gennemskuelighed og en hurtig levering af funktionalitet, så er der andre områder, hvor metoden er mindre velegnet.

Således er det ikke nødvendigvis en god idé at give sig i kast med Scrum eller lignende, hvis der er tale om et projekt med i forvejen kendte rammer, hvor tiden er afgørende, og hvor funktionalitet skal integrere gnidningsløst med andre processer. Det forklarer professor ved Institut for Datalogi på Aalborg Universitet Jan Stage:

»Ved kritiske systemer er man nødt til at være sikker på, at samspillet mellem komponenter altid fungerer, og derfor er man nødt til at designe systemerne mere topdown-agtigt.«

Jan Stage mener, at der til tider nærmest kan være en forskrækkelse over for tankegangen om BDUF – ‘big design up front’ (stort design først) – som vandfaldsmodeller typisk lægger op til. Altså at der på forhånd eksempelvis er specificeret klare strukturelle og designmæssige krav til projektet samt en detaljeret kravspecifikation.

»Jeg tror, at de fleste ville være mere trygge ved at sætte sig op i en flyver, hvis der var sådan et big design up front,« siger han.
Kompleksitet og uforudsigelighed

For at afgøre, om en vandfaldsmodel eller en agil udviklingsmodel er velegnet til et projekt, mener Jan Stage, at det er nødvendigt at kigge på projektets kompleksitet og uforudsigelighed. Han nævner både en rumfærge og en bro som eksempler på komplekse projekter, der ikke er videre uforudsigelige, da de bygger på kendte design.

Derfor bør vandfaldsmodeller bruges til den slags opgaver. Ellers er det vanskeligt at sikre, at de forskellige dele i de komplekse projekter fungerer i en sammenhæng, påpeger Jan Stage.

»Man ved godt, hvordan brugerne i rumfærgen skal bruge det udstyr, der er. Det svære er at få forskelligt udstyr som sensorer til at spille sammen på en måde, så systemerne og rumfærgen ikke pludselig går i stå,« siger han.

Adjunkt ved IT-Universitetet Lene Pries-Heje er enig i, at Scrum og andre agile tilgange ikke nødvendigvis egner sig til store og komplekse projekter, hvor informationer skal kunne udveksles mellem flere elementer.
»Ved en vandfaldsmodel har man opdelt projektet i nogle faser, der skal afsluttes. Og der er typisk nogle dokumenter, der bevirker, at man kan kommunikere, hvad der foregår i en fase og over til en anden fase,« siger hun og tilføjer:

»Jo flere, der arbejder samtidigt med komplekse problemstillinger, des mere er man nødt til at lave en højere grad af planlægning og arkitektur for at kunne koordinere de
involveredes arbejde, og det er vandfaldsmodeller velegnede til.«

Til gengæld er agile udviklings¬metoder velegnede til projekter, hvor usikkerheden er stor, påpeger hun:

»Eksempelvis i offentlige projekter, hvor der hele tiden kommer ny lovgivning. Der kan det være en god idé at have en agil tilgang, så det går forholdsvist hurtigt at implementere den nye lovgivning i de bagvedliggende systemer.«

Version2 sætter frem til 18. oktober fokus på agil udvikling.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (12)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#3 Morten Hoffmann

når pointerne bag det agile manifest synes at være gået helt hen over hovedet på artiklens ophav. Der er selvfølgelig værdi i at tænke sig om på forhånd, men der er større værdi i kun at tænke nok til at kunne slice projektet op i meningsfulde bidder, hvoraf de forretningsmæssigt vigtigste er detail-specificerede. Derefter sluges bidderne een af gangen, vi får "smagsoplevelsen" undervejs og kan rette ind om nødvendigt. På den måde håndteres de uundgåelige ændringer vi støder på.

Og det siger jeg selvfølgelig helt på linie med Lars Balker – med 16+ års erfaring har jeg endnu til gode at arbejde på bare eet softwareudviklingsprojekt, som på samme tid er komplekst og forudsigeligt.

  • 5
  • 0
#5 Nikolaj Brinch Jørgensen

at udtalelserne kommer fra en verden som ikke gør sig i at realisere store komplekse IT systemer.

At tro at projektet (selv en bro eller en flyver) er forudsigelige er epic fall. Al vandfald bygger på antagelser og forudsigelser. Det som de iterative processor (herunder de agile) giver mulighed for er, at rette ind i forhold til de fejlantagelser og forudsigelser vi har gjort os tidligere.

Det giver vandfaldsmodellen os ikke. Desværre er jeg tilbøjelig til at give forfatterne ret, så længe systemet har en helt klart specificeret kravsspecifikation der i detaljer beskriver alle funktioner (det som nogen af os referere til at systemet er implementeret i Word først herefter med IT infrastruktur). Men sådanne systemer er jeg endnu ikke stødt på. Altså systemer hvor der ikke sidder en kunde i den anden ende og gerne lige vil have ændret noget, eller hvor ydre omstændigheder kræver ændringer, f.eks. konkurrenter og markedet generelt.

En timeboxed vandfaldsmodel giver et kendt resultat, nemlig et, hvor det som der kan skrues ned for, for at nå at blive færdig, er kvaliteten - det giver sig selv da det er den sidste fase i projektet. De iterative giver os andre valg end kun kvaliteten, det er den helt store forskel, og det er synd at det ikke kommer frem fra ophavet til artiklen.

Og så vil jeg da give Morten ret, i at det ser ud til at det agile manifest er gået helt hen over hovedet på artiklens ophav.

  • 3
  • 0
#6 Klaus Enevoldsen

Agile udelukker da ikke dokumentation, desuden kan man lave dårlig kvalitet både med vandfald og med agile. Det er det faglige håndværk, der er afgørende. Desuden er det den, der stiller kravenes evne til at beskrive dem, der er afgørende for mulighederne for at teste en User Story. Tester man op mod sine acceptance criteria (eller Conditions of Satisfaction som Mike Cohn hellere vil kalde dem), går man aldrig helt galt i byen, men det kræver at man har gode acceptance criteria og det er ikke nemt.

  • 1
  • 0
#7 Niki Nicolas Grigoriou

@Lars og @Morten med flere.

Jeg synes kommentarer bære præg af en antagelse om al systemudvikling foregår på samme præmisser og kun omfatter software. Sådan er det ikke altid. Lige præcis eksemplerne med fly og broer er komplekse systemer, som i høj grad har fysiske aspekter - og ikke kun består alene af software, som kan opdateres i næste "release". Så snart den slags fysiske aspekter indgår i de systemer man udvikler, så er agile metoder ikke svaret på alt.

Alex' eksempel med patientovervågning på intensiv afdeling på et sygehus kræver f.eks. at sensorer og software er udviklet og kliniks testet og valideret inden det tages i brug på patienter. Hvis man laver software, som styrer robotter og maskiner, så skal man sikre sig at f.eks. EU-maskindirektiv er overholdt i lønningen. Den slags systemkrav lægger op til en eller anden form for vandfaldsmodel. At man så med fordel kan bruge agile elementer indenfor de enkelte faser og ofte gør det, bekræfter kun at verden ikke bør ses i sort/hvid.

  • 0
  • 1
#8 Nikolaj Brinch Jørgensen

@Niki

Agil vs. Vandfaldsmodel. Det er rigtigt at ingen metode er one-size-fits-all, og at verden ikke er sort hvid. Jeg tror det er det folk her opponerer imod, ifht. artiklen. Artiklen sætter i den grad en sort/hvis verden op, med nogle meget få og uhørt brede penselstrøg for hvornår man skal vælge det ene fremfor det andet. Det duer ikke. Artiklen læser de fleste af os i en software udviklingskontekst, for det er der jeg går ud fra den er møntet (siden den er kommet på V2?).

Jeg mener ikke at al systemudvikling foregår på samme præmis, slet ikke. Der er en masse variation her. Men det jeg mener der er brug for er, at gøre om med hvid-tankegangen. Nemlig at whitelable vandfaldsmodellen, og blive holdt fast i en nogen gange omkostningstung affære. Jeg er sikker på man godt kan lave både patientovervågning og robotter efter agile metoder (software til patientovervågning er vel ikke anderledes en al muligt andet software og robotter er vel ikke specielt anderledes end al muligt andet - at et EU-maskindirektiv skal overholdes har ingen indflydelse). Der hvor jeg synes kæden tit hopper af, er når udviklingsafdeingen slår sig på, at de jo er åh så specielle så de kan i hvert fald ikke bruge generealiseret metode a, b eller c. Når man så analysere det, så viser det sig at de langt hen ad vejen, at forskellene er minimale.

  • 0
  • 0
#9 Morten Hoffmann

@Niki Uden at dette skal udvikle sig til en teologisk diskussion, så er udgangspunktet for min kommentar nok at jeg blev provokeret af en datalogi-professors (måske journalistens?) meget simple udlægning af agile. De opgaver hvor det ikke gør en forskel om vi anvender den ene metode eller den anden, er "sikre og simple", for nu at genskrive artiklens overskrift, og kræver på ingen måde et BDUF.

For alle andre opgavers vedkommende (uforudsigelige eller komplekse) kan det efter min mening altid betale sig at arbejde i små hurtige afleveringer (vertikale snit), for derigennem at drage erfaringer, som kan tages med videre.

Det kunne f.eks. være i form af en stubbet (eller mock'et) udgave af hardwaren eller det formodede maskindirektiv, eller bedre endnu blot dele af snitfladerne.

  • 0
  • 0
#10 Martin Frederiksen

Jeg råber i kor med Morten, og så vil jeg gerne tilføje (med baggrund i web-projekter, som er min hverdag), at en stor fare i vandfaldsmodellen er "organisationens opfattede klarhed over egne behov", som meget sjældent er i sync med "organisationens faktiske behov".

Ofte er det faktisk tilfældet, at når man når et par trin hen i processen, at det viser sig at man kan klare sig med en mindre løsning end de selv tror - og så er det jo dobbelt ærgeligt at have skrevet under på kontrakten på et BDUF.

  • 1
  • 0
#12 Jeppe Boelsmand

Hvis dokumentation er kritisk for leverancen er den vel sin egen pind i backloggen og i sprintet. Følger det ikke logisk at dokumentation der er lavet på den måde bedre beskriver det der faktisk blev lavet?

Da jeg var en del af AAU IS var Jan Stage HCI guru og brugte det meste af sin tid på det og det ser ikke ud til at have ændret sig når man ser på han udgivelser. Jeg syntes ikke hans holdning skal veje tungt fordi han har AE stemplet når han udtaler sig om Agil udvikling. Jeg så gerne at man spurgte Ivan Aaen eller Arne Skou en anden gang.

  • 0
  • 0
Log ind eller Opret konto for at kommentere