Bij Agile-systeemontwikkeling wordt niet veel aandacht besteed aan het schrijven van documentatie. Schrikbeelden uit het verleden van stapels documentatie die nooit geraadpleegd werd, is een belangrijke oorzaak hiervan. Maar schieten we niet te ver door? Gaan we er niet te gemakkelijk vanuit dat we geen documentatie nodig hebben?
Tegenwoordig wordt veel software ontwikkeld volgens een Agile-methodiek, zoals Scrum. Eén van de onderliggende principes van Agile-softwareontwikkeling is: ‘we value working software over comprehensive documentation’ (manifesto for Agile software development). Dat betekent natuurlijk niet dat er geen documentatie meer gemaakt moet worden, maar dat we niet meer tijd willen besteden aan het schrijven van documentatie dan strikt noodzakelijk is.
Dat brengt ons bij de volgende vraag: welke documentatie hebben we minimaal nodig en hoe zorgen we ervoor dat we voldoende tijd besteden aan het schrijven van deze documentatie? Het antwoord op deze vraag is niet eenvoudig te geven en dat leidt er in de praktijk vaak toe dat er vaak te weinig documentatie gemaakt wordt.
Als er al documentatie gemaakt wordt, gaat het vaak om ontwerpdocumentatie (use cases, class diagrams die bij het ontwerpen van de software gebruikt zijn). Het is de vraag of dit geschikte documentatie is, omdat de kans aanwezig is dat de software die gebouwd is, niet volledig gebouwd is volgens de gemaakte ontwerpen, bijvoorbeeld omdat er in een later stadium toch nog wat wijzigingen waren of doordat bleek dat er in het ontwerpstadium nog geen volledig beeld bestond van wat er precies gebouwd moest gaan worden. Zeker bij iteratieve methodieken (bijvoorbeeld Scrum) wordt in elke iteratie een stukje functionaliteit gebouwd, maar meestal wordt niet in elke iteratie de ontwerpdocumentatie bijgewerkt of aangevuld.
Door aan het eind van een project alle geproduceerde ontwerpdocumentatie op een hoop te vegen en er de sticker ‘Systeemdocumentatie’ op te plakken, lopen we het risico dat we documentatie opleveren die niet overeen komt met de opgeleverde software. Dergelijke documentatie heeft geen toegevoegde waarde, sterker nog, het wekt de indruk dat er documentatie is, terwijl dat niet het geval is.
Als we serieus software willen ontwikkelen volgens Agile-principes, zullen we van tevoren moeten vaststellen welke documentatie we minimaal nodig denken te hebben om het systeem in de toekomst te kunnen onderhouden en doorontwikkelen. Die documentatie hoort op de sprint backlog te staan en als onderdeel van het project opgeleverd te worden. We zullen ervoor moeten zorgen dat die documentatie actueel is en een correcte beschrijving is van het gebouwde product. Als we dat niet doen, verhogen we wellicht onze velocity, maar schuiven we de rekening naar de toekomst.
al die meningen… In Scrum is er maar 1 die bepaalt wat de deliverables zijn en of die nodig zijn : De productowner
Dat documentatie niet geheel up-to-date is, is niet nieuw. Hier hebben we ook last van bij traditionele systeemontwikkeling.
Maak elke partij die documentatie wil, zelf verantwoordelijk voor die documentatie. Dat lijkt goed te werken. En om ervoor te zorgen dat de kwaliteit van die documentatie op orde blijft, neem ik in de Definition of Done op dat de documentatie up-to-date moet zijn. Goed versiebeheer en tracebility is uiteraard een must in deze.