Boekreview – Specification by Example

Zo af en toe kom ik een boek tegen dat mijn passie voor het maken van mooie software aanwakkert. Een boek dat ik ademloos en met rode oortjes van opwinding van begin tot einde uitlees, terwijl ik bij elke paragraaf geestdriftig knik en zo nu en dan hardop “Ja, inderdaad, zó moet het!” uitroep. Een boek dat ik vervolgens constant bij vrienden en collega’s aanbeveel en waar ik voortdurend uit citeer. Specification by Example van Gojko Adzic is zo’n boek.

De centrale vraag van dit boek is: ‘Hoe kun je op een efficiënte wijze software maken die doet wat de klant wil?’ Traditioneel wordt deze vraag beantwoord door het opstellen van lange, gedetailleerde functionele specificaties. Dit bracht echter allerlei problemen met zich mee, bijvoorbeeld dat de specs binnen de kortste keren al niet meer de daadwerkelijk gemaakte software beschrijven. Binnen agile methodes is dit vervangen door lichtgewicht documentatie. ‘Precies genoeg’ documenteren is nu het devies, maar hoe doe je dat nou?

 

pecification by Example beschrijft een proces om dat voor elkaar te krijgen. De kern hiervan is dat de klant nauw samenwerkt met ontwikkelaars en testers om zo de specificaties met behulp van concrete voorbeelden precies en voor iedereen begrijpelijk op te schrijven. Bovendien worden de specificaties zo geschreven dat ze geautomatiseerd kunnen worden getest op de software. Daarmee garandeer je enerzijds dat de software precies doet wat je hebt beschreven en anderzijds dat de documentatie precies klopt met wat de software doet. Als je dit goed doet, ontwikkelt zich ‘levende documentatie’ van grote waarde: een toegankelijke beschrijving die mee evolueert met de software.

De benaming “Specification by Example” geeft al aan hoe belangrijk concrete voorbeelden zijn bij het opstellen van de specificaties. Requirements die initieel vaag en abstract zijn, worden precies en concreet zodra de klant een realistisch voorbeeld geeft. Een voorbeeld leidt bovendien al snel tot verdere discussie, zodat randgevallen en omissies boven water komen. Tijdens workshops waarin zowel de klant, de ontwikkelaar als de tester deelnemen, worden deze voorbeelden verder verfijnd en tot de essentie teruggebracht. Daarna kunnen ze door de ontwikkelaar zonder verdere aanpassingen worden geautomatiseerd en als bewijs dienen dat de software aan de requirements voldoet.

Sommigen zullen dit herkennen als Behaviour-Driven Development (BDD) of Acceptance-Test-Driven Development (ATDD). Dit zijn inderdaad allemaal termen die ongeveer hetzelfde aanduiden. Maar Adzic heeft hier bewust van afgeweken: BDD en ATDD zijn namelijk beide termen die suggereren dat het iets technisch is, iets van ontwikkelaars of van testers. En dit terwijl juist de klant de allerbelangrijkste speler is! Hij moet actief betrokken zijn bij de specificaties, meeschrijven en meelezen om ervoor te zorgen dat de juiste software wordt gemaakt.

Om de specificaties zonder aanpassingen te kunnen automatiseren, zijn allerlei tools op de markt, zoals Cucumber (waarover onlangs in Java Magazine is geschreven), JBehave en Fitnesse. Maar dit boek beschrijft bewust geen tools en bevat geen lettercode. Het gaat de auteur er juist om een proces uit te werken waarmee de communicatie en samenwerking tussen het business- en het ontwikkelteam verbetert en niet om een specifieke tool te verkopen. Zo ontstijgt het boek de technologie van de dag en bevat het wijsheid en inzichten die lange tijd hun waarde zullen behouden.

Het mooie van dit boek is dat het zelf ook voldoet aan “Specification by Example”. De beschreven principes zijn het resultaat van een groot aantal case studies, afkomstig van bedrijven die dit proces met succes in de praktijk uitvoeren. De talloze voorbeelden helpen om je ervan te overtuigen dat deze methodiek echt werkt en dat het niet alleen mooi klinkt in theorie. Tegelijkertijd laat het boek zien dat ieder bedrijf uniek is en dat ieder team weer tegen andere obstakels aanloopt, terwijl het probeert om tot een beter ontwikkelproces te komen.

Hoewel ik al eerder had gehoord van technieken zoals BDD, heeft Specification by Example me op dit gebied pas echt de ogen geopend door me laten zien hoeveel verder het gaat dan alleen “Given … When … Then”. Dit boek is het absoluut waard om gelezen en herlezen te worden. Lees het zelf en raak ook overtuigd.

Streamer: De kern van Specification by Example is dat de klant nauw samenwerkt met ontwikkelaars en testers om zo de specificaties met behulp van concrete voorbeelden precies en voor iedereen begrijpelijk op te schrijven.