• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Balancing the Pendulum: Reflecting on BDD in Practice
 

Balancing the Pendulum: Reflecting on BDD in Practice

on

  • 1,805 views

Here are the slides that I used for my talk on "Balancing the pendulum: Reflecting on BDD in Practice" at the Great Lakes Ruby Bash, April 17th, 2010 in Lansing, MI. ...

Here are the slides that I used for my talk on "Balancing the pendulum: Reflecting on BDD in Practice" at the Great Lakes Ruby Bash, April 17th, 2010 in Lansing, MI.

This talk was aimed at sharing my reflections and experiences on how BDD and outside-in development has been working over the past few years.

Statistics

Views

Total Views
1,805
Views on SlideShare
1,783
Embed Views
22

Actions

Likes
4
Downloads
24
Comments
0

3 Embeds 22

http://speakerrate.com 18
http://www.slideshare.net 2
http://www.slashdocs.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Balancing the Pendulum: Reflecting on BDD in Practice Balancing the Pendulum: Reflecting on BDD in Practice Presentation Transcript

    • Balancing the Pendulum Reflecting on BDD in practice Zach Dennis, Mutually Human Software Great Lakes Ruby Bash 2010
    • BDD Implementing an application by describing its behaviour from the stakeholders perspective
    • 3 Principles 1. Enough is enough 2. Deliver stakeholder value 3. It’s all behaviour
    • Trust holds it together The glue that
    • 7 areas of reflection
    • Outside-in UI/UX Stakeholder Stories & Acceptance Criteria Automation Doing it example first Spikes
    • 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-in STAKEHOLDER PERSPECTIVE STORIES ACCEPTANCE CRITERIA UI/UX VIEWS CONTROLLERS MODELS DATABASE FEATURES
    • Outside-in is value/need driven from the stakeholder perspective
    • Outside-in provides a starting point
    • Outside-in identifies where to go next
    • Outside-in helps define done-ness
    • UI/UX
    • UI/UX The invisible elephant (except to designers)
    • Developers are not designers.
    • Different hats entirely.
    • Switch if necessary, but don’t develop + design.
    • Usability matters
    • Tracking expenses A real world example
    • Agile + UX: Convergence John Hwang has a great talk
    • Stakeholders
    • Expect to fight for stakeholder involvement
    • Most stakeholders don’t care about BDD
    • 52% of agile projects report challenges getting stakeholder involvement SOURCE: SCOTT AMBLER, BUSTING THE MYTHS OF AGILE DEV. SOURCE: DR DOBBS NOVEMBER STATE OF THE UNION SURVEY
    • 15% of agile projects report resistance from stakeholders SOURCE: SCOTT AMBLER, BUSTING THE MYTHS OF AGILE DEV. SOURCE: DR DOBBS NOVEMBER STATE OF THE UNION SURVEY
    • 32% of agile projects report challenges getting trust SOURCE: SCOTT AMBLER, BUSTING THE MYTHS OF AGILE DEV. SOURCE: DR DOBBS NOVEMBER STATE OF THE UNION SURVEY
    • Stories & Acceptance Criteria
    • 9 out of 10 stakeholders don’t author stories or acceptance criteria
    • Stakeholders prefer other communication methods
    • Stories & acceptance criteria are natural to developers not 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 everything has to be automated
    • Unit-level examples YES
    • Deployments YES
    • Acceptance-level examples MAYBE
    • Automation isn’t free. time, money value, risk commitment, requirement
    • Goals fail fast, feedback reflect, adapt improve, balance (iterate)
    • Unit-level examples Automate Automate Automate
    • High level scenarios Automate Explore Script
    • Computers do it “... faster, better, stronger.”
    • They also don’t notice anything you don’t tell them to notice.
    • In-browser automation is still evolving
    • Doing it example first (er... TDD)
    • Example first drives out design, less code, better code, regression
    • Doing it well takes experience, exploration, reflection, courage, willingness to change
    • People have varying levels of experience
    • Inexperience bad examples brittle examples hard to maintain
    • Outside-in is a way of thinking before it is a hard-fast rule
    • Higher level examples provide implementation flexibility
    • When in doubt spike not test
    • Spikes
    • A 15 minute spike can save you 15% or more on your next feature
    • Spikes aren’t BDD per-say just simple awesome
    • Spikes aren’t this complex
    • A spike is time-boxed, communicated, example / test free, exploratory
    • A spike saves time, save money, provide learning, provides experience
    • Recap
    • Outside-in UI/UX Stakeholder Stories & Acceptance Criteria Automation Doing it example first Spikes
    • Thank you