In dit artikel lees je over de evaluatie naar behaviour-driven development, hoe je user stories opzet en deze kan (auto) testen. Ook geven we een aantal tools voor deze manier van software ontwikkeling.
“Soms moet er iets gebeuren voordat er iets gebeurt.”
– Johan Cruijff
Software voor betere business-outcomes
Op het gebied van software ontwikkeling is een belangrijke evolutie gaande. Waar voorheen werd gekeken, welke functies door de software moesten worden uitgevoerd, wordt nu gekeken welke features toegevoegde waarde aan de organisatie leveren.
Omdat computers vroeger veel energie, koeling en ruimte nodig hadden zaten de programmeurs letterlijk in de kelder van veel organisaties. Tel hierbij op dat bèta mensen zich vaak moeilijker in andere personen kunnen verplaatsen en een subcultuur is geboren. Kort door de bocht bouwden programmeurs applicaties en de rest kon deze gebruiken.
Doordat ICT een steeds belangrijke rol in organisaties in heeft genomen zijn gebruikers (terecht) steeds mondiger geworden en wordt ICT als elke andere investering beschouwd. ICT is niet meer iets aparts, maar is verwoven door de hele organisatie. Bij veel organisaties is inmiddels een chief information officer (CIO) die bij board-meetings met andere executives aanwezig is. Van de kelder naar de board-room in een jaar of 15, well done!
Eerder hebben we het gehad over de noodzaak van thrasing en prototypen om de mens terug te brengen in ontwerpproces. De uitdaging is nu ook de mens (stakeholders) terug te brengen in het development- of programmeerproces. De mogelijkheden voor het bouwen zijn eindeloos. Ja, alles kan. Maar omdat iets kan, wil niet zeggen dat we dit ook moeten bouwen. Software moet waarden toevoegen aan business-outcomes. Liefst bepalen we de return-on-investment (ROI), maar soms is dit lastig. Waar beginnen we ons project als de doelstelling “een besparing van 5% op onze operationele kosten” is?
Enter behaviour-driven development & stories
Behaviour-driven development (BDD) gaat er vanuitdat je een idee tot geïmplementeerde, geteste en productie-klare code kan omzetten. Dit gebeurt op een eenvoudige en effectieve manier, zolang deze eis maar specifiek genoeg is, zodat iedereen weet wat deze inhoud.
Om dit te doen hebben we een manier nodig, zodat iedereen (de business mensen, de analisten, designers, developers en testers) een gemeenschappelijk begrip van de omvang van het werk kan hebben. Iedereen dient dezelfde verwachting te hebben om zo misverstanden en frustraties te voorkomen.
Dit is dan ook het doel van je story (ik ben een voorstander van het aanhouden van begrippen in het Engels). Een story is een beschrijving van de eis én zijn toegevoegde waarde en een set van criteria, waarmee iedereen kan besluiten dat het item ‘af’ is.
In dit format kan de eis kan een functionele feature zijn, maar dit hoeft niet perse.
De structuur van een story
Hieronder het ideale formaat van een story . In de praktijk kun je zelf bepalen wat voor structuur het beste bij je past. Soms is meer nodig, soms minder. Dit hangt ook af of je via een watervalproject werkt of via bijvoorbeeld een agile scrum methode.
De structuur is als volgt:
Titel (één zin die de story beschrijft)
Verhaal:
Als een [rol]
Wil ik [feature]
Zodat [waarde]
Accepteer criteria: (gepresenteerd als Scenarios)
Scenario 1: Titel
Gegeven [context]
en [wat meer context]…
Wanneer [gebeurtenis]
Dan [outcome]
en [nog een outcome]…
Scenario 2: …
De beste stories komen tot stand door gezamenlijke input. We doen dit in meetings, waar we de planning bespreken. Deze zijn intensief en kunnen zelfs een hele dag duren. Hierna zijn echter alle betrokken op de hoogte van wat we gaan doen. Dit levert later in het project heel veel voordeel op (zie ook thrasing). De meetings worden voor elke release herhaald.
Om een voorbeeld te geven van een story en tegelijkertijd te laten zien hoe complex dit kan worden gebruiken we het pinnen van geld bij een bankautomaat:
Story: Klant pint geld
Als een klant
Wil ik geld uit een bankautomaat halen
Zodat ik geld heb wanneer de bank dicht is
Scenario 1: Mijn rekening heeft voldoende geld
Gegeven dat er 100 euro op mijn rekening staat
En dat mijn pincode juist is
En dat er genoeg geld in de automaat zit
Wanneer de klant 20 euro vraagt
Dan moet de automaat 20 euro geven
En mijn rekening moet 80 euro bevatten
En mijn kaart moet worden terug gegeven
Scenario 2: Onvoldoende geld op de rekening
Gegeven dat er 10 euro op mijn rekening staat
En dat mijn pincode juist is
En dat er genoeg geld in de automaat zit
Wanneer de klant 20 euro vraagt
Dan moet de automaat geen 20 euro geven
En de automaat moet zeggen dat er onvoldoend geld is
En mijn rekening moet 10 euro bevatten
En mijn kaart moet worden terug gegeven
Scenario 3: Pincode is onjuist
Gegeven dat mijn pincode onjuist is
Wanneer de klant 20 euro vraagt
Dan moet de automaat zeggen dat de pincode onjuist is
En dat er nog 2 pogingen over zijn
Scenario 4: Pincode is driemaal onjuist…
Heb je het allemaal doorgenomen? Waarschijnlijk niet en dit is nog lang niet alles voor deze story ‘klant pint geld’.
Het hele verhaal is namelijk erg complex! Eenvoudiger is de functionele eis bij een developer neer te leggen: “Een klant moet kunnen pinnen”, zonder verdere informatie. Een goede developer zal dan doorvragen, maar te vaak gebeurd het dat, of de klant niet goed weet hoe het precies in elkaar zit, of de developer de eis accepteert zonder een besef van de complexiteit te hebben. Dit zorgt voor gumption traps als “dit is niet waarom ik gevraagd heb” of “ik ben je vergeten te vertellen over dit ene extra ding”.
Software ontwikkeling is complex. Volgens mij dusdanig dat het onmogelijk is vooraf de hoeveelheid werk goed in te schatten. Agile ontwikkelmethode zijn een must. Ik ben ervan overtuigd dat dit de reden is dat zoveel ICT-projecten niet slagen of niet tevreden worden opgeleverd. Stap dus niet in deze valkuil! Alleen door het gebruik van stories kun je dit vermijden.
Om overzicht te bewaren kun je de stories ook nog opknippen in deel verhalen:
- Klant pint geld (aanname: automaat werkt en de pincode is geldig)
- Klant pint geld met onjuist pincode (aanname: automaat werkt)
- Klant pint geld bij defecte automaat (aanname: pincode is geldig)
Dit stelt je beter in staat de stories te bespreken en demonstraties te geven dat de stories werken. Vaak kun je stories groeperen onder bepaalde onderwerpen van het te bouwen platform. Een groep stories bij elkaar noemen we Epics.
Dan North geeft je meer advies over waar je op moet letten bij het opstellen van stories.
Software development tools
Het aantal stories kan aardig oplopen. Voor een klein project zijn dit er toch al snel 20. Een complexer project kan er wel tot enkele honderden hebben. Als je bedenkt dat er vervolgens met een heel team aan gewerkt moet worden en iedereen met zijn eigen taken en workflow heeft, dan is er al snel een goede tool nodig.
Voor kleine projecten raad ik aan eens te kijken naar tools als Pivotal Tracker. Een eenvoudig te gebruiken tool met heldere user interface.
Wanneer je een complexere workflow hebt zijn er meer uitgebreide (en duurdere) tools beschikbaar zoals:
- Jira (+ Greenhopper)
- PlanBox
- Waypoint (van Nederlandse bodem)
- KanBan Tool
- Redmine (open source)
- GitHub + Huboard
Zelf hebben we voor PlanBox gekozen. Omdat onze klanten (product owners) ook toegang krijgen tot het systeem is het belangrijk dat het gebruiksvriendelijk is. Daarnaast moet het wel onze OTAP-werkwijze ondersteunen en een goede API hebben. PlanBox voldoet goed op dit moment, al hebben we wel bijna dagelijks contact met hun developers om de tool nog beter te maken.
PlanBox integreert ook goed met Zendesk (support) en BugDigger (bugs reporting). Overigens gebruiken we ook nog steeds Basecamp voor ons projectmanagement.
How-to-demo en geautomatiseerd testen
Na elke ontwikkelfase dient de klant de stories te controleren en goed te keuren. Als je je verhaal goed hebt uitgeschreven, kan de klant (of samen) alle stories één voor één doornemen en vervolgens afvinken. Dit is van belang om de verantwoordelijkheid te bepalen, wanneer later iets stuk gaat. Is het door de klant gecontroleerd en geaccepteerd en gaat daarna iets op de server stuk, of veranderd iets in een browser waardoor de story niet meer klopt, dan ligt de schuld (en dus de rekening) niet direct bij de ontwikkelaar.
Het doorlopen van how-to-demo’s voor stories moet vaak in meerdere browsers en soms op meerdere devices gebeuren, een behoorlijk karwei. Als er 100 stories zijn en deze moeten in 5 browsers getest worden dan moeten er 500 stories doorlopen worden, bij elke nieuwe release van het platform! Dit is in de praktijk handmatig niet goed te doen. Daarom kijken we bij GoalGorilla op dit moment naar oplossingen zoals Behat en Mink (met o.a. Selenium). Het mooie is dat ook zij behaviour-driven testen, je opgestelde stories kunnen automatisch getest worden tegen je gemaakte applicatie:
Erg gaaf!!
