Documentatie in een Agile traject

In een waterval ontwikkeltraject is in detail uitgewerkt ontwerpdocumentatie een belangrijke vereisten om met bouw en test te kunnen starten. Binnen een agile traject niet, want het Agile Manifesto zegt het volgende over documentatie:  “We value working software over comprehensive documentation”, of te wel “Wij waarderen werkende software boven uitgebreide documentatie”. Vanuit dit principe is er een spanningsveld tussen ontwerpen in traditionele omgeving en ontwerpen in een  agile omgeving. Dit artikel beschrijft  hoe je als team hiermee om kunt gaan.

De business analist (ontwerper), de ontwikkelaar en de tester
De business analist zegt: “Volgens de agile principes is het niet nodig de documentatie volledig uit te specificeren. Ik geef een globale beschrijving van de requirements en het ontwerp zodat de ontwikkelaar kan starten met de bouw en de tester in staat is om de testen te specificeren.”

De ontwikkelaar zegt: “Het ontwerp dient volledig uit gespecificeerd te zijn. Anders kan ik niet inschatten wat ik moet bouwen en hoeveel pokerpunten ik aan het ontwerp moeten toekennen.”

De tester zegt: “Het ontwerp dient volledig uit gespecificeerd te zijn. Ik bepaal niet wat de testverwachtingen zijn, dat moet blijken uit het ontwerp.”

In feite hebben de drie professionals allemaal een beetje gelijk en een beetje ongelijk.  De business analist dient het noodzakelijke aan te leveren om de complexiteit en de grootte van het ontwerp te kunnen inschatten. Wat precies het noodzakelijke is, kan de business analist met het team bespreken.

Bij een van mijn klanten is het gebruikelijk om  de user stories in een Readiness sessie te bespreken. In deze sessie legt de business analist uit wat de user story inhoudt. De ontwikkelaar en de tester krijgen hierbij de kans om vragen te stellen. In feite is dit  een intake/ review moment van de user stories. De ontwikkelaars en de testers toetsen op dat moment per user story of deze de noodzakelijke informatie bevat om op te kunnen pakken in  de sprint.

Tijdens de eerste sprints kan ervoor gekozen worden om iets ruimer te pokeren om de behoefte met betrekking tot   het detailniveau van de documentatie te bepalen. Doordat de ontwikkelaars een tussentijdse oplevering op de testomgeving doen, is vroegtijdige feedback vanuit het testen mogelijk. Het product wordt op deze manier getoetst met de ontwikkelaar en de business analist. Na een aantal sprints weet:
1)      de business analist  welk detailniveau  de documentatie moet hebben  om de user story in een sprint mee te nemen.
2)      de ontwikkelaar welk detailniveau de documentatie heeft bij aanlevering.
3)      de tester welk detailniveau de documentatie heeft bij aanlevering. Met de tussentijdse oplevering door bouw is er waardevolle feedback mogelijk, als terugkoppeling aan business analist, wat impliciet aangeeft of de detailniveau voldoende is.

In de eerste sprints vraagt deze aanpak enige pragmatiek binnen het team. Aan de andere kant is er ruimte tijdens de eerste twee tot drie sprints om tot een gepaste werkwijze te komen. Na een aantal sprints merk je dat de kwaliteit van de documentatie steeds hoger wordt. Daarnaast zal het team steeds meer domeinkennis opbouwen en vaardigheden ontwikkelen. Hierdoor wordt het begrip wat “noodzakelijk” beschreven moet zijn, steeds minder diep en breed. Als laatste wil ik graag aangeven:

Agile zegt niet dat documentatie niet belangrijk is. Maar beschrijf wat het team nodig heeft om zo effectief mogelijk werkende software op te leveren.

Dit bericht werd geplaatst in Agile ontwikkelen, Algemeen en getagged met , , , , , , , , , , , , , , , . Maak dit favoriet permalink.

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit / Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s