Dennis Geluk
Ik krijg vaak de vraag: “Hoe kan ik het beste requirements vastleggen in een agile project?” Mijn antwoord is dan steevast: “Op dezelfde manier waarop je gewend was om het te doen, alleen nu met een duidelijke visie op just-in-time en just-enough.

Agile is immers een denkwijze, geen voorschrift. Agile legt de nadruk op just-in-time en just-enough en wil voorkomen dat er tijdens een ontwikkelproces “waste” ontstaat. Agile zegt niets over hoe de code, testcases en documentatie van je (agile) projecten er qua vorm uit moeten zien.

Agile requirements zien er dus vaak hetzelfde uit als ‘traditionele’ requirements. Alleen verschilt de methode die we gebruiken om de requirements vast te leggen.

Agile requirements bestaan niet. Agile projecten wel.

Stel, je kijkt naar de code en de testcases van bedrijfskritische software die twee jaar geleden succesvol werd opgeleverd. Zou jij kunnen zien of de code en de testcases agile of niet agile ontwikkeld werden? Waarschijnlijk  niet. Hetzelfde geldt wellicht voor ‘agile requirements’.

Uiteraard zou je aan de diverse werkproducten kunnen zien dat de diepgang op specifieke plekken afwijkt van wat je bij een traditioneel project zou verwachten. Ik denk onder meer aan extra documentatie en commentaar bij complexe codefragmenten of meer details in de requirements en de testcases. Op basis van deze variatie in diepgang zou je wellicht kunnen afleiden dat het project agile ontwikkeld werd.

Maar toch… Ik zou niet willen stellen dat dit altijd zo is. Er zijn immers diverse andere factoren die van invloed kunnen zijn op de documentatie bij code, testcases en de requirements binnen je project. Denk hierbij bijvoorbeeld aan variatie als gevolg van offshore ontwikkeling.

Als je de schoenendoos aan stories even terzijde schuift kun je vaak niet zeggen of code, testcases en requirements in een agile of een traditioneel project ontwikkeld werden. Agile requirements bestaan dus niet. Agile projecten wel.

De rol bepaalt de vorm van je requirements

Het vastleggen van requirements kan op diverse manieren en dient vaak meer dan één doel. Requirements zijn uiteraard een belangrijk hulpmiddel bij het vastleggen van de behoeftenanalyse en de afstemming met stakeholders. Daarnaast vormen requirements de basis voor de te ontwikkelen software en de testcases die valideren of de software daadwerkelijk doet wat er beloofd werd.

In een klein compact team met veel materiekennis heeft iedereen aan een half woord genoeg en volstaat het wellicht om de requirements aan de hand van een user story door te spreken. Een “hoog abstractieniveau” is dan vaak voldoende. Bij complexere materie, meer teams en langere ontwikkelcycli zal echter ook vaak de behoefte aan gestructureerde documentatie toenemen.

Bij het oppakken van een story kunnen naast de standaard taken voor ontwikkelaars en testers dan ook taken met betrekking tot de documentatie ontstaan. Denk bijvoorbeeld aan het documenteren van die complexe berekening met een activity diagram of specifieke uitgewerkte voorbeelden. Zoals iedere vakman wil je dergelijke zaken gestructureerd en duidelijk vastleggen zodat een eventuele opvolger of collega deze zaken makkelijk kan terugvinden.

De vorm van je documentatie zal in de praktijk niet noodzakelijk afhangen van het (al dan niet agile) proces dat je volgt; de vorm van je documentatie zal meer afhangen van andere factoren zoals de complexiteit van de materie en het aantal betrokken partijen en de rol die je requirements vervullen.

Een agile werkwijze leidt niet automatisch tot een nieuwe documentatiestandaard

Als we (naast een set van stories) behoefte hebben aan een vorm van gestructureerde documentatie is het belangrijk om bij bijhouden van deze requirements niet terug te vallen in oud waterval-denken. We kunnen de ‘traditionele’ structuur en vorm wel hergebruiken maar we moeten niet noodzakelijk alles gedetailleerd opschrijven.

Het kan uiteraard helpen om een vorm te kiezen die mensen herkennen en waar geen extra uitleg bij nodig is. Indien je vroeger bijvoorbeeld JSTD of Use Cases gebruikte kunnen deze ook nu nog steeds zeer geschikt zijn. Het is in mijn beleving dan ook een misverstand dat het overgaan naar een agile werkwijze automatisch tot een compleet nieuwe documentatie standaard zou moeten leiden.

Behoud wat in de praktijk goed werkt en focus bij alles wat je doet op het nut en de noodzaak van je beslissingen. Denk hierbij niet alleen aan de korte maar ook aan de lange termijn. Wat vandaag voor sommigen overbodig lijkt zou over een paar maanden voor anderen noodzakelijk kunnen zijn.

Wanneer volstaan stories als requirements?

Het kan geen kwaad om je bij ieder project de vraag te stellen of user stories alleen genoeg zijn om alle requirements vast te leggen. Mijn persoonlijke ervaring zegt van niet maar dit is gekleurd door het feit dat ik vaak bedrijfskritische applicaties specificeer waarbij ook nog wel het een en ander aan complexiteit om de hoek komt kijken.

User stories worden in essentie gebruikt om kleine stukjes functionaliteit te beschrijven. Om de scope van een story zo scherp mogelijk te houden omschrijven we duidelijk wat de story aan business value zal opleveren.

In de praktijk blijkt dit nog wel eens een uitdaging. Hoe ga je bijvoorbeeld om stories die voor het team te groot zijn om binnen één sprint op te kunnen pakken? Of hoe ga je om met een story die geldt als verbetering of nieuwe versie van een eerder opgeleverde story?

In dergelijke situaties ontstaat de behoefte om de onderlinge samenhang tussen stories vast te leggen en om een beeld te hebben van wat de som van al deze stories nu eigenlijk is. Dat beeld beschrijft immers de functionaliteit die opgeleverd werd.

Stories werken perfect in sprints. In de praktijk loont het echter ook vaak om een zekere vorm van de ‘big picture’ (de functionele werking van het systeem) vast te leggen, al is het maar om de product owner te helpen bij het kiezen van de volgende stories.

Conclusie: Agile requirements bestaan niet. Agile projecten wel.

Wat mij betreft bestaan ‘agile requirements’ niet. Agile projecten wel. Agile beïnvloedt de houding van een analist in een project, agile hoeft de vorm van de requirements niet noodzakelijk te beïnvloeden.

Een agile analist stapt af van de natuurlijke (traditionele) houding om alles vooraf uit te zoeken en vast te leggen. In plaats daarvan speelt een agile analist meer in op de just-in-time en just-enough principes waar mijn collega’s in eerdere publicaties al over schreven.

De uiteindelijke vorm van de opgeleverde requirements binnen een agile project zullen in de praktijk niet noodzakelijk verschillen van de vorm van requirements die op de traditionele manier opgemaakt werden. Agile requirements zijn dus ook maar gewoon requirements.

Hoe denkt u hierover?

Heeft u vragen of opmerkingen over agile werken of de impact van agile werken op uw requirements? Aarzel niet en deel uw vragen en opmerkingen via het reactieformulier onderaan deze pagina, via info@divetro.nl of via +31 (0) 88 000 54 00. Wij helpen u graag verder.

Blijf op de hoogte

Wilt u meer van dit soort blog posts lezen? Meld u dan aan voor onze nieuwsbrief. U ontvangt onze blog posts dan automatisch in uw mailbox.

Meld u aan voor onze nieuwsbrief