Vandfaldsmodellen hænger fast selvom alle taler om agil udvikling

Flertallet af it-projekter udvikles stadig efter vandfaldsmodellen. Den agile udviklingsmodel kæmper mod træge organisationer og lider under manglende kontrolredskaber.

Den klassiske vandfaldsmodel for softwareudvikling lever i bedste velgående. Den blev brugt i 56 procent af it-projekterne i 2015 ifølge analysefirmaet Gartner, og selvom agil udvikling står på dagsordenen, så har det ikke let ved at bide sig fast. Det skriver The Register.

Problemet ligger hovedsageligt i omstillingen fra den traditionelle metode til den agile metode. Der er flere forhindringer undervejs, der kan få en ambition om at gå over til agil udvikling til at støde på grund.

Det kan eksempelvis være udviklere, der har arbejdet mange år i firmaet efter vandfaldsmodellen med nogle helt centrale systemer. Hvis de ikke er med på at skifte, så kan deres modstand tvinge organisationen tilbage på den gamle model. Tilbagefaldet kan også ske over tid, når udviklerne falder tilbage i gamle vaner.

Der er også modstandere af den nærmest religiøse måde, agil udvikling fremstilles på i visse kredse. Det kan betyde, at en organisation vælger at gå agilt, fordi det er nyt og smart, men måske mangler at forankre den agile tankegang i organisationen. Når centrale nøglepersoner, der har været drivkraften bag det agile, forsvinder, så falder det agile arbejde fra hinanden.

Endelig kan der være problemer med at få de agile udviklingsmetoder til at passe ind med de processer, der styrer resten af organisationen.

Eksempelvis kan det være svært at forene Prince 2 og lignende modeller med agil udvikling. Den agile tankegang kan gøre det svært at registrere og rapportere, hvor projektet er, især hvis projektlederen ikke kan jonglere for eksempel både Scrum og Prince.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (11)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Ivan Skytte Jørgensen

agile (med lille a) er ikke så svært: Bryd arbejdet op i mindre features og gør dem færdige en ad gangen. Acceptér at verdenen ændrer sig og kunden skifter mening. Sørg for automatiseret test så man kan rydde op i dårlige implementationer uden at ligge søvnløs om natten. Undgå vandtætte skodder mellem udviklerene. Acceptér at man ikke kan vide alt på forhånd. Altsammen gode ideer som (for det meste) hugget andre steder fra.

Der hvor filmen knækker er, når det bliver Church of Agile (med stort A). Pludselig bliver målet om at være fleksibel erstattet af øhm.. tja.. noget ridigt og meget lidt appetitelig. Men det er Agile! Og derfor godt!

Ovenstående skal nok få folk op af stolen. Men lad mig lige fortælle baggrunden for min erfaring: 15 år i virksomheden, med op- og nedture. Nogle personer hang stadig fast i at gerne ville skrive store specifikationer, men kunne presses til at splitte features op. Nogle ville gerne have mere kundekontakt, men kunne ikke presses til konsulent/on-site support. Jeg var sendt ud til kunder flere gange og arbejde generelt tæt sammen med supportafdelingen. Jeg tog også vande-potteplanter-tjansen, for så kom jeg forbi alle kollegerne mindst en gang om ugen. Efter en længere række frasalg/tilkøb/fusioner blev afdelingen købt af en større virksomhed. De sendte en præst fra Church of Agile uden jordforbindelse. Selvfølgelig skulle alle kunne kode alt. Selvfølgelig var hjemmearbejde ikke muligt for så kunne man ikke være med til daglig standup. Ingen personlig ansvarsområder (men der kunne allernådigst være "subject matter experts"). Selvfølgelig skulle der omplaceres 2-3 udviklere til at være product owners (som skulle bruge omkring 120% af tiden på møder), men nej, der kunne ikke skaffes flere hænder. Jeg tog en dyb indånding og indleverede min opsigelse. I modsætning til det man normalt siger "people join companies but leaves managers", så forlod jeg ikke pga. min chef (som faktisk var smadderdygtig - han kunne bare ikke skærme imod det ovenfra kommende pres).

Så:
1: lær fra agile. Der er masser af gode ting i det. Målet er at kunne skifte retning hurtigt.
2: Agile (med stort A) skal dø

Michael Cederberg

agile (med lille a) er ikke så svært: Bryd arbejdet op i mindre features og gør dem færdige en ad gangen. Acceptér at verdenen ændrer sig og kunden skifter mening

Det er jeg ikke uenig i. Men det der normalt får filmen til at knække er at alle organisationer gerne vil have et indledende estimat over omkostninger baseret på et ønsket featureset. Hvis man ikke laver detaljeret planlægning/design og baserer estimater på det, så ender man nemt med et budget der er helt galt (det sker nu også ofte selvom man laver detaljeret planlægning og design). Og så er vi allerede på afveje. Med det store indledede design er vi allerede på vej mod den gamle vandfaldsmodel.

Jeg har altid ment at "agile" primært handler om at alle skal erkende at ingen kan lave ordentlige specs up-front, at ingen kan lave perfekt design blot på basis af specs, og at planer og budgetter derfor bliver derefter.

Jeg har svært ved at forestille mig ledere i virksomheder planlægge med blot at sige: Her er X millioner – lav så meget I kan på projektet (ok, det kan brydes ned i mindre portioner, men det har også en række minusser). For hvordan kan ledelsen vælge hvad de vil bruge penge på, hvis de ikke ved hvad det koster? Og så er vi tilbage ved at alle skal erkende at de ikke kan få oplyst pris, tidsramme og featureset inden projektet starter.

Leif Lodahl

Det er min opfattelse at de danske fortolkninger af gældende udbudsregler sætter meget firkantede regler op for, hvordan kontrakterne skal udformes. Kammeradvokaten, som de facto er rådgiver for samtlige IT-indkøb i centralforvaltningen, er medvirkende til denne tendens.

SKI er begyndt at rykke sig, men standardkontrakterne hænger fortsat lidt i bremsen, og der er ikke rigtig nogen der tør afvige fra standardkontrakterne.

Jeg tror det handler om at der skal mere IT-ledelse og mindre advokat i indkøbsprocesserne.

Philip Juhl

Jeg har svært ved at forestille mig ledere i virksomheder planlægge med blot at sige: Her er X millioner – lav så meget I kan på projektet


Det har jeg også svært ved at forestille mig.
Men hvis hverken de eller udviklingerne ved hvad det kommer til at koste, vil det så ikke være bedre at finde ud af det ved sige hvad kan der leveres for 1/10 del af prisen, og på baggrund af dette sige ønsker vi at forsætte eller stoppe?

Philip Juhl

1: lær fra agile. Der er masser af gode ting i det. Målet er at kunne skifte retning hurtigt.
2: Agile (med stort A) skal dø


Jeg har ikke de samme erfaringer som dig. Jeg har mødt både gode og dårlige Agile mentorer. gode og dårlige scrum-masterer og gode og dårlige udviklerer.
Så jeg forstår ikke din argumentation.
Jeg ser Agile som en række principper man kan prøve at få ens arbejdsproces til at "opfylde".
Ligesom f.eks SOLID principper for en udvikler er nogle principper man kan prøve at opfylde med det kode-design man vælger.
De eksempler du nævner lyder mere som om man er gået ud af en tangent, og f.eks droppet at opnå princippet om selvorganiserende teams.

Ivan Skytte Jørgensen

Så jeg forstår ikke din argumentation.


Det tror jeg at du gør, for:

De eksempler du nævner lyder mere som om man er gået ud af en tangent, og f.eks droppet at opnå princippet om selvorganiserende teams.


Det er netop når man gør tingene rigide at det går galt. F.eks. når man fint oplæser agile manifesto heriblandt "We value [...] Individuals and interactions over processes and tools", og så i næste åndrag siger "og derfor har vi disse 30 processer og værktøjer som i skal bruge". Så er det ikke længere nyttige vejledninger og ideer, men derimod religiøse bud som man ikke kan fravige.

Risikoen for rigiditet er ikke unikt for agile. Det kan også forekomme i andre tilgangsmåder (SA/SD, RUP, prototyping, vandfald, ...)

Torben Mogensen Blogger

Men det der normalt får filmen til at knække er at alle organisationer gerne vil have et indledende estimat over omkostninger baseret på et ønsket featureset.

Et gammelt IT-citat siger. "Price, features, deadline: Pick any two". Underforstået, at det er umuligt at fastsatte alle tre ting på forhånd. Lidt ligesom fysikere ikke kan bestemme en partikels position og hastighed samtidigt.

Vanskeligheden i at lave estimater stiger med størrelsen af projektet, så en god strategi er at undgå kæmpestore projekter, men at opdele dem i bittesmå bidder, med mulighed for at trække stikket efter hver bid. Det er vel også en slags "agile", men det strider mod politikeres ønske om at have store forkromede systemer, der kan klare det hele.

Men uanset, så holder jeg mest med Dijkstra:

A number of these phenomena have been bundled under the name "Software Engineering". As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot.".

Frithiof Jensen

Jeg har svært ved at forestille mig ledere i virksomheder planlægge med blot at sige: Her er X millioner – lav så meget I kan på projektet


Det er cirka det man gör: Et projekt har en värdi for lederen, denne värdi skal gerne väre noget höjere end omkostningerne.

Men, man ved jo ikke lige på "Tollgate 0" hvad omkostningerne er. Derfor bryder man projektet ned i features og deliverables ("grupper af features", WU's) som alle har en estimeret pris og en deadline.

Derefter sorterer man sammen med ledelsen sine WU's så de mest värdifulde features og de särligt komplicerede (fordi odd's er at man nok bliver forsinket med disse) så vidt muligt kommer först i projektet.

På det stadie hvor projektet starter kan det godt väre at man vil overstige budgettet og tidsplanen i fölge projektplanen, men det ignorerer man lidt, fordi i löbet af projektet justerer man löbende på "actuals" og man har "tollgates" for vigtige deliverables. Hvis man misser en tollgate kan det betyde at projektet er estimeret forkert eller at teamet ikke leverer. Så må man opdatere planen eller droppe projektet.

Når pengene enten er brugt eller man når deadline, så dropper man ofte de resterende features / WU's - disse er jo i fölge planen de mindst värdifulde, så de er "nice to have".

Så, ja, man har ofte en pose penge og en deadline fra ledelsen og så ser man hvor langt man når ;-)

Carsten Poulsen

Jeg tror, at vandfaldsmodellen finder anvendelse når opdragsgiveren ikke kender værdien af produktet, men skal kunne forsvare investeringen før opgaven startes.
Der laves en simpel forretningsmodel, som skal godkendes af en djøf'er (undskyld stereotypen :-)) og hvis regnestykket ikke hænger sammen, forkastes projektet.
Anderledes ser det ud, hvis projektet er en betingelse for en anden del af en forretning. Her vil der stadig blive set på økonomien, men her er udgangspunktet, at den centrale forretning ikke kan gennemføres uden at underprojetet leverer funktionalitet, som i øvrigt undertiden ikke kendes når hovedprojektet startes. Her vil omstillignsfilosofien spille ind og næsten automatisk sørge for, at projektet gennemføres agilt forstået som: vi ved ikke fra starten hvordan dette skal fungere, men vi bliver nødt til at gå i gang.
Udfordringen for at gennemføre alle projekter agilt bliver derved, at hovedprojektet skal blive klar over, at deres mission ikke kan føres ud i levet uden underprojektet og derved fjerne forretningsfokus fra underprojektet. Djøf'eren skal ud af ligningen som projektstarter. Ikke at djøf'eren skal miste sin betydning, men fokus skal fjernes fra at retfærdiggøre prpjektøkonomien fra starten, men overlade definitionen af kravene til projektgruppen under gennemførelsen i stedet for at forsøge at vide alt fra starten - banal viden, men sandt.

Carsten Poulsen

Desværre vil vandfaldsmodellen (VM) ofte bevirke, at krav specificeres ud fra opdragsgiverens kendte viden. Derved afskærer han sig i høj grad fra at lade udviklerne tilføre ny viden til projektet og eventuelt opnå en bedre løsning end den, som VM kravspecifikationen lægger op til. Det er en L-løsning.

Log ind eller Opret konto for at kommentere
Brugerundersøgelse Version2
maximize minimize