In vorige blogs schreef ik dat het van belang is werkende software op te leveren. Dat is ook waar, maar hoe logisch het ook klinkt, het wordt vaak vergeten. Vooral in grote programma's bestaat de neiging om vooral eerst veel plannen te maken, waardoor de aandacht voor het opleveren van het eindproduct verzwakt en naar de toekomst wordt verschoven.
De vele planningen, designs, testmatrices en change requests leiden tot een soort tweede werkelijkheid. Deze tweede werkelijkheid maskeert waar het project echt om draait: het werkende eindproduct.
Een vraag die mij met enige regelmaat gesteld wordt is: 'Wanneer je zo focust op de werkende software, krijg ik dan mijn documentatie nog wel?' Het antwoord, zoals ook kort besproken in mijn vorige blog, is natuurlijk: 'Ja, je krijgt documentatie.'
Tenminste als je dat wilt. Het gaat om prioriteitstelling. Dus als documentatie belangrijk is in jouw project of organisatie, dan moet documentatie onderdeel zijn van de oplevering.

In Agile trajecten wordt het concept van de 'Definition of Done' (DoD) gebruikt. Deze definitie geeft aan wat de omvang moet zijn van je opleveringen voordat ze "af" beschouwd en geaccepteerd worden als oplevering aan het einde van een sprint.
Deze DoD wordt in gezamenlijkheid tussen het team en de product owner (vertegenwoordiger van de business) opgesteld. Dus als je aan een groot project werkt, dat moet opleveren aan een beheerorganisatie die ook systeemdocumentatie verwacht, dan ligt het voor de hand dat de systeemdocumentatie opgenomen is in de DoD. Hetzelfde kan gelden voor bijvoorbeeld gebruikersdocumentatie.
Nog een opmerking over systeemdocumentatie. Meestal wordt hierbij gedacht aan Office documenten met specificaties en diagrammen erin. Naar mijn mening kan systeemdocumentatie beter bestaan uit bijv. unit test scipts en testresultaten, user stories en annotaties in de softwarecode dan een ordner met documentatie die nooit gebruikt en ook ook niet actueel gehouden wordt.
Samenvattend, zorg voor focus op het eindproduct en heb binnen je projectorganisatie een eenduidig beeld van de vorm en omvang van de eindproducten. De DoD definieert vervolgens hoe je kunt vaststellen of de opgeleverde producten ook daadwerkelijk af zijn en wat je daarvoor als team op moet leveren. Vraag bij alles wat je doet en oplevert af of het zinvol is en prioriteit verdient.
Er zijn nog geen reacties
Let op: Uw reactie wordt gepubliceerd. Voor privé-reacties kunt u rechtstreeks mailen met de auteur. Voor contact mogelijkheden bekijk het auteur profiel van Michiel de Vries
Michiel de Vries is Manager bij Deloitte Consulting en werkzaam als Project Manager in complexe projecten met een IT component. Zijn specialiteit is het adviseren over en opzetten van projectorganisaties voor software ontwikkeling.
Lees Meer in Profiel