Een project is geslaagd, heeft voldoende kwaliteit, als de klant tevreden is. Wanneer is de klant tevreden? Als hij krijgt waar hij om heeft gevraagd tegen de afgesproken prijs en op het afgesproken tijdstip. Deze drie factoren zijn dan ook de voornaamste redenen waarom meer dan helft van alle software ontwikkeltrajecten als mislukt worden beschouwd. We kennen allemaal zulke projecten. Vanuit deze gedeelde ervaring is DSDM(Dynamic Systems Development Method) ontwikkeld. DSDM biedt een Framework, handvatten en gereedschappen om zowel ontwikkelaar als klant steeds de zekerheid te geven dat het project een kwalitatief goede oplossing voor de klant zal opleveren.
Download:
Powerpoint-presentatie: DSDMSmallProjects.zip (107Kb)
Frits Ankersmit is werkzaam bij Class-a. Heeft een rijk verleden in de automatisering op diverse terreinen. Van training tot projectleiding maar ook als ontwikkelaar heeft Frits zijn handen vies gemaakt.
Bij het uitvoeren van ons werk komen we allemaal in aanraking met de "Duivelsdriehoek": tijd, geld en functionaliteit. Trek je aan de ene kant, dan heeft dat gevolgen voor de andere kant. De meeste projecten kennen een vaste set van functionele specificaties. Deze moeten we binnen een bepaalde tijd of binnen een bepaald budget (of beide) bouwen. Vaak lukt dat niet, waardoor er òf meer tijd, òf meer geld (of beide) bij moet. Dat vindt de opdrachtgever niet fijn.
In plaats van de functionaliteit zet DSDM (Dynamic Systems Development Method) juist de twee andere punten, tijd en geld, vast. DSDM speelt met de functionaliteit. Om dit te kunnen doen is bij alle betrokkenen (opdrachtgever, opdrachtnemer en alle andere spelers) de bereidheid nodig om zaken naar belangrijkheid te ordenen, om gedurende het project nog eens kritisch naar deze belangrijkheid te kijken en waar nodig wijzigingen mogelijk te maken. Het motto is "all changes are reversible", maar dat heeft - uiteraard - zijn prijs.
Een van de methodes waar DSDM gebruik van maakt, is de MoSCoW methode. Hierin worden alle punten waaraan het project moet voldoen, beschreven in klant-terminologie en worden ze opgedeeld in Must have's (doorgaans ca. 60% van de punten), Should have's (20%), Could have's (10%) en Want to have's (10%). Voorts wordt bij DSDM niet een uitgebreid functioneel ontwerp gemaakt, maar wordt al doende ontwikkeld. Indien door voortschrijdend inzicht de gestelde deadline (tijd) niet gehaald dreigt te worden, wordt in overleg bepaald welke punten niet in dit traject gerealiseerd gaan worden.
Er wordt alles op alles gezet om een werkbaar produkt binnen de gestelde termijn en het geschikbare budget op te leveren. Kan dat echt niet, dan wordt het project gestaakt. Vaak spelen dan andere, verborgen agendapunten een rol.
Dat theorie en praktijk weleens uiteenlopen bleek ook tijdens deze presentatie. Ondanks alle voorbereidingen lukte het Frits niet om alle Powerpoint-slides in de beschikbare tijd te behandelen. Zelfs het overslaan van een aantal punten om toch nog de 12 slides met tips en tricks in de blessuretijd door te nemen, strandde bij de vierde slide. Er was te veel om te bespreken en er kwamen te veel vragen. De rest van de tips moeten we dan maar van de SDGN-site downloaden.
Dénise en Bram Laumans
www.ir2.nl