Jihmmy er en meget tung dreng med over 22 års erfaring som systemudvikler, projektleder og konsulent. Primært fokuseret på projektledelse men også med en solid teknisk kompetence på state-of-the-art Microsoft implementeringer.
Nogle projekter afsluttes med succes, nogle holder ikke tidsfristen eller den økonomiske ramme. Andre projekter afsluttes midt i forløbet, fordi en ”earned value” prognose viser, at projektet højst sandsynligt aldrig vil nå i mål, ligesom nogle projekter aldrig overgår til drift grundet manglende funktionalitet og kvalitet. Der er mange bud på, hvad der skal til for at et projekt kan lykkes. Nogle mener, at vejen til succes er anvendelse af en bestemt systemudviklingsmetode frem for en anden, og det er netop, hvad denne artikel handler om.
Trenden lige nu er, at vejen til succes går gennem anvendelse af agile systemudviklingsmetoder og extreme programming (XP). Ingen artikel og intet seminar eller konference med respekt for sig selv undlader at prædike agile metoder. Det er også sandt, at rækken af succeshistorier, hvor der er anvendt agile metoder, er lang. Sagen er bare den, at der er lige så mange succesfulde projekter, som anvender plandrevne udviklingsmodeller. Spørgsmålet er så, hvorfor går det sommetider godt at anvende plandrevne modeller, og hvorfor går det sommetider galt? Hvorfor lykkes et projekt ikke altid, når man anvender en agil metode?
Jeg vil i denne artikel anvise nogle ”håndtag”, som man som konsulent kan tage i anvendelse, når man står over for en konkret opgave og skal vælge en systemudviklingsmetode, ligesom jeg vil beskrive et par konkrete projekter til at belyse konsekvensen af at vælge den ene metode frem for den anden.
Historisk set har de plandrevne metoder, også kaldet vandfalds-metoder, altid eksisteret og vil fortsat blive anvendt. De agile metoder, eller letvægts-metoder, er dels udviklet som en konsekvens af indførelsen af objektorienteret programmering, dels ved en gradvis overgang fra få, store centrale transaktionssystemer til mange mindre decentrale videnssystemer, og har således over tid vundet mere og mere anvendelse i takt med stigningen i client-server- og internetbaserede projekter.
Det hele tog sin egen form, da 17 ”ustyrlige” programmører i 2001 mødtes på en skiferie i Utah og opfandt ”The Agile Manifesto” som det eneste sande mantra. Flere af deltagerne har siden hen gjort mantraet lidt blødere og erkendt, at one-size ikke passer til alle. Grundholdningen er dog stadig, at der findes to yderpunkter: Money-for-documentation (plandreven) og money-for-functionality (letvægt). Faktisk er der mere eller mindre konsensus på metodefronten, og der er nærmest en stiltiende overenskomst om, at flere faktorer (det er her håndtagene kommer ind) kan have indflydelse på, hvilken metode der er den mest optimale at anvende i en given situation. For at nævne et yderpunkt, er en af de 17 skiløbere fra Utah nået frem til at opgøre antallet af omkomne i et projekt. Dette kan være vældig relevant, hvis man arbejder med persontransport (fly og tog), rumfart (NASA mv.) eller i våbenindustrien. Han fraråder direkte, at anvende agile metoder, hvis det kan koste menneskeliv. For eksempel består en kabinedør til et moderne passagerfly blandt andre ting af ca. 400 skruer. Alle disse skruer har et nummer og er udførligt beskrevet i en manual. Dette ville man aldrig have gjort i en agil metode.
Bortset for antallet af omkomne personer, som dog er et ekstremt ”håndtag”, har følgende faktorer en afgørende indflydelse på, om man får succes med henholdsvis den ene eller den anden systemudviklingsmetode:
Opgavens størrelse og kompleksitet:
Store (mandetid) og teknisk komplekse projekter hælder mod en plandreven metode, mens knapt så store og mindre komplekse projekter taler for en agil metode.
Projektgruppens viden:
Jo større forretningsviden, projektviden samt teknisk viden jo mere agil.
Projektdeltagernes baggrund:
Stor projekterfaring og motivation taler for en agil metode, mens en plandreven metode mindsker projektrisikoen, hvis der er tale om manglende erfaring.
Fysiske forhold:
Agile metoder fordrer, at udviklere har uhindret adgang til brugerorganisationen under hele udviklingsprocessen, ja faktisk skal de helst sidde i samme lokale!
Projektgruppens sammensætning:
Undersøgelser har vist, at agile metoder bedst lykkes i små grupper med blandede persontyper, som har erfaring fra tidligere eller lignende projekter.
Kalendertid:
Kort time-to-market taler for en agil metode.
Interessenter:
Få interssenter, hvor der er enighed om produkt og proces, taler for en agil metode, mens mange interessenter med forskellige opfattelser finder bedre indpas i en plandreven model.
Kvalitet:
Er kvalitet det altoverskyggende succeskriterium frem for tid og økonomi, skal man anvende en plandreven metode.
Som det ses, er der flere ”håndtag” som har indflydelse på valg af systemudviklingsmetode. Nogle af håndtagene er modsatrettede, hvilket gør, at man må foretage en afvejning og vælge en metode, som ligger mellem de to yderpunkter f.eks. en delvis inkrementiel metode, som indeholder elementer fra både en plandreven- og en agil metode eller RUP, som er use-case og arkitektur-drevet.
Case 1 – ”eDag”
I forbindelse med indførelsen af elektronisk faktura i den offentlige sektor skulle en større finansiel virksomhed udvikle et middleware-produkt, som kunne sende og modtage elektronisk faktura. Projektet havde følgende kendetegn:
Projektet blev pålagt en plandreven systemudviklingsmodel
(company policy). 9 måneder efter projektstart blev projektet
lukket. Det eneste, der var produceret, var en kravspecifikation på 1000 sider. Projektet er siden hen startet igen og er afsluttet med 24 måneders forsinkelse.
Kigger man på projektets kendetegn, ligner det mere et letvægts-projekt end et plandrevet projekt. Givet projektgruppens sammensætning og store erfaring og motivation og den tidsmæssige deadline og projektets trods alt moderate størrelse, burde man nok have lavet en afvejning og valgt en metode, hvor man lynhurtigt fik udviklet en prototype (money-for-functionality) og præsenteret denne for interessenterne, så de havde noget konkret at forholde sig til i stedet for et 1000 sider stort dokument.
Case 2 – ”Big Bill”
En offentlig virksomhed startede i 1999 et udviklingsprojekt. Projektet gik ud på at erstatte et eksisterende, egenudviklet billing-system med et nyt, egenudviklet system, som var år 2000-parat. Ved udgangen af 2004 var projektet 75% færdigt, og projektet blev lukket. I starten af 2005 startede man et nyt projekt. Det nye projekt havde følgende kendetegn:
Der blev ikke valgt en ren agil metode, da der ikke var direkte adgang til brugerorganisationen, ligesom de høje kvalitetskrav gjorde, at det færdige produkt skulle være fejlfrit inden for den anførte tidsramme. RUP er for stort til så lille et projekt, så der blev valgt en delvis inkrementiel metode. Første produktionstest blev udført i april måned 2005 og projektet blev afleveret i sommeren 2005, som erstatning for det gamle system.
Som det fremgår af mine to eksempler, er ingen af dem rene agile projekter eller rene plandrevne projekter. Min hensigt har været at underbygge påstanden om, at one-size ikke passer til alle projekter, og at man, stillet overfor de to yderpunkter plandreven og agil, i praksis ofte må foretage en afvejning og træffe et valgt ud fra de 8 kriterier, som kan opstilles for en projektopgave.
I det hele taget synes jeg, det er en god ide altid at benytte skemaet til at vurdere sine udviklingsopgaver og træffe et bevidst valg, inden man kaster tid, penge og kvalitet over bord og tror, at en bestemt systemudviklingsmetode er den rigtige, fordi det gik godt sidste gang.
