ORDINA BLOGT

BDD Deel I - Three Amigo's

Behaviour Driven Development. Deel I van een vierluik: Three Amigo's: Hoe werken team en business samen?

  • Kaspar van Dam
  • 29 april 2016

Afgelopen week was er in Groningen het Innoveer Jij Mee evenement 'To BDD or Not to BDD?'. Een bijzonder boeiende avond waarin Ordina heeft mogen vertellen over Behaviour Driven Development en tevens hoe wij dit vorm hebben helpen geven bij TKP Pensioenen en de Rabobank. Er ontstonden leuke discussies, met name tijdens de afsluitende Fishbowl sessie. En het mooiste van de avond: In eerste instantie bleek 80-90% van de deelnemers in meer of mindere mate sceptisch over BDD en gaf aan dat het wellicht niet meer dan de zoveelste afkorting was binnen de IT, aan het einde van de avond gaf iedereen aan daadwerkelijk iets te gaan doen met BDD binnen de eigen organisatie! Hieruit blijkt wel hoe belangrijk het is dat men weet heeft van wat BDD is en waar de afkorting werkelijk voor staat! En dat is ook mede aanleiding voor de diverse blogs die ik over dit thema zal plaatsen op www.ordina.nl!

BDD Deel I - Three Amigo's

Binnen Behaviour Driven Development staat het gedrag centraal. Het gedrag van de eindgebruiker wel te verstaan. Daarna is relevant welk gedrag een systeem als respons geeft op dit gedrag. Er wordt binnen BDD dus een duidelijk onderscheid gemaakt tussen gedrag enerzijds en de implementatie anderzijds. Binnen de IT hebben we (tientallen) jaren lang de neiging gehad om te denken in oplossingen. Geregeld komt de business dan ook met een user story met daarin het verzoek voor een bepaald scherm met een specifieke knop. Soms zelfs met schermafbeeldingen en al. Echter: de kans is bijzonder klein (of feitelijk nul) dat de eindgebruiker daadwerkelijk vraagt om een bepaalde knop. De eindgebruiker wil iets gedaan krijgen en dat een systeem hem/haar daarbij kan helpen! Dus, vergeet die ene knop en bepaal eerst het gedrag van de gebruiker en vervolgens op welke manier een systeem daar eventueel die gebruiker bij kan helpen. Mogelijk is dit daadwerkelijk die ene specifieke knop. Maar wie weet blijkt iets heel anders veel praktischer en/of eenvoudiger en/of goedkoper...

Nu klinkt dit tamelijk eenvoudig. De ervaring leert dat het bijzonder lastig is om de daadwerkelijke wens van de eindgebruiker boven tafel te krijgen. Een belangrijk hulpmiddel hierbij kan een zogenaamde Three Amigo's sessie zijn. Van oorsprong bestond een dergelijke sessie altijd uit drie personen, te weten de tester, ontwikkelaar en business (Product Owner). Inmiddels weten we dat het van belang is om alle stakeholders aan te laten haken. Veelal is dat in ieder geval het gehele ontwikkelteam, de product owner, eventuele andere stakeholders vanuit de business, ops, enzovoorts. Dit zijn dan ook al snel veel meer dan drie personen. Wel is het relevant te zorgen dat de groep niet té groot wordt, want dan gaat dit een effectief overleg in de weg zitten. In dat geval is het goed om met vertegenwoordigers te werken. Eén persoon die namens diverse stakeholders spreekt en dus bekend is met hun wensen en ook het mandaat heeft deze uit te spreken.

Het doel van de sessie moet zijn om een bepaald thema aangedragen door de business uit te diepen om helder te maken wat de eindgebruiker wil. Vaak begint het dan ook met een user story. Een methode om deze te vertalen naar gedrag is door de 'diverge-explore-converge' werkwijze te hanteren. Hierbij wordt een onderwerp eerst zo groot mogelijk gemaakt door er steeds meer bij te halen, daarna wordt een verkenning gedaan van de diverse nieuwe onderwerpen om dit uiteindelijk weer kleiner te maken tot een concrete omschrijving van bepaald gedrag van de eindgebruiker en vervolgens het gewenste gedrag dat een systeem hier als antwoord op kan gaan geven (implementatie). In een vervolg blog zal ik verder in gaan op hoe iets dergelijks concreet genoeg gemaakt kan worden middels 'Specification by Example'.

De output van een dergelijke sessie is heel specifiek de opdracht aan het team om iets (iteratief) te gaan implementeren dat de eindgebruiker daadwerkelijk wil hebben. Het 'Doing it the first time right'- principe. Op deze manier kan een goede Three Amigo's sessie enorme hoeveelheden rework voorkomen en levert zijn geld dus meer dan op! Het is belangrijk dat alle stakeholders dit belang van de sessie inzien en dus ook aanwezig zijn (en meer dan alleen fysiek aanwezig!). Het is tevens van belang dat het eindresultaat van de sessie concreet genoeg is om verdere misverstanden of misinterpretatie te voorkomen.

Dergelijke sessies organiseren en met name ook het onderscheid houden tussen Gedrag en Implementatie kan in het begin lastig zijn. Het vergt veel discipline van een team. Het kan daarom zinvol zijn om een BDD coach hiervoor in te schakelen. Iemand van buitenaf die het team tijdens de sessie scherp houdt op het doel van de sessie. Uiteraard kan één van de BDD coaches van Ordina hierbij helpen, maar het kan ook geen kwaad om bijvoorbeeld een collega uit een ander, niet bij het proces betrokken, team hiervoor in te schakelen!

Vragen? Op-/aanmerkingen? De behoefte hier mee aan de slag te gaan en hierover van gedachten te wisselen? Laat het mij weten of neem contact op met de Ordina contactpersoon!

Over de auteur:

Kaspar van Dam

Kaspar van Dam is test(automatisering) consultant bij Ordina en adviseert collega's en klanten over vraagstukken rondom de thema's agile testing, behavior driven development (BDD), testautomatisering en meer.