Regelmatig lees of hoor je dat IT-projecten falen, een langere doorlooptijd nodig hebben dan oorspronkelijk gepland en veel meer kosten dan oorspronkelijk gedacht. De oorzaken hiervoor zijn veelal te herleiden naar communicatieproblemen zoals:

• de business is niet in staat om het gewenste gedrag eenduidig te benoemen
• de ontwikkelaars begrijpen niet wat het gewenste gedrag is dat ze moeten ontwikkelen
• de business begrijpt niet welke technische uitdagingen het gewenste gedrag met zich meebrengt

Wat is BDD?

Het primaire doel van BDD is om mensen te laten communiceren en de kloof te dichten tussen ‘technische’ en ‘business’ mensen. BDD zorgt voor communicatie tussen iemand met diepgaande technische kennis, iemand met een grondige business kennis en een professionele tester. Door deze verschillende stakeholders de functionaliteit te laten bespreken, de problemen te bespreken en te praten over hoe ze deze kunnen oplossen, zal leiden tot specificaties die door alle stakeholders op dezelfde wijze wordt begrepen.

Behaviour Driven Development (BDD) is een raamwerk voor software ontwikkel activiteiten die teams helpt software te ontwikkelen:

• die waardevol is,
• die van hoge kwaliteit is
• op een snellere manier

BDD maakt gebruik van Agile en Lean praktijken en in het bijzonder Test Driven Development (TDD) en Domain Driven Design (DDD). Het belangrijkste is dat BDD gebruik maakt van een gemeenschappelijke taal, gebaseerd op eenvoudige en gestructureerde zinnen.

BDD is ontwikkeld door Dan North. De ontwikkeling hiervan is begonnen in 2003 als reactie op problemen die Dan North ondervond met TDD.

BDD is gebaseerd op de volgende 3 principes:

• Genoeg is genoeg
  Er moet vooraf net genoeg analyse en ontwerp gedaan worden om te kunnen starten. Meer is verspilde moeite.
• Lever waarde voor de stakeholder
  Er moet alleen gedaan worden wat waarde oplevert of het vermogen om waarde te leveren vergroot.
• Alles draait om gedrag
  Op elk niveau kan dezelfde taal gebruikt worden om het gedrag van het systeem te beschrijven

Werkwijze

BDD richt zich op het duidelijk identificeren van het gewenste gedrag van een functie. Het gedrag wordt geïdentificeerd met behulp van het beschrijven van realistische voorbeelden, in plaats van te worden beschreven in abstracte en generieke jargon.

Het idee is om, samen met alle teamleden, vertegenwoordigers uit de business en mogelijk zelfs klanten, het gedrag van de software te definiëren. Dit kan middels een specificatie workshop. Deelnemers aan de specificatie workshop krijgen de opdracht om na te denken over hoe het systeem zich moet gedragen en beschrijven dat volgens een vast formaat.

De “The Three Amigos” is een goede manier om deze gesprekken te laten plaatsvinden. In essentie betekent “The Three Amigos” aanpak dat drie key stakeholders samen werken aan het uitwerken van een user story of feature voordat gestart wordt met de ontwikkeling van de software.

Veelal worden de volgende stakeholders hierbij ingezet:

• business analyst of product owner
• ontwikkelaar
• tester

Een gemeenschappelijk taal helpt het hele team om te begrijpen wat er wordt verwacht van de functie. Hoewel het voor de verschillende teamleden van belang is om te kunnen werken met de nomenclatuur van hun eigen domein, is het van belang om te blijven realiseren wat echt belangrijk is: Wat de gebruiker ziet en doet.

Om dit te realiseren, gebruikt BDD Gherkin. Dit is een eenvoudige taal, om te beschrijven hoe een functie zich zal moeten gedragen onder verschillende omstandigheden. De officiële standaard voor Gherkin wordt onderhouden door Cucumber, een van de belangrijkste BDD automatiserings frameworks.

In hoofdlijnen bestaat een Gherkin beschrijving uit een feature, in de vorm van een user story, requirements en voorbeelden in de vorm van scenario’s

• In het artikel over Gherkin wordt in detail ingegaan op bovenstaande structuur en is een uitgewerkt voorbeeld opgenomen.

Voordelen BDD

• Goede samenwerking
  BDD verhoogt en verbetert de samenwerking. Het stelt iedereen, die betrokken is bij het project, in staat zich gemakkelijk in te zetten voor de systeemontwikkeling. En door een eenvoudige taal te gebruiken, kunnen alle betrokkenen scenario’s schrijven.
• Gericht op toegevoegde waarde voor de business
  BDD hecht veel waarde aan de toegevoegde waarde voor de business. Door prioriteiten te stellen aan de business, op basis van de toegevoegde waarde die functionaliteit biedt, kunnen ontwikkelaars een beter resultaat leveren omdat ze een goed begrip hebben van hoe de business denkt. Door te focussen op de toegevoegde waarde, worden er geen nutteloze functies gebouwd.
• Ubiquitous taalgebruik
  Ubiquitous taal is een idee uit Domain Driven Design om binnen een project een door iedereen gedeelde taal te gebruiken gebaseerd op het domein waarover het project gaat. Op deze manier worden misverstanden zoveel mogelijk vermeden en mensen van buiten het domein gedwongen deze gedeelde taal te leren.
• Lagere kosten
  Door de kwaliteit van de code te verbeteren, verminderen de onderhoudskosten en worden de risico’s van het project geminimaliseerd.
• Traceerbaarheid
  Alle ontwikkelde software is terug te traceren naar bedrijfsdoelstellingen.

Nadelen BDD

• Vereist veel samenwerking / betrokkenheid
  In de basis gaat het bij BDD om communicatie. Wanneer er communicatieprobleem zijn tussen de verschillende stakeholders, zal BDD meer problemen opleveren dan dat het oplost.
• Vereist iteratieve benadering
  BDD is niet geschikt voor een waterval aanpak. De business analist is niet meer de enige die de requirements van te voren schrijft, testers wachten niet meer met het registreren van bevindingen tot aan het einde van een release en ontwikkelaars overleggen regelmatig met de rest van het team.
• Lijkt langzamer te gaan
  BDD vergt in het begin van een project veel tijd en moeite waardoor het kan lijken dat de ontwikkeling langzamer gaat dan anders.

A