De ontwikkelingen in ons vakgebied zijn snel gegaan de afgelopen jaren. De manier waarop we requirements achterhalen en omgaan met wijzigingen daarin is enorm veranderd. Ziet jouw requirementsproces er nog hetzelfde uit als 5 jaar geleden?
We zijn iteratief en agile gaan werken. Dat geeft allerlei mogelijkheden om requirements effectiever te achterhalen. Of je nu in een agile omgeving werkt of niet. Als je je requirementsproces meer agile maakt:
- Kost het opstellen van requirements minder tijd
- Zijn wijzigingen in de requirements gemakkelijker door te voeren
- Levert de ontwikkelde software meer businesswaarde
Tips om je requirementsproces te verbeteren
Om het lekker concreet te houden, geef ik 4 tips om je requirementsproces meer agile te maken. Ze zijn niet moeilijk toe te passen, maar vragen soms een beetje lef 🙂.
Tip 1. Documenteer zoveel als nodig is in jullie specifieke situatie
Agile heeft ons doen inzien dat we waren doorgeslagen in het documenteren van alle requirementsdetails. Toch is het ook geen goed idee om documentatie zomaar achterwege te laten. Substantieel minder documenteren kan alleen als je hebt gewaarborgd dat:
- De juiste software met de gewenste functionaliteit wordt gebouwd
- Impactanalyses en RFC’s goed uitgevoerd kunnen worden
- Er geen essentiële kennis verloren gaat als het werk (of de software) aan in- of externe collega’s wordt overgedragen
In traditionele projecten is gedegen documentatie hierbij onmisbaar. In agile is dat door de totaal andere werkwijze niet meer het geval. Hoe meer je team en organisatie de agile principes naleeft, hoe minder behoefte aan documentatie er zal zijn. Mijn 5 belangrijkste agile documentatietips lees je hier.
Tip 2. Hanteer de spreuk ‘goed is goed genoeg voor nu’
Het is niet nodig om in één keer vanaf scratch de uiteindelijke requirements boven water te halen. En dat is ook niet realistisch. De (vertegenwoordigers van de) gebruikers weten namelijk zelf maar tot op zekere hoogte welke functionaliteit ze nodig hebben.
Zeker wanneer hun bedrijfsproces of werkwijze gaat veranderen, kun je er niet van uit gaan dat ze hun requirements al kennen. Ook al denken gebruikers zelf wel een helder beeld te hebben.
Geef de (vertegenwoordigers van) de gebruikers de gelegenheid om gaandeweg te ontdekken hoe het systeem ze het beste ondersteunt. In een aantal feedbackslagen help je de gebruikers zich een beter beeld van het gewenste systeem te vormen. Daar gebruik je prototypes (of beter nog incrementen) voor.
Bij een agile (incrementeel en iteratief) aanpak begin je met een uiterst eenvoudige versie van het systeem. Die breid je stapsgewijs uit tot een volwaardig systeem dat veel businesswaarde levert.
De requirements voor het eerstvolgende increment zijn dan niet de uiteindelijke requirements. In de opeenvolgende feedbackslagen groeien ze daar als het ware naar toe. De requirements die je nu opstelt hoeven alleen goed genoeg te zijn voor het volgende increment.
Tip 3. Bekijk de requirements met ‘de kennis van vandaag’
Alleen de actuele informatie over de eisen en wensen van de business is relevant. Zorg dat de requirements steeds het actuele beeld weerspiegelen. Dan werken jullie als agile team steeds met de informatie die er op dat moment is.
Dit impliceert dat vasthouden aan eerder afgestemde of goedgekeurde requirements niet slim is. Wijzigingen wil je eenvoudig kunnen doorvoeren, als inspelen op nieuwe inzichten belangrijk is.
Zie een wijziging als iets positiefs! Realiseer je dat de werkelijke behoeften kennelijk weer een stukje scherper zijn geworden. Zeg (en denk) bij een wijziging niet ‘maar toen zei je …’. Check hooguit wat de stakeholder van mening heeft doen veranderen.
Tip 4. Neem afscheid van achterhaalde ‘wijsheden’
Sommige dingen die we de afgelopen decennia heel belangrijk vonden, zijn ondertussen achterhaald. Traditioneel opgeleide vakmensen die open staan voor nieuwe inzichten, raden we het online programma Meester in agile requirements aan.
Vroeger deden we ons uiterste best om:
Voor aanvang van de bouw een complete en goedgekeurde set aan requirements op te stellen
Met als gevolg dat er erg veel tijd zat tussen het definiëren van de requirements en het implementeren ervan. Dat alleen al leidt tot extra wijzigingen. Veranderde marktomstandigheden en nieuwe inzichten die zich in die tussentijd voordoen, zijn immers niet in de reeds opgestelde requirements opgenomen.
De requirements volledig, eenduidig en meetbaar te specificeren
Eigenlijk wisten we wel dat dit maar beperkt mogelijk is. Toch bleven we ernaar streven. En staken we er veel tijd en energie in om de totale set aan requirements zo volledig mogelijk te specificeren. Tegenwoordig wordt het gelukkig bestempeld als verloren moeite.
We hebben nu andere manieren om requirements over te brengen aan het agile team. Bijvoorbeeld met de (vaak verkeerd uitgelegde) user story techniek.
Je requirementsproces meer agile maken
Dit waren mijn tips om je requirementsproces te verbeteren en meer agile te maken.
In agile zijn requirements volledig geïntegreerd in het ontwikkelproces. Hoe dat eruit ziet lees je in dit blogartikel.
Nicole de Swart
