Muur met geeltjesMet de komst van agile zijn we heel anders tegen documentatie aan gaan kijken. Vroeger is ons geleerd dat we alle requirements juist, volledig en eenduidig moeten vastleggen. Dat was cruciaal omdat die documentatie fungeerde als contract en als basis voor projectmanagement, ontwerp, bouw, test en beheer. Tegenwoordig ziet het ontwikkelproces er anders uit en is het niet meer vanzelfsprekend om alles (klakkeloos) te documenteren.

Ik merk dat veel requirementsanalisten nog zoeken naar een optimale documentatie. Hoeveel informatie moet ik vastleggen? Gaat er geen essentiële informatie verloren? Wanneer leg ik welke informatie vast? Dit zijn vragen die me geregeld gesteld worden. Daarom geef ik je in dit artikel mijn 5 belangrijkste documentatietips. Hier komen ze:

1. Documenteer selectief

Vraag je steeds af hoe de informatie het beste overgedragen kan worden: mondeling of schriftelijk. Documentatie gebruik je gewoonlijk om tijd te overbruggen en om mensen die niet bij de meeting aanwezig waren te informeren.

Agile maakt veel gebruik van de kracht van mondelinge communicatie en heeft ons andere en vaak effectievere manieren van kennisoverdracht gebracht. Maak daar gebruik van en vind een goede mix van mondelinge en schriftelijke communicatie.

2. Verspil geen tijd aan het onderhouden van documentatie

Stempel ‘Approved’

Voorkom dat je wijzigingen en voortschrijdend inzicht moet verwerken in je documentatie door alleen de informatie vast te leggen die iemand op korte termijn nodig heeft. Beheerdocumentatie is hierop de enige uitzondering (zie tip 5).

Vroeger moesten we de totale set aan requirements goed en nauwkeurig vastleggen, omdat alle requirements goedgekeurd moesten worden voordat de bouw startte. Er zat toen immers veel tijd tussen het achterhalen en vastleggen van de requirements en het implementeren ervan. Met een agile werkwijze ontdek je gaandeweg het project wat de echte behoeften van de business zijn. Als je informatie te vroeg vastlegt en de documentatie dus op de plank komt te liggen, is de kans groot dat het snel verouderd.

3. Gebruik user stories niet als documentietechniek

Gebruik use cases of een andere traditionele techniek als je requirements ‘voor het nageslacht’ wilt vastleggen. User stories zijn daar niet voor bedoeld en ook niet geschikt voor. De korte beschrijving van een user story is niet meer dan een geheugensteuntje voor de mondelinge communicatie die plaatsvindt tussen de business en het ontwikkelteam. Logisch dus dat het alleen een summiere beschrijving is. Je gooit ze weg nadat de user story is geïmplementeerd.

Als je precies wilt weten hoe je de user story techniek optimaal gebruikt, is mijn online masterclass Vervolmaken van je user stories voor jou gemaakt.

4. Stel het documenteren zo lang mogelijk uit

Doel gedeelte

Niet alleen het vastleggen, maar ook het achterhalen van requirements doe je zo laat mogelijk. Het is verschoven van up front naar just in time. Dus net voordat iemand (bijvoorbeeld management of ontwikkelteam) de informatie nodig heeft. Dat impliceert dat je weet voor wie je het vastlegt en waarvoor zij het gaan gebruiken.

Leg alleen die informatie vast die een duidelijke toegevoegde waarde heeft. Uiteraard is dat afhankelijk van jullie werkwijze en projectinrichting. Doorgaans betekent dat dat je hele globale requirements hebt en deze gefaseerd en in een aantal detailslagen steeds verder uitwerkt tot het benodigde detailniveau.

5. Leg beheerdocumentatie tijdens de sprint vast

Maak expliciet onderscheid tussen beheer- en requirementsdocumentatie. Het ontwikkelteam heeft requirements nodig om de juiste software te bouwen. Voor beheer en onderhoud is inzicht in de functionaliteit en opbouw van het systeem nodig. Daarom kun je pas nadat de software is gebouwd de juiste beheerinformatie vastleggen.

Tot voor kort gebruikten we de requirements voor meerdere doeleinden. Dat lijkt op het eerste gezicht efficiënt maar brengt allerlei nadelen met zich mee. Je krijgt daardoor bijvoorbeeld dikke documenten die voor de meeste doelgroepen veel overbodige informatie bevatten.

Ik hoop dat ik je met deze tips een heel eind op weg heb geholpen. Wil je meer toelichting of heb je specifieke vragen, plaats dan een reactie hieronder.

Succes met de requirements,

Nicole de Swart

Vond je dit artikel interessant? Deel het dan via de share knoppen aan de zijkant.

Gratis e-book Vliegende start als agile analist

e-book Vliegende start als agile analist Met 25 do's en dont's voor agile requirements

Nicole de Swart

Nicole de Swart

Requirementstechnieken expert

Ik help je de juiste mix van agile en traditionele requirementstechnieken toepassen

Volg Nicole op:

Tips voor de moderne analist

# abonnees

Abonneer je en ontvang eens per maand een nieuw artikel