Overslaan en naar de inhoud gaan

Agile wordt vaak gezien als alleen maar programmeren en niets documenteren. Documentatie lijkt het ondergeschoven kindje. Onterecht, zeggen Nicole de Swart en Rini van Solingen. De rol van documentatie verandert, maar zij is niet overbodig. Vijf misverstanden over agile en documentatie.

Veel organisaties stappen over op agile systeemontwikkeling om sneller software te kunnen ontwikkelen en sneller te kunnen reageren op nieuwe vragen uit de markt. Snelheid en wendbaarheid worden gezien als cruciale randvoorwaarden voor de toekomst. Kort-cyclisch leveren van werkende en geteste software staat daarbij centraal. Documentatie lijkt dan al snel het kind van de rekening te worden. Voor je het weet start de volgende sprint en is er geen tijd om te documenteren wat er in de vorige is opgeleverd. Dit voedt het misverstand dat het in agile alleen maar gaat om programmeren zonder te documenteren (zie kader). Dit vooroordeel lijkt ook bevestigd te worden door de tweede regel van het Agile Manifest, waarin werkende software boven uitgebreide documentatie wordt gesteld. De waarheid is genuanceerder. Ja, agile stuurt meer op directe resultaten en producten dan op tussenresultaten en documenten. Ja, documentatie wordt gezien als ondersteunend en niet als leidend. Ja, met een agile werkwijze is doorgaans minder documentatie nodig. Maar nee, agile betekent niet alleen maar programmeren en niets documenteren. Agile is focussen op het leveren van zoveel mogelijk waarde, iedere sprint opnieuw. Ook ten aanzien van documentatie wordt daarom een kritische houding verwacht. Niet als vanzelfsprekend alles documenteren, maar bewust afvragen waarvoor die documentatie nodig is en of er geen betere alternatieven zijn.
 

Twee soorten documentatie

De behoefte aan documentatie verandert bij agile werken. Om dit toe te lichten is het nodig onderscheid te maken tussen documentatie ten behoeve van het voortbrengingsproces (vooraf nodig voor het bouwen van de juiste software) en systeemdocumentatie (die achteraf samen met de software wordt opgeleverd). In agile wordt de eerste soort documentatie, voor het voortbrengen van de software, voor een belangrijk deel vervangen door rechtstreekse interactie tussen het ontwikkelteam en de gebruikers. Alle betrokkenen zijn hierbij aanwezig en er worden alleen korte statements, via user stories, vastgelegd als geheugensteun. Daarnaast is in agile via intensieve samenwerking binnen multidisciplinaire teams de informatieoverdracht tussen de teamleden geregeld. Hierdoor is er tijdens het voortbrengingsproces ook minder behoefte aan documentatie. Een duidelijk voorbeeld van documentatie ten behoeve van het voortbrengingsproces is requirementsdocumentatie. Traditioneel werd die documentatie regelmatig ook gebruikt als systeemdocumentatie, die beschrijft wat er is gemaakt. Dat lijkt efficiënt, maar hoe gedetailleerd de requirementsspecificaties ook zijn, het wil niet zeggen dat de uiteindelijke software er ook aan voldoet. Het gevolg is dat de documentatie later weer aangepast moet worden. Dat is niet alleen dubbelwerk, maar ook foutgevoelig en bovendien is er aan het einde van het project meestal te weinig tijd. Kortom de betrouwbaarheid liet nog al eens te wensen over. Systeemdocumentatie blijft echter ook bij agile belangrijk. Deze documentatie wordt alleen niet eenmalig aan het einde gemaakt, zoals we dat traditioneel gewend waren, maar iteratief opgeleverd. Elke twee weken als er een nieuwe versie van het systeem uitkomt, is er ook een bijgewerkte set van de systeemdocumentatie. En hoeveel werk kan dat zijn, als het maar over twee weken gaat? Daarnaast kan de systeemdocumentatie ook minder uitgebreid zijn dan in traditionele projecten. Dat komt door de stabiele samenstelling van agile teams. Ze blijven namelijk langer bij elkaar dan alleen de duur van een project. Een dergelijk team ontwikkelt niet alleen nieuwe software maar blijft deze ook zelf onderhouden. Uiteindelijk stelt zo’n team de systeemdocumentatie dus voor zichzelf op. En niet, zoals we traditioneel gewend waren, voor anderen die het systeem in beheer nemen en die niet bij de ontwikkeling betrokken waren.
 

Toegevoegde waarde

De toegevoegde waarde van documentatie zit hem in het overbruggen van tijd (dingen onthouden) en/of het overdragen van informatie aan mensen die niet aanwezig waren. Het gaat dus om kennisborging. Vaak wordt vergeten dat documentatie niet de enige manier is om kennis te borgen. Men gaat er impliciet vanuit dat als iets niet gedocumenteerd is dat dat dan tevens betekent dat die kennis verloren gaat. Maar dat is niet waar. Kennis zit immers in de hoofden van mensen en niet in documenten. Kortom, door agile werken verdwijnt de toegevoegde waarde van (traditionele) documentatie voor een belangrijk deel. De beweging naar multidisciplinaire en stabiele agile teams zorgt ervoor dat kennisoverdracht minder via documenten verloopt. Maar eigenlijk was dat altijd al een misverstand. De gedachte dat wanneer iets ‘op papier’ staat, gelijk zou staan aan ‘in de hoofden van mensen zitten’, was altijd al schone schijn. We zien in de praktijk, dat ondanks de populariteit en successen met agile werken, er tegenkrachten ontstaan die juist sterk sturen en leunen op documentatie. SLA’s, uitbestedingscontracten op basis van fixed scope, outsourcingspartners die alleen bouwen op basis van specificaties, beheerafdelingen die uitgebreide documentatie eisen, voorbereidingsteams die zeer ver vooruitlopen op de agile teams, een ‘uw vraagt/wij draaien houding’ bij ontwikkelteams, RFC-processen et cetera. Vooralsnog ligt het punt waarop alles en iedereen agile werkt nog ver in de toekomst. In de tussentijd zal er nog steeds behoefte zijn aan (te) veel documentatie.


Auteurs: Nicole de Swart & Rini van Solingen, Automatiseringsgids

TAGS

Copyright © 2024 Mavim B.V.