Detta är en sammanfattning av Liz Keogh's kurs i Behaviour Driven Development (BDD) som hon höll 10 oktober 2014. En heldag på Konsert & Kongress i samband med DevLin 2014.

Tanken med BDD är att föra samman användaren med utvecklaren (kravställaren med teamet). Målet är att de båda, genom kontinuerlig konversation och kommunikation, ska komma fram till hur systemet ska bete sig i ett givet sammanhang när en viss händelse inträffar. I samtalet används vanligt språk så att båda parter förstår vad som ska ske. Parterna når målet genom att samtala och genom att besvara ett antal frågor och ge belysande exempel. BDD är lämpligt att använda för komplicerade funktioner. Dock bör man undvika det när funktionerna är komplexa. Man ska inte heller använda BDD för sådant som är helt självklart.

Kravställaren och teamet möts alltså för att diskutera och komma fram till hur systemet ska bete sig. De gör detta genom att använda vanligt språk och genom att hela tiden ge mer och mer specifika och belysande exempel. För detta använder man en given syntax.

Syntaxen är viktig; Liz återkommer till den gång på gång.

Given a context

When an event is caused

Then an outcome should occur

BDD är ett sätt att ta fram valideringskriterier i förväg. BDD är nära släkt med TDD (test driven development). I och med att man hela tiden använder en given syntax i kombination med att exemplen blir mer och mer specifika (genom kommunikation och frågeställningar) lämpar sig detta väl att kombinera med verktyg för TDD, t ex Cucumber.

Frågorna som man hela tiden ställer:

• Who is the stake holder; who fought for this?
• Why are we doing this?
• Give me an example!
• Is there anything different about what we’re doing? What will it get for us that we don't already have?
• Is there any context which, for the same event, will give us different outcomes? (context questioning)
• Is there any other outcome that’s important? If we could do it with ”pixies”, would it be enough? (outcome questioning)

Hon återkommer hela tiden till uppmaningen - ”ge ett exempel!”. Hon menar att om man inte kan ge verkliga exempel, t ex om man saknar en verklig kravställare eller verklig användare, då kan man skriva roliga och fåniga exempel. Det är helt okej!

Liz delar upp features i diskreta och icke-diskreta. Features som är icke-diskreta är sådant som inte sker vid ett visst enskilt tillfälle utan som görs löpande (continuous). Exempel på detta kan vara: underhålla kod (maintainability) eller prestanda (performance). Då bör man ändå försöka exemplifiera dessa genom att göra om dem till diskreta, typiskt övervakning (monitoring). På så vis kan man skriva lämpliga exempel ändå.

Hon menar att man ska uppmuntra olika åsikter; uppmuntra diskussioner kring olika uppfattningar. Detta stimulerar tanken och kan få problem att bubbla upp till ytan. Hon föreslår att man kan dela in teamet i små grupper med likatänkande och be dem att först diskutera i de små grupperna. Därefter diskuterar man i hela teamet. Då får man en intressant diskussion som kan bära frukt.

För att förstå komplexiteten i det man vill göra bör man kategorisera enligt följande:

Who has done this before?

5. No one in the world

4. Someone in the world, but not here

3. Someone we have access to

2. Someone on the team

1. We all know how to do it!

5 och 4 faller inom ramen för komplexa funktioner och lämpar sig inte för BDD. Däremot 3 och 2 lämpar sig utmärkt; de klassificerar Liz som komplicerade. Slutligen 1 är skåpmat, enkelt, och finns redan någonstans i systemet och man kan bara återanvända den koden (t ex login). Man använder inte BDD för 1:or.

5 och 4 är högriskare och ska alltid analyseras först. Det finns en tendens i projekt att skjuta på dessa eftersom de är svåra att angripa och risken är då stor att det mest komplexa och tidskrävande hamnar längst ner i backlogen.

Cynefin (uttalas kinevin) är ett annat sätt att klassificera krav och behov. Den modellen stämmer rätt väl med klassificeringen ovan. Hon placerar in siffrorna i modellen.

Liz menar att features typiskt genomgår en viss utveckling. När man har något som är annorlunda och sticker ut jämfört med konkurrenterna kallar hon det differentiator. När en konkurrent upptäcker detta och kopierar, kategoriserar hon det spoilers. Efterhand blir dessa features skåpmat som hon kallar commodities och de är repeterbara (repeatable). Man måste då se till att hitta på något nytt för att vara annorlunda och sticka ut.

Vill du veta mer?

”Deliberate Discovery”, Dan North

”Commitment”, Chris Matts; Olav Maassen; Chris Georg

slideshare.net/lunivore (Liz's bilder)

lizkeogh.com