84
This is an extract; the full document can be downloaded from http://www.slideshare.net/lunivore/ behavior-driven-development-11754474 1 1

Bdd Liz Keogh

Embed Size (px)

DESCRIPTION

Behaviour Driven Development

Citation preview

Page 2: Bdd Liz Keogh

BehaviourDrivenDevelopment

Liz Keogh@lunivore

2

Page 3: Bdd Liz Keogh

Behaviour-Driven

DevelopmenFeature Injection

Cynefin and Differentiati

onSplitting Stories

3

Page 4: Bdd Liz Keogh

BDDuses examples

to illustrate behavior

4

Page 5: Bdd Liz Keogh

An Example of an Example

Given Fred has bought a microwaveAnd the microwave cost £100

When we refund the microwaveThen Fred should be refunded

£100.

5Given, When and Then are the key bits here. Using “and” or “but” signifies that the step is the same type as the previous one.

Page 6: Bdd Liz Keogh

An Example of an Example

Given baby rabbits cost £10When we sell Snowy the Baby Rabbit

Then the customer should be charged £10.

6Given, When and Then are the key bits here. Using “and” or “but” signifies that the step is the same type as the previous one.

Page 7: Bdd Liz Keogh

Examples

Given a contextWhen an event happens

Then an outcome should occur

7

Page 8: Bdd Liz Keogh

“Given Scenario” – an antipattern

Given Fred puts a microwave in the basket

And the microwave cost £100When Fred buys the microwave

Then he should be charged £100When we refund the microwave

Then Fred should be refunded £100.

8This is actually two scenarios.

The first scenario is concerned with payments. The second scenario is concerned with refunds. The first scenario is setting up the context for the second scenario.

Talking through scenarios like this is absolutely fine. If you capture them, you might want to separate the two scenarios. As we’ll see later when we start looking for different outcomes and more interesting scenarios, once things start getting complicated these scenarios can be hard to maintain.

Usually, if you see this, you’ll find there are either two different concerns in play, or that one of the scenarios is redundant.

Page 9: Bdd Liz Keogh

Cucumber

Feature: Addition In order to avoid silly mistakes As a math idiot I want to be told the sum of two numbers Scenario: Add two numbers Given I have entered 50 into the calculator And I have entered 70 into the calculator When I press add Then the result should be 120 on the screen

9There are tools available which will take your English-language steps and turn them into real automated regression tests! Cucumber, Cucumber for the JVM, SpecFlow and JBehave are all examples of system-level BDD tools. There are others which run against smaller elements of code or classes, such as RSpec and MSpec, but you don’t have to worry about those unless you’re a developer.

Page 10: Bdd Liz Keogh

Cucumber

Feature: Addition In order to avoid silly mistakes As a math idiot I want to be told the sum of two numbers Scenario: Add two numbers Given I have entered 50 into the calculator And I have entered 70 into the calculator When I press add Then the result should be 120 on the screen

This is what most peopleassociate with BDD

9There are tools available which will take your English-language steps and turn them into real automated regression tests! Cucumber, Cucumber for the JVM, SpecFlow and JBehave are all examples of system-level BDD tools. There are others which run against smaller elements of code or classes, such as RSpec and MSpec, but you don’t have to worry about those unless you’re a developer.

Page 11: Bdd Liz Keogh

10

Page 12: Bdd Liz Keogh

11However, the conversations are the most important bit, so start with those.

Page 13: Bdd Liz Keogh

11However, the conversations are the most important bit, so start with those.

Page 14: Bdd Liz Keogh

BDD is about having conversations

11However, the conversations are the most important bit, so start with those.

Page 15: Bdd Liz Keogh

12Remember that the point of BDD is to create working software. If you find that it’s getting in the way of that, you’re probably focusing too much on the process, and too little on the goal.

Page 16: Bdd Liz Keogh

BDD should make it easyto create software

12Remember that the point of BDD is to create working software. If you find that it’s getting in the way of that, you’re probably focusing too much on the process, and too little on the goal.

Page 17: Bdd Liz Keogh

13A lot of teams that use BDD insist on having very clear examples for everything they attempt. As we’ll see later, some things resist well-defined outcomes, especially when they’re very new or innovative. BDD should be a collaboration tool, not a contractual one; it’s about trying to understand what the business want, not making it “their fault” if we end up producing the wrong thing.

Page 18: Bdd Liz Keogh

A scenario is an idea, not a promise

13A lot of teams that use BDD insist on having very clear examples for everything they attempt. As we’ll see later, some things resist well-defined outcomes, especially when they’re very new or innovative. BDD should be a collaboration tool, not a contractual one; it’s about trying to understand what the business want, not making it “their fault” if we end up producing the wrong thing.

Page 19: Bdd Liz Keogh

14We should always be looking for what we want next, or what we’ve got wrong, or what we could do differently.

Page 20: Bdd Liz Keogh

A scenario is an idea, not a promise

14We should always be looking for what we want next, or what we’ve got wrong, or what we could do differently.

Page 21: Bdd Liz Keogh

Having conversations

15

Page 22: Bdd Liz Keogh

Having conversationsis more important thancapturing conversations

15

Page 23: Bdd Liz Keogh

Having conversationsis more important thancapturing conversations

is more important thanautomating conversations

15

Page 24: Bdd Liz Keogh

Exercise

Think of thebest conversations

you’ve had.What made them awesome?

16

Page 25: Bdd Liz Keogh

Entertaining

Learning

Questions

ChallengeDifferentopinions

Uncertainty

Shared context

Newpeople

IdeasSupportCertainty

17These were some of the ideas I came up with. Others might be relevance, unexpectedness and surprise, being funny… these can all come into your scenarios, too. Make them memorable.

How many people said, “These are things I value in conversations…” and started listing them, and how many shared stories of conversations they’d had? We are “homo narrans”; we learn best from stories.

Page 26: Bdd Liz Keogh

A storybecause devs love

empty lists

18When I spoke to the Head of Client Management, I said, “Given a client manager has some clients, when he logs in, then he should see his clients. Given he has no clients, what should he see when he logs in then?” I was thinking about the case when they had an empty list of clients.

But the Head of Client Management said, “If you’re a client manager and you have no clients, I’m about to fire you! Get on the phone and get some clients!”

From my dev perspective, I was worried about empty lists. From his perspective, an empty list was a business about to be bankrupted. So that taught me quite a bit about the domain!

Page 27: Bdd Liz Keogh

Boring!Given Fred bought a microwave

And has receipt number 1857123And receipt 1857123 lists it at £100

When we scan the receiptThen the screen should show the list of

itemsWhen we select the microwave

And we refund itAnd scan Fred’s credit card

Then Fred should be refunded £100.

19If you find yourself talking in ways that seem unnatural, you’re probably thinking too hard about the solution, rather than the problem. This is a very solution-focused scenario. Also try and avoid any reference to the UI, as that’s part of the solution space too.

Page 28: Bdd Liz Keogh

Examples

Given a contextWhen an event happens

Then an outcome should occur

20“Should” is a magic word that allows us to question whether an example really should happen.

Page 29: Bdd Liz Keogh

Should it?

21Should it happen now, or should it happen later? Or at all? Should it always happen? Is there a context in which it doesn’t happen?

Page 30: Bdd Liz Keogh

Make sure you get it right

22In Waterfall, we make sure we get it right because it’s expensive to change later. In Agile, we assume we got it wrong to change as quickly as we can. Given I’ve worked on projects which had a years’ worth of analysis and still didn’t get it right, it makes sense to assume that we got it wrong, especially given how little we worked on the requirements! So feedback and keeping things easy to change is essential.

Page 31: Bdd Liz Keogh

Make sure you get it rightAssume you got it wrong

22In Waterfall, we make sure we get it right because it’s expensive to change later. In Agile, we assume we got it wrong to change as quickly as we can. Given I’ve worked on projects which had a years’ worth of analysis and still didn’t get it right, it makes sense to assume that we got it wrong, especially given how little we worked on the requirements! So feedback and keeping things easy to change is essential.

Page 32: Bdd Liz Keogh

Is there a context in whichthis event will createa different outcome?

23This is the pattern I call “context questioning”.

Page 33: Bdd Liz Keogh

Examples

Given Fred has bought a microwaveAnd the microwave cost £100

And the microwave was on 10% discount

When we refund the microwaveThen Fred should be refunded £90.

24

Page 34: Bdd Liz Keogh

Examples

Given Fluffy the baby rabbitis 1 ½ months old

When we try to sell FluffyThen we should be told he’s too

young

25

Page 35: Bdd Liz Keogh

Is this the only outcomethat matters?

If we could achieve it with pixies, would it be enough?

26This is the pattern I call “outcome questioning”.

A pixie is a small person. If you’ve ever read Terry Pratchett’s “Discworld” novels, you’ll know that when you take a photo in the Discworld, a little goblin or person inside the camera quickly paints the picture for you! I sometimes find it helpful to imagine that there are similar tiny people inside all of our machines, painting on the inside of our computer monitors and sitting crouched in our cash machines.

As a developer, I love writing code. I can’t help it! So as soon as you start talking to me about the problem, I start writing software in my head – moving to the solution space. If I can imagine that pixies are going to do the job instead, it makes it much easier to think about, and question, what the pixies should do, instead of the implementation of it.

Page 36: Bdd Liz Keogh

Examples

Given Fred has bought a microwaveAnd the microwave cost £100

When we refund the microwaveThen the microwave should be

added to the stock count.

27I also introduced the example of a cash machine. What else needs to happen if there’s a pixie in the machine giving me my £20? Oh, yes, it needs to debit the account! Now, we know that for a cash machine the two scenarios *cannot* be shipped separately. But for this, they probably can. So talking through scenarios can help you to decide what your scope is, too, as well as uncovering extra scope.

Page 37: Bdd Liz Keogh

Examples

Given each rabbit eats an average of

20g of carrots a dayWhen we sell 10 rabbitsAnd 5 rabbits are born

Then our order for carrots shouldgo down by 700g a week

28I also introduced the example of a cash machine. What else needs to happen if there’s a pixie in the machine giving me my £20? Oh, yes, it needs to debit the account! Now, we know that for a cash machine the two scenarios *cannot* be shipped separately. But for this, they probably can. So talking through scenarios can help you to decide what your scope is, too, as well as uncovering extra scope.

Page 38: Bdd Liz Keogh

Same scenario?

Then Fred should be refunded £100

Then the microwave should be added

to the stock count

29These are two separate aspects of behaviour, so you probably want to put them in different scenarios. It’s OK to get this wrong, though, and if someone comes up with an interesting outcome, it’s probably better just to capture it quickly. Remember that it’s more important to keep the conversation fluid and allow ideas to flow than to do it “right”.

Page 39: Bdd Liz Keogh

Same scenario?

Then I should be given £20

And £20 should be debitedfrom my account

30These are not two separate aspects of behaviour. This is one transaction. It needs to happen in the same scenario, because we can’t ship one without the other. That just isn’t useful.

Page 40: Bdd Liz Keogh

Then my eyes glaze over…When we select “baby rabbit” from the list of petsAnd the customer declines all special offersAnd we want a VAT receiptAnd we select payment by credit cardAnd the customer is presentThen the receipt should say £10And we should have £10 more takingsAnd the number of rabbits in stock should decreaseAnd …

31If you have a scenario that gets like this, you might want to start splitting it up. Nobody is really interested in talking about all these outcomes at once.

Page 41: Bdd Liz Keogh

Then my eyes glaze over moreWhen we click the “Pets” drop-downAnd we select “baby rabbits”And we click “No”And we check “VAT receipt”And we click “Pay”And we select “Credit Card”And we click “Yes”And …

32This is even worse. Focusing on the GUI ties you to a particular GUI. If you ever have a search box instead of a drop down, this is going to be a maintenance nightmare. I can tell from this scenario that whoever wrote it hasn’t actually had any conversations with anyone!

Page 42: Bdd Liz Keogh

Exercise

Come up with two scenarios

withtwo outcomes

from your own work,one of which can be splitand one of which can’t.

(They don’t have to be about software)

33Transactional outcomes often have two different outcomes for two different stakeholders.

Imagine paying someone money online. You want to have some kind of confirmation, don’t you? Would it be OK to pay the other person without getting that confirmation? Or get the confirmation when you haven’t paid? These kind of outcomes have to be shipped together.

Page 43: Bdd Liz Keogh

And you can keep going…

Given Fred has bought a microwaveAnd the microwave cost £100And the microwave is faulty

When we refund the microwaveThen a fault ticket should be

printed.

34As you talk through different scenarios, you’ll find new requirements. If you’re after an MVP (Minimum Viable Product) – the smallest thing that you could usefully ship and make money from or learn from – then think about whether you really *need* to ship the scenario or not. For instance, you could usefully deploy a cash machine which doesn’t work for people who have overdrafts, and it will still cut the bank queues down.

Page 44: Bdd Liz Keogh

Exercise

What other benefitscan you think of

that might come fromtalking through

different scenarios?

35Another benefit we talked about is that developers start using the language in the code, so that they can talk more easily to the business and their code is easier to read and more maintainable.

Page 45: Bdd Liz Keogh

Acceptance criteria vs. Scenarios

Given Fred has bought a microwaveAnd the microwave cost £100

And the microwave was on 10% discount

When we refund the microwaveThen Fred should be refunded £90.

36This is a scenario with specific data. We can’t tell from this what the actual rules are. It’s an exemplar; an example made to *illustrate* behaviour. It’s not really a description of the behaviour.

Page 46: Bdd Liz Keogh

Acceptance criteria vs. Scenarios

Given an item was soldwith a discount

When a customer gets a refundThen he should only be refunded

the discounted price.

37This isn’t a scenario, even though it’s phrased as GWT. It’s acceptance criteria. It’s a description of the behaviour which is true for all the contexts mentioned… unless you can think of another context which changes this!

Page 47: Bdd Liz Keogh

Acceptance criteria vs. Scenarios

Items should be refundedat the price at which they were

sold.

38We don’t need to phrase things as GWT if the scenarios can easily be derived.

Page 48: Bdd Liz Keogh

Acceptance criteria vs. Scenarios

Given Fluffy the baby rabbitis 1 ½ months old

When we try to sellFluffy the baby rabbit

Then we should be toldthat he’s too young

39

Page 49: Bdd Liz Keogh

Acceptance criteria vs. Scenarios

Given a pet is belowrecommended selling age

When we try to sellthat pet

Then we should be toldthat the pet is too young

40This isn’t a scenario, even though it’s phrased as GWT. It’s acceptance criteria. It gives us the rules for all pets, not just rabbits. If someone started with this, we could ask them, “Can you give us an example?” Using concrete examples with real baby rabbits entices our imaginations in a way that abstractions don’t. I bet you even have an image in your head of what colour Fluffy is too!

Page 50: Bdd Liz Keogh

Acceptance criteria vs. Scenarios

We shouldn’t be ableto sell pets

younger than therecommended

selling age

41There are multiple ways of phrasing acceptance criteria. If we can’t imagine scenarios from the criteria then we can create some to help illustrate the behaviour. It’s perfectly OK to capture obvious scenarios in this form – you don’t have to write *everything* down! The trick with BDD is to get to the things we’re discovering which are new as quickly as possible.

Page 51: Bdd Liz Keogh

ExerciseCan you derive some scenariosfrom these acceptance criteria?

The user should be able to add and remove bold, italics and underlines.

When browsing an item, users should be able to see what other users who browsed the item

bought.

Pets shouldn’t be listed for saleuntil they’re old enough.

42When we talked through the examples, a lot of them read as acceptance criteria. I ask concrete questions like, “What’s his name? Can you think of an example of text that Fred might want to make bold? Can you think of an example of that?” Even just repeating “Can you give me an example of that?” usually helps reduce abstract acceptance criteria to something that really fires the imagination.

Page 52: Bdd Liz Keogh

Feature Injection

43When Chris Matts taught me Feature Injection, he explained it in much the way I explained it to you. However, he has some different emphasis that’s worth reading, and is strongly aligned with the later sections on differentiation. Here’s his article on it: http://www.infoq.com/articles/feature-injection-success

Page 53: Bdd Liz Keogh

Vision

Makes moneySaves money

Protects moneyPrimaryStake-holder

44There’s always someone who cares about the project; who has fought to get the budget for it, or perhaps funded it directly. This is the project owner. Everyone else is a proxy.

Page 54: Bdd Liz Keogh

Goal

Neededto go liveIncidental

Stake-holder

45As well as the project owner, there will be several other stakeholders whose needs have to be met in order to go live. Often these are “gatekeeping” stakeholders – security, support, audit, legal, etc. You can engage these stakeholders before-hand and get some tests for their goals.

Tom Gilb is pretty big on quantifying goals. Here’s a good article on it: http://projectmanagement.atwork-network.com/2012/03/20/qa-tom-gilb-on-quantifying-project-objectives/

You may also find my blog post on identifying stakeholders across the whole value stream useful: http://leansystemssociety.org/value-streams-are-made-of-people/

Page 55: Bdd Liz Keogh

Capability

Userscan achievea businessoutcome

Business Analyst

46To deliver the stakeholder goals, we look to see what capabilities are needed. A capability is “the capability to do something”. For instance:

- The capability to trade copper- The capability to book a holiday- The capability to comment on an article- The capability to calculate counterparty exposure

etc. We can also find smaller capabilities within larger ones if we need to. A 1-year, enterprise-wide project in a trading company we used this in had about 30 capabilities for the whole project, some of which were – in a rough estimate – 10 times smaller than others. Capabilities may also be principles that extend across the whole project (security, performance, etc.) They *all* have stakeholders, even the ones we refer to as “non-functional” or “technical”. Working out who the stakeholder for a requirement is, and phrasing it in terms of the business benefit, can really help to narrow down what actually *needs* to be delivered.

Page 56: Bdd Liz Keogh

Feature

User interfacecomponent

which enablesa capability

UIDesigner

47Some capabilities will be delivered in the form of software features. There may be one or many features related to a capability. For instance, in order to comment on an article we may need user registration, comment reporting (in case of spam, vulgarity or libel), and the comment box itself.

The features that we choose to implement may change frequently during a project, especially if the capabilities we’re delivering are new. Capabilities don’t change often, though, so one trick is to find the newest capabilities, and work out a way to get feedback on those quickly!

More on that in the differentiation / Cynefin section.

Page 57: Bdd Liz Keogh

Story

A slice througha featureto enable

faster feedback

Often adeveloper

48The reason we split features into stories is to get feedback and trust. Showing that you’ve delivered *something* that the stakeholders can see and play with is usually more valuable than trying to get a whole “complete vertical slice”. If there’s a way to show progress or get feedback more quickly, do that. Why code an entire slice if you can throw something smaller away?

Page 58: Bdd Liz Keogh

Scenario

An exampleof how the system

might behavefrom a userperspective

Dev, tester,analyst

49Scenarios can be used to help discover the scope of features and capabilities, and to split features into stories. If we can’t think of an example in which a capability or feature proves its value to the business, maybe it won’t…

Page 59: Bdd Liz Keogh

Code

Ideas turning intorealityDeveloper

50And finally, we get to code.

Page 60: Bdd Liz Keogh

Vision Goal Capability Feature Story Scenario Code

51And later on in this talk, I show why this doesn’t actually work as neatly as this diagram shows But it’s a useful model to bear in mind for the moment.

Page 61: Bdd Liz Keogh

Vis Go Ca Fea Sto Sce CoCa

pabi

lit

52We focus on the capability wherever possible because it gives us options for changing the lower-level steps beneath. The features we use to deliver a stakeholders’ goals often change, but the capabilities the business needs to meet those goals rarely do.

Page 62: Bdd Liz Keogh

Vis Go Ca Fea Sto Sce Co

Scen

ario

53We focus on scenarios in BDD because it’s the place where the technical, problem-solving developers and the non-technical business analysts and problem-finding testers meet.

Page 63: Bdd Liz Keogh

Exercise

Who are your stakeholders?

54Who are the stakeholders for your project?

Are there any which are missing? Are there capabilities that are simply delivered as an industry standard? Do you actually need them?

Page 64: Bdd Liz Keogh

Examples can help youdiscover

things early

55

Page 65: Bdd Liz Keogh

Is there a stakeholder for whomthis application will not meet their goal?

56Remember the “context questioning” question? (Do you?)

This is what it looks like when we apply it at the stakeholder level.

Page 66: Bdd Liz Keogh

Are all of the stakeholder’s goalsmet by this?

If we could achieve it with pixies, would it be enough?

57This is what outcome questioning looks like (do you remember that?)

We can also do this for the other levels. Is there some context in which this feature won’t be usable? Is there some market context in which we won’t make money with this?

Page 67: Bdd Liz Keogh

Traditional

Developers Testers

58Traditionally, we give up our choices about what the project will do quite early on, well before the testers get involved! Implementation is a commitment.

Testers know how to break our code before we even get a chance to code it, but we don’t always ask them *how* they’ll break our code. We just go ahead and code, and they use their evil, evil deliberate discovery skills and “hand it back to us in tatters”, as Dan North said.

Here’s Dan’s blog post on Deliberate Discovery: http://dannorth.net/2010/08/30/introducing-deliberate-discovery/

Page 68: Bdd Liz Keogh

Traditional

Developers Testers

Deliberate Discovery skills

58Traditionally, we give up our choices about what the project will do quite early on, well before the testers get involved! Implementation is a commitment.

Testers know how to break our code before we even get a chance to code it, but we don’t always ask them *how* they’ll break our code. We just go ahead and code, and they use their evil, evil deliberate discovery skills and “hand it back to us in tatters”, as Dan North said.

Here’s Dan’s blog post on Deliberate Discovery: http://dannorth.net/2010/08/30/introducing-deliberate-discovery/

Page 69: Bdd Liz Keogh

Traditional

Rework

Developers Testers

Deliberate Discovery skills

58Traditionally, we give up our choices about what the project will do quite early on, well before the testers get involved! Implementation is a commitment.

Testers know how to break our code before we even get a chance to code it, but we don’t always ask them *how* they’ll break our code. We just go ahead and code, and they use their evil, evil deliberate discovery skills and “hand it back to us in tatters”, as Dan North said.

Here’s Dan’s blog post on Deliberate Discovery: http://dannorth.net/2010/08/30/introducing-deliberate-discovery/

Page 70: Bdd Liz Keogh

BDD

Developers Testers

59Testers are “whattabout” people. They ask, “What about this scenario? Or this one?”

They can do this while devs are thinking about the solution, and analysts are trying to help them with it. This keeps us in the problem space for a bit longer, and helps us avoid that premature commitment. Conversations aren’t very expensive.

Page 71: Bdd Liz Keogh

BDD

Developers TestersTesters

59Testers are “whattabout” people. They ask, “What about this scenario? Or this one?”

They can do this while devs are thinking about the solution, and analysts are trying to help them with it. This keeps us in the problem space for a bit longer, and helps us avoid that premature commitment. Conversations aren’t very expensive.

Page 72: Bdd Liz Keogh

BDD

Developers Testers

Deliberate Discovery skills

Testers

59Testers are “whattabout” people. They ask, “What about this scenario? Or this one?”

They can do this while devs are thinking about the solution, and analysts are trying to help them with it. This keeps us in the problem space for a bit longer, and helps us avoid that premature commitment. Conversations aren’t very expensive.

Page 73: Bdd Liz Keogh

BDD

Less Rework

Developers Testers

Deliberate Discovery skills

Testers

59Testers are “whattabout” people. They ask, “What about this scenario? Or this one?”

They can do this while devs are thinking about the solution, and analysts are trying to help them with it. This keeps us in the problem space for a bit longer, and helps us avoid that premature commitment. Conversations aren’t very expensive.

Page 74: Bdd Liz Keogh

1 2 4 5

60Here’s how evil testers are. A dev once asked me, “Why do we need testers, if we’re doing automated testing and having conversations around scenarios?” So I wrote this on a napkin. “What’s in the middle?” I asked.

Page 75: Bdd Liz Keogh

1 2 3 4 5

61“It’s a 3,” he said.

“Put your tester hat on. What’s in the middle now?”

Page 76: Bdd Liz Keogh

1 2 ? 4 5

62“I don’t know,” he said. “I mean, it might be a 3. But if I’m a tester, I’ll ask.”

“That’s why we need testers. Of course it’s a 3, but a tester thinks about what really ought to be there, and we devs just fill in the gaps.”

Then I showed it to a *real* tester.

Page 77: Bdd Liz Keogh

1 2 : 4 5

63“Might not be a 3,” the real tester said.

Evil. Evil! And very, very, valuable.

Page 78: Bdd Liz Keogh

Real Options

64For most things in life, we have choices. We can pay to extend those choices. An option is the right, but not the obligation, to have something.

Implementation is a commitment. If we implement before we’ve had a chat about something, we are probably investing in the wrong thing.

Similarly, if we do too much analysis about something when trying something out would be the right thing to do, we’re probably investing in the wrong thing.

Automation is also a commitment!

BDD, done well, helps us find the right balance between conversation and prototype.

Page 79: Bdd Liz Keogh

Real Options

Options have value.

64For most things in life, we have choices. We can pay to extend those choices. An option is the right, but not the obligation, to have something.

Implementation is a commitment. If we implement before we’ve had a chat about something, we are probably investing in the wrong thing.

Similarly, if we do too much analysis about something when trying something out would be the right thing to do, we’re probably investing in the wrong thing.

Automation is also a commitment!

BDD, done well, helps us find the right balance between conversation and prototype.

Page 80: Bdd Liz Keogh

Real Options

Options have value.

64For most things in life, we have choices. We can pay to extend those choices. An option is the right, but not the obligation, to have something.

Implementation is a commitment. If we implement before we’ve had a chat about something, we are probably investing in the wrong thing.

Similarly, if we do too much analysis about something when trying something out would be the right thing to do, we’re probably investing in the wrong thing.

Automation is also a commitment!

BDD, done well, helps us find the right balance between conversation and prototype.

Page 81: Bdd Liz Keogh

Real Options

Options have value.

Options expire.

64For most things in life, we have choices. We can pay to extend those choices. An option is the right, but not the obligation, to have something.

Implementation is a commitment. If we implement before we’ve had a chat about something, we are probably investing in the wrong thing.

Similarly, if we do too much analysis about something when trying something out would be the right thing to do, we’re probably investing in the wrong thing.

Automation is also a commitment!

BDD, done well, helps us find the right balance between conversation and prototype.

Page 82: Bdd Liz Keogh

Real Options

Options have value.

Options expire.

64For most things in life, we have choices. We can pay to extend those choices. An option is the right, but not the obligation, to have something.

Implementation is a commitment. If we implement before we’ve had a chat about something, we are probably investing in the wrong thing.

Similarly, if we do too much analysis about something when trying something out would be the right thing to do, we’re probably investing in the wrong thing.

Automation is also a commitment!

BDD, done well, helps us find the right balance between conversation and prototype.

Page 83: Bdd Liz Keogh

Real Options

Options have value.

Options expire.

Never commit earlyunless you know why.

64For most things in life, we have choices. We can pay to extend those choices. An option is the right, but not the obligation, to have something.

Implementation is a commitment. If we implement before we’ve had a chat about something, we are probably investing in the wrong thing.

Similarly, if we do too much analysis about something when trying something out would be the right thing to do, we’re probably investing in the wrong thing.

Automation is also a commitment!

BDD, done well, helps us find the right balance between conversation and prototype.

Page 84: Bdd Liz Keogh

Business Analyst

Developer Tester

65If you don’t have actual testers, get someone to play that role. Someone who *isn’t* a dev. Us devs are very good at abstraction, and will start solving a problem before we see the whole problem. I don’t believe that an awesome dev can also be an awesome tester, or vice-versa.