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.
Figuur 9: De activiteiten in een cyclus
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.
Figuur 10: Door agile te werken wordt een beter resultaat bereikt (Illustratie: Rachèl Harmsen)
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.