Softwareprojecten maken meestal gebruik van Prince2 als globale projectmanagementmethode. De realisatie wordt vervolgens met andere methodes vormgegeven. Op dit moment is RUP (Rational Unified Process) vrij populair en DSDM (Dynamic System Development Method) wordt ook steeds vaker gebruikt. In Nederland is eXtreme Programming (XP) minder populair.
Dit artikel probeert XP onder de aandacht te brengen als de methode bij uitstek om softwareprojecten beheersbaar en succesvol te laten zijn.
Dit gebeurt aan de hand van twee veelvoorkomende valkuilen bij software-ontwikkelprojecten. In de startfase van een project wordt het bouwen onder architectuur verkeerd geïnterpreteerd. Gedurende het project zijn er krachten aan het werk die vaak ongemerkt de scope van het project veranderen. XP biedt de juiste instrumenten om met deze problemen om te gaan.
Bij professionele softwareprojecten wordt gebouwd onder architectuur, wat wil zeggen dat er een overkoepelende visie en ontwerp is op de ict-huishouding. Elk project moet passen in dit globale beeld en draagt daardoor bij aan het realiseren van een deel van de architectuur. Waarom klinkt dit allemaal logisch, maar leidt het in de praktijk tot grote problemen? Dit heeft alles te maken met de doelstellingen van een project, namelijk binnen een gestelde tijd een softwareproduct bouwen of implementeren (scope) waarbij een bepaald budget niet wordt overschreven. Voldoen aan de eisen van het groter geheel draagt echter niet bij tot het succes of falen van het gebouwde product. Met andere woorden, een project kan heel goed slagen zonder te voldoen aan de architectuur.
‘Bouw nooit iets voor de toekomst’
Een project zal vaker falen als het bouwen binnen de architectuur tot extra inspanningen leidt. Het lijkt erop dat er beter twee projecten gestart kunnen worden: een project om het product te bouwen en een project om het product te herbouwen zodat het in de architectuur past. Het combineren van deze twee doelstellingen in één project is een riskante uitgangssituatie. Het is wellicht efficiënter dan twee aparte projecten, maar de uitkomst van het project is veel moeilijker te voorspellen. Bij eXtreme Programming heeft men daarom de volgende regel opgesteld: ‘Bouw nooit iets voor de toekomst’.
Natuurlijk is het wel aan te raden om bestaande componenten te gebruiken: het heeft geen zin om het wiel opnieuw uit te vinden. We gaan tenslotte ook geen OS, database of webserver meer in elkaar zetten. In die zin is architectuur een gegeven. Ook is het niet meer dan logisch om aan te sluiten bij de bestaande ict-infrastructuur. Ga geen Java gebruiken als alles Microsoft is; gebruik bewezen frameworks en tools. Pas wel op dat het project niet geacht wordt zaken te bouwen ten behoeve van toekomstige producten of projecten!
Nadat de scope van het project is bepaald, wordt de functionaliteit in het algemeen in fases (iteraties of incrementen) verdeeld. Uitgangspunt is vaak dat alle gevraagde functionaliteit geleverd gaat worden. Dit is echter fnuikend als bij het project tijd en geld nagenoeg geen variabelen zijn. De lineaire ‘watervalmethode’ is terecht bekritiseerd vanwege de onmogelijkheid om te managen op scope. Het juiste antwoord van RUP en DSDM hierop is incrementeel iteratief werken (alle fasen worden meerdere keren doorlopen: tijdens elke doorloopcyclus wordt wat toegevoegd – red.) Dit werkt echter alleen als de scope gedurende het project gewijzigd mag worden. Als de scope vastligt, zullen iteraties (herhaald doorlopen van de fasen – red.) gewoon uitlopen. Je bent hooguit wat eerder op de hoogte van de uitloop dan met de watervalmethode.
Functionaliteiten
Bij XP wordt met de klant elke week opnieuw bekeken wat de belangrijkste functionaliteit is die gebouwd moet worden. De volgorde hiervan is dus in hoge mate variabel. Omdat het product steeds meer vorm krijgt, beseft de klant opeens dat bepaalde functionaliteit toch belangrijker is dan eerst gedacht. Of dat de beschreven functionaliteit eigenlijk pas af is als er iets bijkomt. Dit betekent in XP-termen dat er een nieuwe ‘requirement’ (vereiste) wordt opgesteld waardoor een andere requirement moet komen te vervallen, tenzij het project mag uitlopen. Op deze manier wordt de scope beheerd. Elke functionaliteitswijziging wordt expliciet gemaakt en de prijs die betaald moet worden voor nieuwe functionaliteit is onmiddellijk duidelijk. De vrager – en niet de aanbieder – wordt daarmee verantwoordelijk voor de veranderende scope. De valkuil waarin veel projecten terecht komen wordt hierdoor vermeden.
Tijdens het inschatten van de functionaliteiten wordt in principe geen rekening gehouden met het bestaan van de andere functionaliteiten. Dus hoewel de programmeur weet dat als A gebouwd is, B veel sneller klaar zal zijn, wordt de inspanning van B geschat alsof A er niet is, tenzij er heel duidelijk wordt aangegeven dat B pas gekozen kan worden als A af is. Dit gebeurt zo min mogelijk om de keuzevrijheid van de klant niet te beperken.
Snelheidsmeting
Daarnaast wordt bij eXtreme Programming erkend dat er bij elk software-ontwikkelproject een grote mate van onzekerheid is over de snelheid van een project. Veel softwareprojecten hebben een innovatief karakter. Het project is dan in grote mate afhankelijk van de mensen in het ontwikkelteam. Een groter team betekent niet dat de snelheid toeneemt. De snelheid zou zelfs af kunnen nemen. Daarom wordt bij XP de snelheid van het project continu gemeten. Hierdoor neemt de voorspelbaarheid gedurende het project toe. Het zou dus zelfs zo kunnen zijn dat men halverwege kan voorspellen dat men eerder klaar is dan de geschatte einddatum.
Deze onzekerheid van de meeste softwareprojecten is een doorn in het oog van opdrachtgevers. Die willen met een zak geld op een gegeven moment een kant-en-klaar product zien. Juist doordat XP elke dag opnieuw de snelheid beoordeelt, biedt XP de managementtechnieken om een project steeds beheersbaarder te maken. Als er vervolgens een soortgelijk project met hetzelfde team wordt gedraaid, is er bij aanvang al een behoorlijk betrouwbaar beeld van de einddatum. XP leert managers verantwoordelijk om te gaan met goede mensen in goede teams, om te gaan met onzekerheid en onvermijdelijke scopewijzigingen gedurende een project. Kortom, XP is een goede methode voor softwareprojecten.< BR>
Kees Broenink, Softwareontwikkelaar en ontwikkelprocesbegeleider
