BEHAVIOUR DRIVEN DEVELOPMENT; DE KRACHT VAN BEGRIJPELIJKE TAAL [Johan van den Berg]
BEHAVIOUR DRIVEN DEVELOPMENT (BDD) IS ONTSTAAN OM HELDERE COMMUNICATIE TUSSEN DEVELOPERS, TESTERS EN NIET-TECHNISCHE DEELNEMERS MOGELIJK TE MAKEN. OM ZO SAMEN BETERE SOFTWARE TE KUNNEN ONTWIKKELEN. MAAR WAT IS BDD EIGENLIJK? WAAROM ZOU JE HET VERKIEZEN BOVEN TEST DRIVEN DEVELOPMENT (TDD)? WELKE ROL SPELEN VOORBEELDEN, SCENARIO’S EN RAPPORTAGES BIJ BDD? EN NIET TE VERGETEN; WAT BETEKENT BDD VOOR DE ROL VAN DE TESTER? IN DIT ARTIKEL STIP IK DE BELANGRIJKSTE ASPECTEN VAN BDD AAN.
WAT IS BEHAVIOUR DRIVEN DEVELOPMENT? Eén van de kenmerken van BDD is dat je voorbeelden gebruikt om het gewenste gedrag van de te ontwikkelen software te beschrijven. Deze voorbeelden zijn voor iedereen leesbaar en begrijpelijk; voor business, IT en alle andere betrokkenen. Binnen BDD speelt de vraag waarom de betreffende feature ontwikkeld moet worden een grote rol. Daarnaast is het een methode die ervoor zorgt dat alle betrokkenen elkaar kunnen begrijpen. BDD kun je zien als een voorschrijvende werkwijze op het gebied van structuur en proces, waarmee ontwikkelteams kunnen werken. WAAROM BEHAVIOUR DRIVEN DEVELOPMENT? BDD is ontwikkeld om de communicatie tussen developers, testers en niet-technische deelnemers aan een softwareproject te verbeteren. Het komt voort uit het Test Driven Development (TDD). Bij TDD schrijft de ontwikkelaar eerst zijn unit test voordat er ontwikkeld wordt. Dit dwingt hem om onder andere na te denken over het ontwerp van zijn applicatie. Maar waar de ontwikkelaar bij het werken volgens TDD niet over na hoeft te denken is waarom de code wordt beschreven. Ofwel; waarom hij maakt wat hij maakt. Waarom wil de klant deze software? Wat is de vraag achter de klantvraag? En is de bedachte oplossing een antwoord daarop? Deze aspecten blijven binnen TDD onbelicht. BDD legt door te werken met leesbare en begrijpelijke voorbeelden wel de link tussen het technische niveau (het ontwikkelwerk) en het functionele niveau (de klantwens). Wanner het team weet waarom de klant een bepaalde feature gerealiseerd wilt ien is het ook mogelijk alternatieven (technische) oplossingen voor te stellen. Op deze wijze wordt de mogelijkheid gecreërd voor team en klant om elkaar uit te dagen de beste oplossing (in termen van geld, time-to-market en kwaliteit) te realiseren. HOE ZET JE BEHAVIOUR DRIVEN DEVELOPMENT OP DE JUISTE MANIER IN? Om technische en niet-technische projectleden dezelfde taal te laten spreken bij het vaststellen van het gewenste gedrag van de te ontwikkelen software, werk je binnen BDD met toepasbare voorbeelden: oftewel Specification By Example. In deze voorbeelden gebruik je gedrag om de werking van een applicatie te omschrijven. Om het proces om gezamelijk met elkaar in gesprek te gaan om het gewenste gedrag te stroomlijnen, werken we binnen BDD met The Three Amigos Sessie. Deze sessie is vergelijkbaar met de ‘Refinement’ sessies uit Scrum en heeft als belangrijkste vereiste dat de drie rollen business, ontwikkelaar en QA - aanwezig zijn.
83