Balancing the PendulumReflecting on BDD in practiceZach Dennis, Mutually Human SoftwareGreat Lakes Ruby Bash 2010
BDDImplementing an applicationby describing its behaviour from the stakeholders perspective
3 Principles1. Enough is enough2. Deliver stakeholder value3. It’s all behaviour
TrustThe glue that holds it together
7 areasof reflection
Outside-inUI/UXStakeholderStories & Acceptance CriteriaAutomationDoing it example firstSpikes
Pre Outside-in
“A man without a purpose is like a ship without a rudder.”
-- THOMAS CARLYLE
It’s easy to write code you don’t need
It’s easy to invent code you think you’ll need
It’s easy to write code that is awkward to use
Outside-in acts as the rudder, steering the boat.
Outside-in
Outside-inSTAKEHOLDER PERSPECTIVE
ACCEPTANCE CRITERIA
UI/UX
VIEWS
CONTROLLERS
MODELS
DATABASE
STORIES
FEATURES
Outside-inis value/need driven from the stakeholder perspective
Outside-inprovides a starting point
Outside-inidentifies where to go next
Outside-inhelps define done-ness
UI/UX
UI/UXThe invisible elephant(except to designers)
Developers are not designers.
Different hats entirely.
Switch if necessary, but don’t develop + design.
Usability matters
Tracking expensesA real world example
Agile + UX: ConvergenceJohn Hwang has a great talk
Stakeholders
Expect to fight for stakeholder involvement
Most stakeholdersdon’t care about BDD
52% of agile projects report challenges getting stakeholder involvement
SOURCE: DR DOBBS NOVEMBER STATE OF THE UNION SURVEY
SOURCE: SCOTT AMBLER, BUSTING THE MYTHS OF AGILE DEV.
15% of agile projects report resistance from stakeholders
SOURCE: DR DOBBS NOVEMBER STATE OF THE UNION SURVEY
SOURCE: SCOTT AMBLER, BUSTING THE MYTHS OF AGILE DEV.
32% of agile projects report challenges getting trust
SOURCE: DR DOBBS NOVEMBER STATE OF THE UNION SURVEY
SOURCE: SCOTT AMBLER, BUSTING THE MYTHS OF AGILE DEV.
Stories & Acceptance Criteria
9 out of 10 stakeholdersdon’t author stories or acceptance criteria
Stakeholdersprefer other communicationmethods
Stories & acceptance criteriaare natural to developersnot stakeholders
Having 2 folks helps to converse and record
Popping the “why” stack
SPOILER ALERT
Not every answer is a going to be a good one
Automation
Not everythinghas to be automated
Unit-level examplesYES
DeploymentsYES
Acceptance-level examplesMAYBE
Automation isn’t free.time, moneyvalue, riskcommitment, requirement
Goalsfail fast, feedbackreflect, adaptimprove, balance(iterate)
Unit-level examplesAutomateAutomateAutomate
High level scenariosAutomateExploreScript
Computers do it “... faster, better, stronger.”
They also don’t notice anything you don’t tell them to notice.
In-browser automationis still evolving
Doing it example first(er... TDD)
Example firstdrives out design,less code,better code,regression
Doing it welltakes experience,exploration,reflection,courage,willingness to change
Peoplehave varying levels of experience
Inexperiencebad examplesbrittle exampleshard to maintain
Outside-in is a way of thinkingbefore it is a hard-fast rule
Higher level examplesprovide implementation flexibility
When in doubt spikenot test
Spikes
A 15 minute spike can save you 15% or more on your next feature
Spikes aren’t BDD per-sayjust simple awesome
Spikes aren’t this complex
A spike istime-boxed,communicated,example / test free,exploratory
A spikesaves time,save money,provide learning,provides experience
Recap
Outside-inUI/UXStakeholderStories & Acceptance CriteriaAutomationDoing it example firstSpikes
Thank you
