Bdd for Life
•Télécharger en tant que PPTX, PDF•
6 j'aime•1,626 vues
Described as a "woolly, fluffy, boring talk" by some and "amazing and lifechanging" by others, this talk brings the patterns of BDD - testing, and learning through the definitions of those tests - to real life and the pursuit of our personal goals. Please see the Notes (next to Comments) - I have annotated these for easy reading.
Recommandé
Contenu connexe
En vedette
Similaire à Bdd for Life
Similaire à Bdd for Life (20)
Bdd for Life
- 4. An Example of an Example Given Fred has bought a microwave And the microwave cost £100 When we refund the microwave Then Fred should be refunded £100.
- 5. Examples Given a context When an event happens Then an outcome should occur
- 7. GROW Given a context When an event happens Then an outcome should occur Goal
- 8. GROW Given a context When an event happens Then an outcome should occur Reality
- 9. GROW Given a context When an event happens Then an outcome should occur Options / Way Forward
- 11. Acceptance criteria vs. Scenarios Given Fred has bought a microwave And the microwave cost £100 And the microwave was on 10% discount When we refund the microwave Then Fred should be refunded £90.
- 12. Acceptance criteria vs. Scenarios Given an item was sold with a discount When a customer gets a refund Then he should only be refunded the discounted price.
- 13. Acceptance criteria vs. Scenarios Items should be refunded at the price at which they were sold.
- 15. Examples Given Jane would like some tools for changing her life When she comes to my talk Then she should leave happy.
- 16. “leave happy”
- 17. Will it actually happen that way?
- 18. Acceptance criteria vs. Scenarios I want people to have happier lives because of this talk.
- 20. Cynefin Simple ComplicatedComplex Chaotic With thanks to David Snowden and Cognitive Edge Kuh-neh-vin
- 21. Cynefin With thanks to David Snowden and Cognitive Edge Disorder
- 22. Cynefin SimpleChaotic With thanks to David Snowden and Cognitive Edge
- 25. Talking through outcomes works really well… …hereish.
- 26. Is there a context in which this event will create a different outcome?
- 27. Examples Given Jane would like some tools for changing her life When she comes to my talk Then she should leave happy.
- 28. Examples Given Steve thinks he can’t change his life And he can When he comes to my talk Then he should leave feeling troubled and uncertain.
- 29. Examples Given I am a deep sleeper When I fly to Chicago Then I should still wake refreshed and ready to speak next day.
- 30. Is this the only outcome that matters? If we could achieve it with pixies, would it be enough?
- 31. Examples Given Steve thinks he can’t change his life And he can When he comes to my talk Then he should leave feeling troubled and uncertain And he should get in touch
- 33. “Should”
- 34. Examples Given Dan knows more about BDD than I do When he comes to my talk Then ...?
- 35. Dan North’s “Three Ages” Explore: Optimise for Discovery Stabilize: Optimize for Repeatability Commoditize: Optimize for Efficiency
- 38. GROW Given a context When an event happens Then an outcome should occur Options / Way Forward
- 40. Vision Makes money Saves money Protects money
- 43. Feature User interface component which enables a capability
- 44. Story A slice through a feature to enable faster feedback
- 45. Scenario An example of how the system might behave from a user perspective
- 51. Goal Scenario Goal Feature A Real Project Vision Goal Capability Capability Feature Feature Story Story Story Scenario Code Code Code Whoops, forgot Oops, didn’t know about that… Look what I found! Don’t need this… Can’t remember what this was for…
- 52. Goal Scenario Goal Feature A Real Project Vision Goal Capability Capability Feature Feature Story Story Story Scenario Code Code Code Whoops, forgot Oops, didn’t know about that… Look what I found! Don’t need this… Can’t remember what this was for… Um Er… Oh! Oh F… Dammit! Hmm! That’s funny! Ooh, look! Interesting! Sh..! Oops!
- 53. We’re discovering how to build software by doing it Vision Goal Goal Goal Capability Capability Feature Feature Feature Story Story Story Scenario Scenario Code Code Code
- 54. We’re discovering how to discover stuff by doing it Whoops, forgot Oops, didn’t know about that… Look what I found! Don’t need this… Can’t remember what this was for… Um… Er… Oh! Oh F… Dammit! Hmm! That’s funny! Ooh, look! Interesting! Sh..! Oops!
- 56. Options have value. Options expire. Never commit early unless you know why.
- 57. BDD Less Rework Developers Testers Deliberate discovery skillz Testers
- 60. A Naïve Scenario CONTEXT EVENT OUTCOME Well-formed outcome Event which leads to the outcome Reality. It’s all good, right?
- 61. Reality. It’s all good, right? Subgoals CONTEXT EVENT OUTCOME Well-formed outcome Event which leads to the outcome Unwanted Context Unwanted Outcome!
- 62. Unwanted Context Subgoals CONTEXT EVENT OUTCOME Well-formed outcome Event which leads to the outcome Replacement context Unwanted Outcome!
- 63. Given Scenario CONTEXT EVENT OUTCOME Well-formed outcome Event which leads to the outcome Unwanted Context Replacement context EVENT OUTCOME Event which leads to replacement
- 64. Changing reality CONTEXT EVENT OUTCOME Well-formed outcome Event which leads to the outcome Unwanted Context Replacement context EVENT Event which leads to the replacement CONTEXT
- 65. Creating options Is there any context which we could introduce in which more events would give us outcomes we want?
Notes de l'éditeur
- I wrote this talk for Agile 2010, and added the roadmap for Skills Matter.
- I get very polarised feedback for this talk. Most people love it, but a few people seem to expect something more technical. This isn’t a very technical talk. It’s about life. If you were expecting to find out how to use Cucumber or JBehave, or you’re the kind of person who likes numbers, this talk might not be suitable for you.
- This road map might help you work out where we’re going with this talk, as lots of people reckon they get a bit lost.
- BDD started in about 2003, when Dan North replaced the “test” at the beginning of test methods in TDD with “should”. Read more about it here: http://blog.dannorth.net/introducing-bdd / We also applied the same patterns to scenarios, working at an acceptance test instead of a unit level. That means that we were describing what a system should do for its users, and what a class should do for the other classes that use it. The most powerful aspect of “should” is the ability to ask, “Should it?” That learning and questioning is at the heart of BDD.
- http://www.flickr.com/photos/wwarby/4693654445/ http://creativecommons.org/licenses/by/2.0/deed.en http://www.flickr.com/photos/tambako/820497294/ http://creativecommons.org/licenses/by-nd/2.0/deed.en http://www.flickr.com/photos/ghentooo/3322745430/ http://creativecommons.org/licenses/by/2.0/deed.en A scenario is built using: Given a context, when an event happens, then an outcome occurs. When we play scenarios in real life, we are usually trying to achieve an outcome. We choose the events to take us from where we are, right now, to where we want to be.
- More recently still, Chris Matts has been working on Feature Injection, taking BDD into the Analysis space. Read more here: http:// www.infoq.com /articles/pulling-power Our context in the analysis space is a bit different, as are the tests we use to tell whether we’ve achieved our outcomes. We can define a vision as something which makes money, saves money or protects money. We can question whether we understand enough about our context in which we’re trying to achieve the vision. We then think of the stakeholders who need to be involved in order for the vision to be a success. We can ask, “Is there a context we’re missing? Is there a stakeholder we haven’t taken into account?” When the goals of all the stakeholders have been met, then we can ship the product.
- Next: Scenarios in Real Life
- http://en.wikipedia.org/wiki/File:Rinjani_1994.jpg http://creativecommons.org/licenses/by/2.0/deed.en Reality is merely an event happening in a particular context, where that context has been produced by the events which have gone before. All the way back to the big bang.
- I put this in here to energise the room and help people think about whether this session was applicable. Stand up if these apply to you.
- Seriously, stand up. I know you’re just reading these, but you’ve probably been sitting down for a while. It’ll make you feel better and more energised, so you’ll pay attention to what’s coming up. Go get a cup of tea or something.
- Next: Defining goals and outcomes in Real Life
- http://www.flickr.com/photos/scalespeeder/2652863086/ “ Please feel free to use this image on the web, in print, or wherever, on condition that the photo is credited to (and linked to on the web) to: www.robnunnphoto.com/ ” Well-formed outcomes is an NLP term. You should be able to express your outcomes in terms of what you can see, what you can feel, touch, taste, hear. These are called “modalities”. When you’ve expressed it this way, try thinking, “Is there another way that I could achieve these outcomes?” If the other way doesn’t satisfy what you want, then there’s something missing in your outcomes.
- Next: Some other models which are quite a lot like playing Scenarios in life
- The GROW framework is a common coaching pattern. We define our Goals in terms of well-formed outcomes. We look at where we are now. Then we examine our options for going forward, and find a way which looks sensible.
- Plan, Do, Check, Act is also known as the Shewhart or Deming cycle. http:// en.wikipedia.org /wiki/PDCA It’s often used in process improvement. Plan: Establish a test or set of checks to determine how you will know you have achieved your desired outcome. Do: Implement or perform the work to move towards your outcome. Check: Run the checks determined in the Plan. Have you reached your outcome yet? Act / Adapt / Adjust: If you haven’t reached your outcome, determine which step went wrong or whether you have some different ideas. If you have, work out what outcome you want next.
- This table shows how the three frameworks – BDD’s scenarios, the GROW framework and PDCA – align with each other. The “Act” step in PDCA stands in for reality because it’s the point at which we examine where we are, having made the changes we’ve made. You can see that the GROW framework has no step for reflecting on the success of the chosen way. Andy Palmer suggests “Look Back” as a term for this step, giving us GROWL. BDD adds something to both of these – a step in which we ask whether we understand the context or reality in which we’re acting. We can ask, “Are there any contexts we’re missing?”
- Next: The stuff that this talk has been building up to. This is the longest bit of the presentation. Did you get that cup of tea?
- This is a slide which I have copied from memory from Agile 2009, in which Alistair Cockburn talked about the different decisions which get made on a project. The testers get to make decisions about system correctness. I asked, “Have you come across any companies which have found a way to allow decisions about system correctness to be made before decisions about implementation?” In this scenario, the only way in which testers’ input can flow back into the system is through feedback. This causes rework, also called bugs. It’s one of Taiichi Ohno’s 7 types of waste. In life, bugs like this would be devastating, because frequently we only get one chance to perform the event. We can’t just make a patch for what we just did and ship it to production.
- In BDD, we have a cycle of learning in which everyone is involved. Particularly, we examine the context and consider how to test our outcomes before we go ahead and implement them. NB: The test is not the outcome – it’s just a way of verifying it.
- The previous model came to me from reading Chris Matts’ comic on Feature Injection. In this, he talks about Real Options, which have the rules above. In finance, people will pay for the option to buy something at a particular price, some time in the future. In reality, we talk about “keeping our options open”. Chris introduced me to the idea of paying for those options and creating them for ourselves, even when they don’t exist already. We know that in Agile we commit at the last responsible moment. We may sometimes find it useful to extend that last responsible moment.
- When we decide on our desired outcomes, before we start performing the events to reach them, we can look at the context in which we’re acting. Should this event really produce that outcome? Is there another context which we might have missed in which events might produce a different outcome? In BDD’s scenarios, we can use this to help us have conversations with our stakeholders and reach a common understanding of what it is we’re trying to achieve. In life, we can use this to stop ourselves from acting before we have enough information.
- This act of questioning context is part of what Dan North calls “Deliberate Discovery”. This can also help us find the most risky aspects of what we’re trying to achieve. The most risky stuff is the stuff that we don’t even know we don’t know. We have no idea that the risk even exists. When we know enough to be able to identify the risk, we have an awareness of what we don’t know. Our deliberate discovery should focus on those two areas in that order. A good way of becoming aware of what we don’t know is to talk to people who work in that area already. Insatiable curiousity also helps!
- As well as asking if there are any unexpected contexts, we can look for contexts we wish that we did have. Maybe we will find that we had more options than we thought we did! Perhaps we will also wish that we were in a different context to begin with. There’s an old joke which goes: Driver: Excuse me, mate! How do I get to Dublin? Irishman: Well, I wouldn’t start from here! What if we didn’t have to start from the context we find ourselves in right now? What would you be able to achieve that you can’t?
- If we can specify our desired outcomes, and our tests for those outcomes, in the smallest and most specific ways, then we have more options for achieving it. The outcome of “I want to be an airline pilot” has fewer options than “I want to have a job which lets me travel”, which has fewer options than “I want to be able to see the clouds from above, every day.” By focusing on our outcomes in this specific way, we start unconsciously looking for ways to achieve those outcomes. We will find ourselves prepped for events which occur that might help us, so that we can take advantage of them. This is why positive visualisation often works – because we know we will achieve our goal, so we start creating a context in which the achievement can happen.
- If you have unwanted contexts, then you won’t get the outcome you want either!
- What if we could change our context and provide a replacement for that context instead? Then we would get the outcome we actually want. Perhaps we could provide an additional context. Perhaps we could replace a context or provide a context which gives us more options. Then we will have more resilience, through the options we create, for the unexpected contexts we will inevitably discover.
- If we had a replacement context already, then we would be able to play our original life-scenario and achieve our outcome. This is BDD’s “Given Scenario”. Given this scenario has already happened When I perform this event Then I will get this outcome.
- So we can play our Given Scenario before our main scenario. We are changing the context in which we started. We are changing our reality so that we start in a more favourable place. This is what I really wanted to share with you.
- Next: Some stuff that people, including me, often get wrong.
- Eventually, we have to act. Gathering all the information up-front is impossible. We will always encounter the unexpected. We ourselves are unexpected. Our desires and the things we want from life will change. Sometimes it’s better to act and see what happens than collect all the information.
- http://www.flickr.com/photos/cmogle/3526750763/ http://creativecommons.org/licenses/by/2.0/deed.en It’s worth learning about systems thinking if you want to do this. I like “The Art of Systems Thinking” by Joesph O’Connor and Ian McDermot. Jean Tabaka, one of the best Systems Thinking teachers I know, recommends “The Fifth Discipline” by Peter M. Senge. I haven’t read my copy yet. Basically, your actions will have effects on other people’s actions. Your reality is other people’s reality too. I sometimes put on my “evil hat” to think about the possible negative consequences of a change: http://lizkeogh.com/2010/01/06/the-evil-hat/
- http://www.flickr.com/photos/dvids/3774998205/ http://creativecommons.org/licenses/by/2.0/deed.en Chris Matts has warned me to be careful in the past. When we create an option for ourselves, sometimes people can think that we intend to pursue the option. We would like the right without the obligation. If people don’t realise that this is what we’re doing, they can create the obligation for us! For instance, if I say that I might want to go on holiday in September, maybe I won’t get an invite to the party that my friend decides to host in September, unless I make it clear that I’m not committed yet. Sometimes making commitments can be motivating. For instance, I went on a 10k run. I paid £30 for the option to go on the run. When I started asking for, and getting, sponsorship, I was committed to doing it. That got me out and training even in the rain.
- http://www.flickr.com/photos/theogeo/1473491679/ http://creativecommons.org/licenses/by/2.0/deed.en Sometimes people are tempted to lie about their ability to commit or about the outcomes they are pursuing. Sometimes people want to do things which go against their core values in order to achieve their outcomes. There is a part of our unconscious mind which can detect micro-expressions and incongruences which tell us that something isn’t right. Lying is one of the hardest things to do well. It might be easier to examine the context in which we feel the need to lie, then change that. People are considered to have integrity when they deliver on their promises and commitments, and can be trusted by their word.
- http://www.flickr.com/photos/wallrevolution/46957842/ http://creativecommons.org/licenses/by-sa/2.0/deed.en_GB If we try to achieve too many things at once, one or more of them will “drop off the radar”. I have a natural limit of 3 concerns or outcomes I’m working towards at any time. I keep a Kanban board with “Todo”, “In progress” and “Done” columns. I limit myself to 6 things to do and 3 things in progress at any time. I keep my board electronically on the web so I can access it anywhere: http:// leankitkanban.com /
- http://commons.wikimedia.org/wiki/File:Steph_Davis_wingsuit_BASE_brento.jpg http://creativecommons.org/licenses/by-sa/3.0/deed.en You’d be amazed what you can achieve. If someone told me that I could run 10k this time last year, I’d have laughed at them. I had some help from some hypnotherapists to help me believe that I could. This is Steph Davis, jumping off a cliff with a wingsuit on. Wingsuiters are either crazy nutters, or less limited in their self-belief than I am. Possibly both.
- Next: Closing words and an example.
- http://www.flickr.com/photos/urbandecay/364746628/ http://creativecommons.org/licenses/by/2.0/ If you have trouble working out what goals you want to achieve, apply a futurespective to yourself. You are old, close to your last years. You will die fairly soon. Look back on your life. What do people say about you? What do you have around you? What can you see, and touch? What memories do you have? This might help you find the outcomes you want.
- An example: How I planned this talk
- Unwanted contexts are in pink. There are many other contexts which I am glad I have, but I didn’t bother writing them down because these are the ones which are stopping me from being successful. At least the ones I know about! My well-formed outcomes are on the left. I am already committed to the event, because it helped me with some other options and I was confident I could do it.
- These are the contexts I would rather have, in orange.
- Here I’ve moved my unwanted contexts to sit on the left of my coffee table. My new replacement contexts are now a subgoal.
- Now I think of events I can play which will take me to these replacement contexts. I sometimes find it helps to have tests for replacement contexts as well, especially if they’re opening up options and I’m not sure what I’m going to do afterwards.
- These were the tests for after the session. I also got many emails from people asking for these slides, so I’ve annotated them for you. Hope you enjoyed them. Thank you! Liz -- [email_address] http://lizkeogh.com http://lunivore.com Twitter: lunivore
- Questions to: [email_address] http://lizkeogh.com http://lunivore.com Twitter: lunivore