Het 6-fasenmodel is een watervalmodel. Dat wil zeggen dat de fases na elkaar plaatsvinden. Net zoals je niet omhoog kan zwemmen tegen een waterval in, kan je in het pure watervalmodel na het doorlopen van een fase ook niet meer terug. Het is niet wenselijk als in de realisatiefase besloten wordt om het ontwerp aan te passen en daarvoor de uitvoering stil te leggen. Het watervalmodel is doorgaans minder geschikt voor softwareontwikkelingsprojecten. Hiervoor zijn een aantal oorzaken (zie o.a. McConnell, 1996, Kroll, 2004, Chromatic, 2003 en Stapleton, 2002).
- De ontwikkeling van software is een creatief proces.
- Het is bijna onmogelijk alle eisen en wensen (functionaliteiten) voor nieuwe software vooraf boven water te krijgen.
- Het inschatten van de benodigde hoeveelheid tijd voor het realiseren van een functionaliteit is erg moeilijk.
- Het is wenselijk dat alle tussenresultaten door de gebruiker gedurende het traject getest kunnen worden.
- Agile projectmanagementmethodes
- Voorwaarden voor Agile projectmanagement
- Risico’s van Agile projectmanagement
De ontwikkeling van software is een creatief proces
De ontwikkeling van software wordt door buitenstaanders eerder als ‘engineering’ dan als ‘iets uitvinden’ gezien. Toch heeft het wel raakvlakken met iets uitvinden. Iets uitvinden betekent dat je vooraf nooit precies weet wat er gaat komen.
De ontwerpers en programmeurs die nieuwe software gaan schrijven, moeten oplossingen bedenken voor de problemen die hen worden voorgeschoteld. Ondanks vele methodes en voorschriften van werken, blijft het schrijven van programmacode voor een groot deel nieuw en daardoor in hoge mate onzeker. De programmeurs kunnen voor hun oplossing kiezen uit wel miljoenen oplossingen, geschreven in tientallen programmeertalen, draaiend op duizendtallen verschillende hardwareconfiguraties, werkend op tientallen software platforms. Die vrijheid biedt een aantal voordelen, maar maakt ook dat het project moeilijker te beheersen is dan traditionele projecten als bijvoorbeeld constructie- of bouwprojecten.
Het is vrijwel onmogelijk alle eisen en wensen vooraf boven water te krijgen
De watervalmethode schrijft voor dat in de definitiefase de eisen en wensen als projectresultaat geformuleerd worden. Idealiter geval wordt van die eisen of wensen niet of nauwelijks meer afgeweken. Bij softwareontwikkeling volgens het watervalmodel wordt er in het begin van het project veel tijd besteed aan het analyseren van de benodigde functionaliteiten (eisen en wensen). Dit leidt tot een functioneel ontwerp (voor een nadere toelichting op functioneel ontwerpen, zie bijvoorbeeld [i]). Op basis van het functionele ontwerp gaat de softwarearchitect in de ontwerpfase een technisch ontwerp maken. In het technische ontwerp wordt beschreven hoe de gewenste functionaliteiten gerealiseerd moeten worden.
Dit lijkt allemaal vrij recht toe recht aan, maar stel de volgende situatie voor (voorbeeld aangepast van McConnell, 1996, p. 138): Er is een project voor de productie van een nieuwe auto. U bent een actieve autorijder en aan u wordt gevraagd de eisen en wensen te formuleren die er aan een auto zijn. U overlegt met andere autorijders en komt met een hele lijst:
- De auto moet plaats bieden aan 4 personen
- De auto moet een stuur linksvoor hebben, een rempedaal, een gaspedaal, een handrem
- De auto heeft 4 wielen
- De auto heeft witte koplampen en rode achterlichten enz. enz. (In de realiteit zou het een enorme lijst worden.)
De ontwerpers maken op basis van uw lijst een nieuw ontwerp, dat vervolgens, maanden later, gebouwd wordt. Dan, u loopt over straat en ziet een auto remmen. U realiseert zich dat u in deze lijst vergeten bent de remlichten te noemen! U belt onmiddellijk met de ingenieur van de autofabriek die zowat ontploft van uw telefoontje. U oppert nog dat het slechts om een kleinigheidje gaat. Maar voor de autobouwers is het rampzalig. De gemaakte auto’s moeten helemaal opengemaakt worden, er moeten kabels van de rempedalen naar achteren getrokken worden, het ontwerp van de achterkant moet helemaal opnieuw om ruimte te bieden voor de remlichten, de achterkleppen die al geproduceerd zijn moeten worden weggegooid, en ga zo maar door.
Bovenstaand voorbeeld lijkt misschien wat absurd maar bij softwareontwikkeling is het bijna dagelijkse realiteit. Programmeurs gaan er ten onrechte vanuit dat de opdrachtgever, klant of gebruiker van nieuw te ontwikkelen software precies weet wat hij wil. De opdrachtgever gaat er ten onrechte van uit dat de softwarebouwers in de kortste tijd alles kunnen maken (en aanpassen). Dit probleem is de grootste oorzaak van conflicten tussen klanten en softwarebouwers.
En dat er veel conflicten zijn tussen klanten en softwareleveranciers blijkt wel uit het volgende. Een startende ondernemer wilde een rechtsbijstandverzekering voor zijn bedrijf afsluiten. Hij informeerde naar de mogelijkheden. De tussenpersoon vroeg in welke branche de ondernemer actief zou zijn, waarop hij ‘ICT’ antwoordde. “Helaas dan”, reageerde de tussenpersoon, “er zijn zo vaak rechtszaken tussen ICT- leveranciers en klanten dat er geen verzekeraar meer is die voor ICT-bedrijven een rechtsbijstandsverzekering wil afsluiten”.
Het schatten van de benodigde hoeveelheid tijd is moeilijk
Het watervalmodel gaat uit van een aantal fasen. In het projectplan moet de projectleider een schatting maken van de hoeveelheid tijd (en dus geld) die nodig is voor elke fase. We hebben al gezien dat het inschatten van de factor tijd lastig is bij projecten in zijn algemeenheid. Met name als die schatting gegeven moet worden in het beginstadium van het project. Voor softwareprojecten is het schier onmogelijk. Stel dat het zou lukken een kwalitatief goede lijst van functionaliteiten op te stellen in de definitiefase. In theorie zou het projectteam dan per functionaliteit redelijk moeten kunnen inschatten hoeveel tijd er nodig is voor de realisatie. De praktijk laat echter zien dat er te veel onzekerheden zijn om een redelijke inschatting te kunnen maken (o.a. McConnell, 1996):
Als functionaliteit gemaakt is, blijkt nogal eens dat de klant hem toch niet nodig heeft. De gebruikte uren zijn als nutteloos te beschouwen.
Eisen en wensen veranderen gedurende het project.
Moet de functionaliteit goedkoop of duur worden uitgevoerd? Er zijn vele manieren van realisatie en implementatie mogelijk.
Hoe wordt functionaliteit technisch ontworpen? Het ontwerp bepaalt in grote mate de tijd die nodig is voor het maken ervan.
Hoe goed moet de kwaliteit zijn van functionaliteit? Bijvoorbeeld moet een webapplicatie altijd 100% beschikbaar zijn, of mag hij een paar uur per jaar offline zijn?
Het vinden en herstellen van fouten in software varieert van minuten tot weken.
Hoelang duurt de installatie en integratie van de nieuwe software bij de bestaande systemen van de klant?
Het ontbreken van kennis over mogelijke oplossingen maakt het schatten van de benodigde hoeveelheid tijd ook moeilijk. Het is daarbij ook moeilijk in te schatten hoelang het verkrijgen van de benodigde kennis duurt.
Uit bovenstaande lijst blijkt dat er heel veel factoren zijn die van invloed zijn op de hoeveelheid tijd die uiteindelijk nodig blijkt te zijn voor de realisatie van software. Uit onderzoek (McConnell, 1996, p. 168) is gebleken dat de schattingen voor de benodigde tijd voor het realiseren van functionaliteit in het begin van een project varieert tussen vier keer te weinig tijd en vier keer te veel tijd. Dat betekent bij een verkeerde schatting dat de benodigde hoeveelheid tijd 4 maal hoger of lager kan uitvallen. Die schattingen worden nauwkeuriger naarmate het project verder is. Na het maken van een functioneel ontwerp is de marge echter nog altijd tussen de 25% te veel of te weinig. Pas vlak voordat functionaliteit gerealiseerd wordt, kan een schatting met redelijk hoge zekerheid gegeven worden.
Software is nooit 100% foutloos. Zelfs van bekende softwarepakketten waar velen mee werken als Word, Excel, Explorer, OSX, PHP, Flash zijn er lijsten van bekende bugs te vinden op het internet. Er komen geregeld nieuwe releases op de markt waarvan er fouten uit de software gehaald zijn.
Klanten verwachten soms foutloze software maar als dat nagestreefd zou worden in de praktijk zou dat betekenen dat software nooit af is. Bovendien komt het niet zelden voor dat de fout in de software niet in de eigen software zit.
Een educatieve game werd gemaakt in Flash. Afgesproken was dat de game als bestand aangeleverd zou worden en dat de klant hem zelf zou installeren op zijn server. Gedurende het project wilde de klant graag dat er een high score aan de game zou worden toegevoegd om het competitieve element tussen de spelers te verhogen. Daarvoor was een stuk scriptcode nodig in PHP. De gamebouwers maakte die scriptcode en testten die op hun eigen server die op Linux draaide. Het werkte. De game en de scriptcode werden aangeleverd aan de klant. Die klant had echter een Windows server en om de een of andere reden werkte het script niet goed meer. De high scores werden niet opgeslagen.
Uiteindelijk had de programmeur een week nodig om het probleem op te lossen. Het bleek zo te zijn dat de combinatie van PHP en Windows server soms niet goed werkt. In het script zelf zat helemaal geen fout! Door een hack kon hij het werkend krijgen en iedereen was tevreden. Alhoewel, wie moest die week extra werk betalen?
Bij een ander softwareontwikkelingstraject werd ook educatieve software gemaakt. Het probleem was dat de software bij de programmeurs prima werkte, maar bij de klant het niet goed deed. Na van alles geprobeerd te hebben, besloot de programmeur bij de klant op bezoek te gaan. Daar bleek dat de computer van de klant een oude pentium III was. Door de traagheid van de computer deed de software het niet goed. Bij de programmeurs was echter ook getest op een pentium III en daar werkte het prima. Na verder onderzoek bleek dat de computer van de klant zo traag was omdat het systeem vol zat met virussen en spyware.
Bovenstaande onzekerheid maakt het schrijven van projectplannen niet eenvoudiger. Ook het maken van afspraken tussen betrokken partijen wordt er lastig door. Iemand moet het risico dragen voor het meerwerk dat gedaan moet worden. Als er betaald wordt op uurbasis, dan ligt het risico bij de klant. Als er een fixed price is afgesproken (zoals bij subsidiefinancieringen), ligt het risico bij de softwarebouwer. Als er meer dan twee partijen bij zijn betrokken, ligt het nog complexer. Wie betaalt er dan voor de meeruren op een project?
Vaak ontstaat er een discussie over wie er verantwoordelijk is voor de vertragingen. Het aanwijzen van een schuldige is in veel gevallen heel moeilijk. En wellicht is er überhaupt geen schuldige omdat er geen sprake is van vertraging, maar van een verkeerde inschatting van de hoeveelheid uren in de eerste plaats. Het overschrijden van het aantal projecturen en de vraag wie dat moet betalen, is een bron van conflicten in de IT-wereld.
Het is wenselijk dat alle tussenresultaten door de gebruiker gedurende het traject getest kunnen worden
In de definitiefase en de ontwerpfase wordt van klanten gevraagd hun eisen en wensen zo goed mogelijk te formuleren. Dat is lastig om twee redenen. Ten eerste hebben klanten maar een beperkte voorstelling van de (on)mogelijkheden van ICT. Ze weten niet goed wat er kan of zou kunnen en dus weten ze ook niet goed wat ze wel of niet moeten wensen. Ten tweede hebben klanten vaak maar een beperkte kennis van hun eigen bedrijfsprocessen. Veel ICT-projecten gaan over het automatiseren van bestaande bedrijfsprocessen bij een klant. Hoewel de klant misschien al vele jaren volgens die processen werkt, blijkt vaak dat hij niet goed in staat is om zijn eigen bedrijfsproces te definiëren. Hij kan prima op zijn eigen manier werken, maar hij kan niet zeggen welke manier dat nu precies is. Deze precieze definiëring van processen is wel een voorwaarde voor het maken van software die de automatisering zal aansturen. De complexiteit voor klant neemt daarbij toe als hij ook nog eens niet bestaande processen moet gaan beschrijven.
Vaak zie je dat er in de definitiefase een eisen- en wensenlijst op tafel komt die onvolledig is. In de realisatiefase maken de programmeurs de software op basis van die onvolledige lijst. Wanneer de gebruiker dan de eerste versies van de nieuwe software voorgeschoteld krijgt, komen er meer eisen en wensen op tafel. Dat ziet er goed uit, kan je het nu ook zo maken dat ik met een knopje kan inloggen zodat ik niet steeds mijn password hoef te herhalen. De programmeurs verzuchten dat de klant niet weet wat ie wil. De klant beroept zich op het ‘feit’ dat de softwareontwikkelaars professionals zijn en eerder hadden moeten inzien dat de klant dat wilde.
Bij een softwareproject voor de automatische afhandeling van aanvragen voor een dienst via het web was een uitgebreid functioneel ontwerp gemaakt. Lange lijsten van eisen en wensen van de klant waren opgesteld. Een aantal schermontwerpen en flow charts waren toegevoegd waarna de programmeurs aan de slag konden.
Wellicht omdat het project onder grote tijdsdruk stond of misschien omdat de organisatie van de klant behoorlijk rommelig was, bleek dat de ontwerpers een belangrijk onderdeel waren vergeten: handmatig beheer.
De aanvragen werden door de software verwerkt. Omdat het verwerken van de aanvragen automatisch zou moeten verlopen, dachten de programmeurs dat er geen handmatig beheer gewenst zou zijn. Die eis stond ook niet in het functioneel ontwerp. Toen de software werd opgeleverd om te testen, realiseerde de klant zich dat er uitzonderingen waren bij de aanvragen. Sommige aanvragen mochten niet automatisch verwerkt worden maar moesten handmatig verwerkt worden. De software werkte echter alleen automatisch…
In het watervalmodel wordt het gerealiseerde projectresultaat getest aan het einde van de realisatiefase. Dat is laat in het ontwikkelingstraject. In de tijd liggen er meerdere maanden, soms zelfs meer dan een jaar, tussen de definitiefase, ontwerpfase en de realisatiefase. Als er in een laat stadium fouten in het ontwerp boven water komen, is het duur of soms zelfs onmogelijk om de software nog aan te passen, zonder een geheel nieuw project te starten. Omdat we gezien hebben dat het eigenlijk onmogelijk is alle eisen en wensen vooraf goed te definiëren zou een werkwijze wenselijk zijn waarbij het mogelijk is om (tussen) resultaten eerder te testen. De terugkoppeling moet veel eerder komen zodat er betere besluiten genomen kunnen worden.
Bij de keuze voor een softwarehuis werden enkele partijen vergeleken. De klant vroeg bij de concurrerende partijen wat er zoal mogelijk was. De ene partij was wat terughoudend en had zijn twijfels of bepaalde klantwensen wel zonder meer uitvoerbaar waren. De andere partij had een gedreven verkoper in dienst. Als de klant aan de verkoper vroeg of een bepaalde wens mogelijk was, belde hij met een van zijn programmeurs. Kunnen wij een functionaliteit bouwen die X kan? De programmeur dacht voornamelijk in termen van techniek en antwoordde daarop dat in principe alles mogelijk was. De programmeur en de verkoper maakten zich beiden niet druk om de haalbaarheid in termen van projectmanagement (tijd, geld, complexiteit, risico’s, en dergelijke).
Het enthousiasme van de verkoper werkte beter dan de wat terughoudende houding van de andere partij. De klant koos voor de aanbieding van de gedreven verkoper. Het vers binnengehaalde project kwam vervolgens in handen van een projectleider en een groep programmeurs. Na verloop van tijd bleek dat het project niet voldeed aan de wensen van de klant. Dat had onder andere te maken met het feit dat de processen bij de klant veel ingewikkelder bleken dan op het eerste oog leek. Bij een zwaar weer gesprek tussen beide partijen beriep de klant zich op het feit dat de verkoper had gezegd dat functionaliteit X geen enkel probleem zou zijn.
Agile (Cyclische) projectmanagementmethodes
Door bovengeschetste problematiek zijn er de afgelopen jaren andere methodes voor projectmanagement ontstaan die met name worden toegepast bij ICT- ontwikkelprojecten. DSDM, SCRUM, RUP, eXtreme Programming (XP), RAD, agile projectmanagement, zijn enkele van de namen van deze relatief nieuwe stromingen binnen projectmanagement (McConnell, 1996, Kroll, 2004, Chromatic, 2003, Stapleton, 2002, [ii], [iii])
Hoewel bovenstaande projectmanagementmethodes op aspecten van elkaar verschillen, komen ze in essentie overeen. Omdat de weg naar het einddoel bij ICT-projecten zo onzeker is gebleken, gaan deze methodes uit van het bereiken van het doel in een aantal korte cyclussen. Vandaar de benaming ‘cyclisch’ projectmanagement voor deze methodes. Omdat niet alles vooraf vaststaat vooraf in het proces worden ze ook wel ‘Agile’ methodieken genoemd.
Bij cyclisch projectmanagement tracht men bij het projectdoel te komen middels enkele korte cycli die na elkaar plaatsvinden. Elke cyclus duurt relatief kort, bij voorkeur korter dan een maand. Binnen een cyclus wordt een deel van het project uitgevoerd. Binnen een cyclus wordt geanalyseerd, ontworpen, gerealiseerd en getest. Dit is wezenlijk anders dan bij de watervalmethode waar die activiteiten allemaal in een eigen fase plaatsvinden. Bij de watervalmethode wordt bovendien maar éénmaal gedefinieerd, ontworpen, gerealiseerd en getest. Bij de cyclische methodes gebeurt dat vele malen na elkaar.
Tijdens de cycli worden verschillende onderdelen van de software gerealiseerd. De cycli staan daarmee maar deels los van elkaar. Nadat een cyclus is afgerond vindt evaluatie plaats. Mocht het zo zijn dat door voortschrijdent inzicht er nieuwe of andere eisen aan het project zijn ontstaan, dan worden de werkzaamheden van de komende cycli daarop aangepast.
Een cyclus begint bij het maken of bijstellen van de planning. Vervolgens worden de eisen- en wensen onderzocht van hetgeen dat gemaakt moet worden in deze cyclus. Er wordt een ontwerp gemaakt, dit ontwerp wordt geprogrammeerd en getest. Vervolgens vindt evaluatie plaats en bij sommige methodes ook in gebruikname van de nieuwe software. Daarna kan de volgende cyclus starten om het volgende deel van het project uit te voeren. (Voor een meer uitvoerige beschrijving van cyclische methodes en de verschillen tussen de methodieken zie onder andere Kroll, 2004, Chromatic, 2003, Stapleton 2002.)
De grote voordelen van het werken met een agile methode zijn:
- Hogere kwaliteit van het product en betere implementatie van functionaliteiten
- Realistischer begroting van tijd en geld
- Projectteam komt minder onder druk te staan
Hogere kwaliteit
Uit vorige hoofdstukken is gebleken dat het moeilijk of wellicht onmogelijk is om in een vroeg stadium in het project de gewenste functionaliteiten goed te bepalen. In de cyclische methoden worden de gewenste functionaliteiten middels enkele korte cycli gerealiseerd. Per cyclus wordt een klein deel van de gewenste functionaliteit niet alleen onderzocht, maar ook ontworpen, gerealiseerd, eventueel geïmplementeerd én getest. Met name het kort opeenvolgen van ontwerpen, realiseren en testen leidt tot betere kwaliteit. Het maakt dat het team in staat is aanpassingen te doen. Als een ontwerp in de praktijk niet goed uitpakt, wordt dit binnen het tijdvak van de cyclus duidelijk. Er kan dan bijgestuurd worden. Binnen deze manier van werken kan de klant dus vragen om aanpassingen.
Een andere reden dat cyclisch projectmanagement tot betere kwaliteit leidt is omdat er in een cyclus intensief wordt samengewerkt tussen klant, ontwerpers en programmeurs. Er is een multidisciplinair team dat gezamenlijk oplossingen bedenkt en uitvoert. Bij de watervalmethode is de klant vooral in het begin aan het woord bij het formuleren van de eisen en wensen, daarna maken ontwerpers een ontwerp en vervolgens programmeren de programmeurs de software. De projectleider is de schakel tussen al die partijen en moet ervoor zorgen dat de informatie over en weer terecht komt. In de praktijk betekent het bijvoorbeeld dat veel programmeurs en ontwerpers de klant nooit zien. Die komt pas weer in beeld als de software af is.
Cyclische (agile) projectmanagement methodes zijn vooral goed voor projecten waarbij men het te bereiken doel vooraf niet goed kan vaststellen, zoals creatieve projecten of onderzoeksprojecten. Door te werken in een aantal cycli met een multidisciplinair team waarin de eindgebruikers ook vertegenwoordigd zijn, leert het team wat nu eigenlijk echt de bedoeling is van het project en hoe dat het beste bereikt kan worden. In elke cyclus zit een reflectiemoment en is er de mogelijkheid tot bijsturen.
Bij waterval projecten wordt vooraf een doel geformuleerd. Reflectie op het oorspronkelijke doel is in mindere mate mogelijk. Het oorspronkelijk geformuleerde doel wordt niet (geheel) bereikt. En geconstateerd wordt dat zowel het oorspronkelijk geformuleerde doel als het bereikte doel helemaal niet de daadwerkelijk gewenste doelen zijn.
De laatste reden waarom een cyclische projectmethodiek tot een beter resultaat leidt is dat de klant na elke cyclus acceptatietests uitvoert. Bovendien wordt de kwaliteit verder verstevigd door van meet af aan uit te gaan van tests als criterium voor goed werkende functionaliteit. Programmeurs moeten daarvoor voordat ze hun code gaan schrijven zogenaamde ‘falende tests’ definiëren (unit tests). Alleen als de code de falende test passeert, is hij goed.
Hoe werkt testgericht werken? Bij testgericht werken moet de programmeur voordat hij nieuwe code schrijft, bewijzen dat er geen bugs in de nieuwe code zitten. Dit doet hij door een test te bedenken die een eventuele bug aan zal wijzen (falende tests), voordat hij gaat coderen.
Bijvoorbeeld, stel dat een programma gemaakt moet worden voor het berekenen van de juiste hoeveelheid wisselgeld die je moet terugkrijgen van een snoepmachine. Allereerst moet er getest worden of er al een functie bestaat die wisselgeld geeft. Deze functie wordt ‘geef wisselgeld’ genoemd. Een simpele test zal gemaakt worden en als die uitgevoerd wordt dan zal er blijken dat er nog niet een functie ‘geef wisselgeld’ bestaat. Wanneer de programmeur vervolgens de functie aanmaakt maar nog geen inhoud geeft, zal deze test slagen.
De volgende stap is dat getest moet worden of de machine de juiste hoeveelheid geld teruggeeft als er iets gekocht wordt. Stop 60 cent in de machine en koop een item van 50 cent. De test zal niet slagen, want de functie is nog leeg. De programmeur zal vervolgens de code schrijven. In de functie ‘geef wisselgeld’ schrijft hij dat de hoeveelheid terug te geven wisselgeld de hoeveelheid geld is die er in de machine is gestopt minus de kostprijs van het gekozen snoep. De test zou nu moeten slagen. Enzovoort, voor elk deel van de software moet vooraf een test bedacht worden (voorbeeld vertaald en aangepast uit Chromatic, 2003, p. 27 e.v.).
Niet alleen de code moet (technisch) getest worden, ook de functionaliteiten moeten getest worden (acceptatie tests). Daarvoor moet de klant voor het coderen bepalen onder welke condities de nieuw te bouwen functionaliteiten geaccepteerd gaan worden. Bijvoorbeeld hoe snel een computer moet reageren op een bepaalde actie van een gebruiker. Met name het vooraf aangeven onder welke condities de nieuwe functionaliteit geaccepteerd zal worden, blijkt moeilijk en tijdrovend. Toch is de actieve rol van klanten bij het testen zeer bepalend voor het succes van het project.
Realistischer begroting van tijd en geld.
Bij een cyclische projectmethodiek worden de te realiseren functionaliteiten niet vastgepind aan het begin van het project. De beschikbare tijd wordt wel vastgelegd. Afgesproken wordt welke richting het project opgaat en onderweg wordt gekeken wat echt nodig, zinnig en realistisch is met betrekking tot de nieuw te maken software. Bij cyclische projecten worden dus niet de te realiseren functionaliteiten als vaststaand doel beschouwd, met als risico dat de benodigde uren (en dus benodigd geld) extreem uit de hand kunnen lopen. Om dat te voorkomen wordt de beschikbare tijd als uitgangspunt genomen en wordt gaandeweg gekeken wat men op realistische wijze kan maken in de beschikbare tijd.
Dit is ook de reden dat cyclische projectmanagementmethodes veel vriendelijker zijn voor het projectteam. Het team doet wat het kan in de gestelde tijd maar wordt niet onder druk gezet om onrealistische planningen te halen of te werken met veel te krappe begrotingen.
Ook het beheersen van externe leveranciers is gemakkelijker. Bij de watervalmethode zit je op een gegeven moment helemaal vast aan één leverancier tot het einde van het project, of die leverancier nu goed presteert of niet. Bij de cyclische werkwijze is het in principe mogelijk om per cyclus of zelfs per op te leveren component afspraken te maken en desnoods te wisselen van leverancier.
Voorwaarden voor agile projectmanagement
Om Agile projectmanagement te kunnen toepassen moet aan een aantal voorwaarden voldaan zijn:
- Actieve betrokkenheid van gebruikers/klanten
Bij agile projectmanagement vindt het opstellen van eisen- en wensen, het ontwerpen, realiseren en testen in elke cyclus plaats. Dat betekent dat er veel beslissingen genomen moeten worden in een cyclus. Om in staat te zijn de wensen van de klant goed te laten uitkomen in de software, moet de klant actief meedoen in het projectteam. Hij moet zo goed mogelijk zijn wensen uitleggen aan de programmeurs en ontwerpers. Men moet denken aan wekelijkse of minimaal tweewekelijkse aanwezigheid in het projectteam.
Klanten houden zich binnen het project bezig met het bepalen van de gewenste functionaliteiten en de planning van de cycli. Ze denken mee over de acceptatietests, ze keuren tussenresultaten goed of af en denken mee over de algemene richting van het project. Overigens geldt ook voor de watervalmethode dat een actieve opstelling van de klant tot betere resultaten leidt.
- Team mag besluiten nemen
Binnen een cyclus moet het projectteam geautoriseerd zijn om dat te doen wat het denkt dat het beste is. Als het projectteam niet deze macht heeft, werkt het cyclische projectmanagementmodel niet. Wanneer er tijdens een cyclus constant autorisatie nodig is van meerderen, zal dit leiden tot stagnatie. Bovendien weten buitenstaanders vaak niet goed wat er speelt omdat ze niet actief deelnemen in het projectteam, wat het voor hen moeilijk maakt zinnige beslissingen te nemen.
- Projectresultaat is opdeelbaar in kleinere delen
Bij agile projectmanagement worden delen van het project uitgevoerd in een aantal cycli. Dat kan alleen als het te realiseren projectresultaat opdeelbaar is in een aantal min of meer los van elkaar staande onderdelen, die onafhankelijk van elkaar ook veranderd kunnen worden. Dat kan meestal wel bij software ontwikkelingsprojecten, bij andere projectresultaten (zoals bijvoorbeeld grote infrastructuurprojecten) is dat niet altijd het geval
- Vanuit het management worden voornamelijk globale eisen ten aanzien van de software gesteld en niet direct concrete en specifieke eisen.
Een van de sterke punten van cyclisch projectmanagement is dat de klant, ontwerpers, programmeurs en eventueel testers nauw samenwerken binnen de cycli. Als er bij het project al direct in het begin heel specifieke en concrete eisen zijn gesteld aan de op te leveren software, dan belemmert dat de vrijheid van het projectteam om naar eigen inzicht ontwerpkeuzes te maken. Veel eisen aan een project blijken gaandeweg aangepast te moeten worden en moeten dus niet in het begin (te) vastliggen.
- De activiteiten zijn voor de klant inzichtelijk
Als er binnen een cyclus veel technisch werk moet gebeuren, dat te moeilijk te begrijpen is voor de klant, bestaat er een risico dat hij niet in staat is goed mee te doen met het team. Hij heeft feitelijk niet veel in te brengen bij de ontwerp-beslissingen die genomen moeten worden.
Een dergelijk risico bestaat ook wanneer de voortgang voor de klant niet goed zichtbaar is. Bijvoorbeeld omdat er veel aan de code gewerkt is en minder aan de gebruikersinterface. Het is belangrijk dat de klant voldoende inzicht heeft in de inhoud en in de voortgang van een cyclus om ervoor te zorgen dat hij niet buiten spel komt te staan.
- Een stap terug moet mogelijk zijn.
Ook bij agile projectmanagement bewandelt het team soms een weg, waarvan men later moet concluderen dat het niet de juiste was. Dan moet het mogelijk zijn om een stap terug te doen. Als een nieuwe module is gemaakt in een cyclus en het blijkt dat hij niet bevalt, moet de oude module terug in gebruik kunnen worden genomen. Dit stelt met name eisen aan de archivering en documentatie van de projectmaterialen. CVS (Concurrent Versioning Systeem) of Subversion zijn hier bijvoorbeeld een nuttig hulpmiddel voor (zie bijlage 3 voor een lijst van hulpmiddelen).
- Programmeurs moeten naast programmeren ook kunnen communiceren met klanten en vice versa. Teamleden moeten in staat zijn conceptueel te denken. Discipline is nodig om het testgericht werken vol te houden. Hetzelfde geldt voor niet ICT agile teams.
- De organisatie waarbinnen het project plaatsvindt moet ook voldoende steun bieden aan deze manier van werken. Systemen voor tijdschrijven, archivering en planning zijn nodig om de projecten te ondersteunen. Deze registratiesystemen zorgen voor de transparantie welke nodig is voor een goede verdeling van resources over de projecten en in de tijd.
- Projecten moeten voldoende prioriteit hebben, teamleden moeten worden vrijgemaakt voor projecten. Het werkt niet als teamleden in veel projecten tegelijk moeten werken. Als een organisatie onvoldoende ingesteld is op het werken met projecten dan zal de lenigheid van agile projectmanagement eerder tot chaos leiden. Overigens is de watervalmethode ook gebaat bij een organisatie die ingesteld is op het werken met projecten (zie Wijnen, 2004, p. 111).
Een directeur van een softwarehuis die meer een visionair was dan een manager had bijna elke maand een goed idee en startte voortdurend nieuwe projecten in zijn bedrijf. Daardoor werden oude projecten nooit helemaal afgemaakt en deden de medewerkers soms wel vijf projecten tegelijk. De charismatische directeur had wel eens een boekje over rapid application development (RAD) gelezen en was er erg enthousiast over. Met name over het aspect ‘rapid’. Hij had boven het kopieerapparaat de uitgangspunten van RAD opgehangen en ging er vervolgens vanuit dat iedereen wel zou gaan werken volgens die uitgangspunten. Het was immers een prachtige methode.
Risico’s van Agile projectmanagement
Nu kan men opperen dat bij cyclische projectmanagementmethodes (Agile) het zou kunnen voorkomen dat er onvoldoende tijd is voor het realiseren van de gewenste functionaliteiten. De hoeveelheid tijd is immers gefixeerd dus dat betekent dat er wellicht minder functionaliteit gemaakt zou kunnen worden dan aanvankelijk werd aangenomen.
Dit risico is inderdaad aanwezig, maar bestaat ook bij de watervalmethode. Bij de watervalmethode is er in de definitiefase een uitgebreide analyse van eisen en wensen. Op basis van die analyse zou je verwachten dat een betere planning van tijd mogelijk is. In de praktijk blijkt dit vaak niet het geval, om eerdergenoemde redenen, en worden functionaliteiten uiteindelijk eveneens weggelaten, omdat het geld op is om ze te kunnen realiseren.
Bij cyclische methodieken wordt er op een pragmatische wijze omgegaan met eisen en wensen. Bijvoorbeeld door per cyclus de eisen en wensen in te delen volgens de MoSCoW regels (Stapleton, 2003):
- Must Have: eisen die essentieel zijn voor het systeem
- Should Have: belangrijke eisen die men graag wil
- Could Have: eisen die wenselijk zijn, maar die eenvoudig weggelaten kunnen worden
- Want to Have: but will not have this time round: eisen die wel kunnen wachten tot later
Ondanks dat het zou kunnen dat er voor bepaalde functionaliteiten geen tijd meer is, is de algemene consensus onder de projectmanagers van DANS dat cyclisch werken tot meer klanttevredenheid leidt dan de watervalmethode. In ieder geval worden de verwachtingen over en weer beter gemanaged en wordt er iets opgeleverd wat aantoonbaar werkt, al is dat wellicht minder uitgebreid dan aanvankelijk gehoopt.
Als nadeel van Agile wordt vaak genoemd dat er veel macht bij de programmeurs komt te liggen. Als ze die macht misbruiken kunnen ze zich verschuilen achter het gebrek aan technische kennis bij de klant. Om dit te voorkomen is een sterke projectleider nodig die zowel de belangen van de programmeurs als die van de klant behartigt. Deze projectleider assisteert de klant bij het kiezen en plannen van de cycli, het inzichtelijk maken van de technische achtergronden bij keuzes en het uithanden nemen van administratie en rapportage.
Tenslotte kan nog als nadeel van Agile worden aangehaald dat er een steile leercurve is met betrekking tot de introductie van de methodiek bij zowel programmeurs, management als klanten.
