Balancing the Pendulum: Reflecting on BDD in Practice

1,660 views

Published on

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.

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,660
On SlideShare
0
From Embeds
0
Number of Embeds
26
Actions
Shares
0
Downloads
29
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Balancing the Pendulum: Reflecting on BDD in Practice

  1. 1. Balancing the Pendulum Reflecting on BDD in practice Zach Dennis, Mutually Human Software Great Lakes Ruby Bash 2010
  2. 2. BDD Implementing an application by describing its behaviour from the stakeholders perspective
  3. 3. 3 Principles 1. Enough is enough 2. Deliver stakeholder value 3. It’s all behaviour
  4. 4. Trust holds it together The glue that
  5. 5. 7 areas of reflection
  6. 6. Outside-in UI/UX Stakeholder Stories & Acceptance Criteria Automation Doing it example first Spikes
  7. 7. Pre Outside-in
  8. 8. “A man without a purpose is like a ship without a rudder.” -- THOMAS CARLYLE
  9. 9. It’s easy to write code you don’t need
  10. 10. It’s easy to invent code you think you’ll need
  11. 11. It’s easy to write code that is awkward to use
  12. 12. Outside-in acts as the rudder, steering the boat.
  13. 13. Outside-in
  14. 14. Outside-in STAKEHOLDER PERSPECTIVE STORIES ACCEPTANCE CRITERIA UI/UX VIEWS CONTROLLERS MODELS DATABASE FEATURES
  15. 15. Outside-in is value/need driven from the stakeholder perspective
  16. 16. Outside-in provides a starting point
  17. 17. Outside-in identifies where to go next
  18. 18. Outside-in helps define done-ness
  19. 19. UI/UX
  20. 20. UI/UX The invisible elephant (except to designers)
  21. 21. Developers are not designers.
  22. 22. Different hats entirely.
  23. 23. Switch if necessary, but don’t develop + design.
  24. 24. Usability matters
  25. 25. Tracking expenses A real world example
  26. 26. Agile + UX: Convergence John Hwang has a great talk
  27. 27. Stakeholders
  28. 28. Expect to fight for stakeholder involvement
  29. 29. Most stakeholders don’t care about BDD
  30. 30. 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
  31. 31. 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. 32. 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
  33. 33. Stories & Acceptance Criteria
  34. 34. 9 out of 10 stakeholders don’t author stories or acceptance criteria
  35. 35. Stakeholders prefer other communication methods
  36. 36. Stories & acceptance criteria are natural to developers not stakeholders
  37. 37. Having 2 folks helps to converse and record
  38. 38. Popping the “why” stack
  39. 39. SPOILER ALERT
  40. 40. Not every answer is a going to be a good one
  41. 41. Automation
  42. 42. Not everything has to be automated
  43. 43. Unit-level examples YES
  44. 44. Deployments YES
  45. 45. Acceptance-level examples MAYBE
  46. 46. Automation isn’t free. time, money value, risk commitment, requirement
  47. 47. Goals fail fast, feedback reflect, adapt improve, balance (iterate)
  48. 48. Unit-level examples Automate Automate Automate
  49. 49. High level scenarios Automate Explore Script
  50. 50. Computers do it “... faster, better, stronger.”
  51. 51. They also don’t notice anything you don’t tell them to notice.
  52. 52. In-browser automation is still evolving
  53. 53. Doing it example first (er... TDD)
  54. 54. Example first drives out design, less code, better code, regression
  55. 55. Doing it well takes experience, exploration, reflection, courage, willingness to change
  56. 56. People have varying levels of experience
  57. 57. Inexperience bad examples brittle examples hard to maintain
  58. 58. Outside-in is a way of thinking before it is a hard-fast rule
  59. 59. Higher level examples provide implementation flexibility
  60. 60. When in doubt spike not test
  61. 61. Spikes
  62. 62. A 15 minute spike can save you 15% or more on your next feature
  63. 63. Spikes aren’t BDD per-say just simple awesome
  64. 64. Spikes aren’t this complex
  65. 65. A spike is time-boxed, communicated, example / test free, exploratory
  66. 66. A spike saves time, save money, provide learning, provides experience
  67. 67. Recap
  68. 68. Outside-in UI/UX Stakeholder Stories & Acceptance Criteria Automation Doing it example first Spikes
  69. 69. Thank you

×