Hoeveel details moet ik nu vastleggen bij een requirement?

Hoeveel details moet ik nu vastleggen bij een requirement?

In mijn workshops & trainingen merk ik vaak dat mensen in zowel traditionele als ‘Agile’-achtige ontwikkelomgevingen worstelen met de vraag:

Hoeveel details moet ik nu eigenlijk vastleggen
bij een requirement 
(of user story)?
Dit kost mij erg veel tijd. Waar vind ik de balans?

Het slechte nieuws is dat er eigenlijk niet direct voor iedereen een kant-en-klaar antwoord te geven is. Daarvoor zul je steeds naar de specifieke situatie moeten kijken. Het goede nieuws is dat er gelukkig wel een paar aspecten zijn die je daarbij in elke situatie in overweging kunt nemen.

Eén van die aspecten om naar te kijken is afstand. Een regel die ik zelf hanteer is: hoe verder weg de programmeur hoe meer je moet opschrijven.

Zit de programmeur naast je of in dezelfde kamer dan hoef je in principe minder op te schrijven, want hij of zij kan jou direct vragen stellen. Zit de programmeur echter in een andere kamer of in een ander gebouw, in een ander land (en dus ook andere cultuur!) en ook nog eens in een andere tijdzone dan zul je veel meer moeten uitschrijven. En hoe meer van deze factoren in jouw specifieke situatie gelden, hoe meer details je zult moeten vastleggen om aannames en misverstanden te voorkomen.

Nu zijn er natuurlijk tegenwoordig allerlei technologische middelen, zoals bijvoorbeeld videoconferenties, om het euvel van afstand en geen oogcontact te minimaliseren. Maar ook al zit de programmeur letterlijk naast je, en werk je in een ‘Agile-achtige’ ontwikkelomgeving, dan nog kunnen er andere redenen zijn om meer details vast te leggen dan alleen één zinnetje.

Zo blijkt bijvoorbeeld dat verreweg de meeste teams in de praktijk van alledag niet constant zijn. Vroeg of laat krijgen ze te maken met leden die vertrekken of nieuw zijn. Ook wordt het product na ontwikkeling vaak overgedragen aan een aparte beheerafdeling voor onderhoud. Het kost dan wel erg veel tijd als kennisoverdracht alleen verbaal kan, doordat er te weinig aandacht is geweest voor het vastleggen van aanvullende gegevens zoals bijvoorbeeld testbare acceptatiecriteria.

Maar blijf kritisch!  Alles vastleggen in dikke documenten zorgt er ook niet voor dat de ander begrijpt wat er wordt bedoeld, zo heeft het verleden bewezen.

Zorg voor het minimaal noodzakelijke om misverstanden te voorkomen en voorkom dat zaken dubbel vastgelegd worden. Leg bijvoorbeeld de kwaliteitseisen die voor alle functionele requirements of user stories gelden eenmalig (én testbaar) vast en beschrijf alleen nog de eventuele uitzonderingen bij het requirement zelf. Ga bijvoorbeeld ook met beheer in gesprek en vraag welke gegevens zij minimaal nodig hebben om hun werk goed te kunnen uitvoeren en hoe ze die het liefst ontvangen. Ook zij lezen liever geen dikke documenten, en al helemaal niet bij storingen.

Kortom, hoe groter de afstand tot de programmeur en hoe groter ook de kans op inwerken van nieuwe teamleden en kennisoverdracht aan beheer, des te raadzamer is het om meer details vast te leggen dan één zinnetje. Maar hou het beperkt tot het minimaal noodzakelijke, want rechtstreeks contact, waarbij direct antwoord op vragen gegeven kan worden, is onmisbaar gebleken om juist begrepen te worden.

Reacties zijn welkom!

,

3 Responses to Hoeveel details moet ik nu vastleggen bij een requirement?

  1. Peter Westerhof January 30, 2015 at 1:11 pm #

    Het cruciale verschil tussen verschillende typen requirements, testspecs en acceptatiecriteria mag wel iets nader uiteen worden gezet. Dat is waar het in de praktijk fout loopt.

    En nog 2 vuistregels die het allemaal een stuk gemakkelijker maken :
    * ‘Als je het niet kunt testen hoef je het ook niet te beschrijven’
    * ‘Als het niet is gedocumenteerd EN geaccordeerd bestaat het niet’

  2. Mirjam van den Berg February 12, 2015 at 6:25 pm #

    Op LinkedIn heb ik ook een aantal reacties gekregen op dit artikel.

    Informatie Analisten Nederland (open groep):
    http://linkd.in/1E4HaKE

    Functioneel Beheer (alleen voor leden):
    http://linkd.in/1FDg8Lq

  3. Wilfried van Hulzen February 16, 2015 at 2:51 pm #

    Wat mij betreft ook een handige: als iets de keuze aan de bouwer overgelaten kan worden zonder risico voor de acceptatie hoef je het niet vast te leggen. Hierin spelen precisie en complexiteit met name een rol (zoals het plaatje met de tank direct illustreert).

Leave a Reply