A friend of mine is an expert on English Literature. He explained that the post-modernists believe that each person will have a different experience when they read a book because they will have a different set of experiences that form their frame of reference. Even further, they will have a different experience every time they read the book because they will have a different context. In other words, given a context, when the reader reads a book, they will have a certain response.
This is similar to JBehave. Given a context, when an event occurs, the system should exhibit certain behaviour. If the context is changed, then the outcome may change.
It seems to me that there is a common pattern.
The idea with JBehave is to start with the story on story cards. When it comes to implement a story, the customer (business coach) should write the acceptance criteria for the story and then parse them into JBehave. This creates given, event and outcome classes. The developer then codes the behaviour expected in these classes. The context is specified using Mock objects in the givens. The call to the class being tested is written in the event class. The checking of outcomes is written in the outcomes class. For each class, a behaviour (JUnit) class is written.

As the classes are implemented, the mocks in the context are replaced with real classes until all the mocks have been removed.
JBehave is an application that converts XP Stories into JBehave behaviours. JBehave can then regenerate the XP Stories from these Jbehave behaviours. In other words, the Jbehave code is self documenting.
Lets start with a simple example XP Story from an ATM application.
Story: Request Cash
As a bank account holder
I would like to withdraw cash from an ATM
so that I do not need to visit my branch.
Acceptance Criteria: Successfully withdraw cash
Given the account is in credit [balance = 50]
When the user requests cash [request 20]
Then reduce balance [balance = balance – 20 =30]
and dispense cash [dispense 20]
and return card.
This story consists of the name, a description, and an acceptance criteria.
JBehave will use this Story to create a class called RequestCash which contains a description and a single acceptance criteria. In addition it will create Jbehave classes. A “given” class called theAccountIsInCredit which contains the comment /* balance = 50 /, an “event” class called theUserRequestsCash with the comment / request 20 /, and three “outcome” class called reduceBalance with the comment / balance = balance – 20 =30 /, dispenseCash with comment / dispense 20 */, and returnCard.
A developer then adds code into the Jbehave classes that is used to test the behaviours of the classes or component. Jbehave runs the behaviour indicating whether the it has run successfully or not.
The format for a JBehave story is as follows:
Syntax of the XP Story in JBehave
Story: <story name>
As a <role name>
I want to <function>
so that <business value>
Acceptance Criteria: <Acceptance Criteria name>
{optional}Given <context>
When <action>
Then <outcomes>
There can be any number of acceptance criteria for a story.
<context> = {optional} <full acceptance criteria name>, <givens> [<comment>] * n separated by “and”
<outcomes> = <outcome> [<comment>] * n separated by “and”
<full acceptance criteria name> = <acceptance criteria name> {optional} from <story name>
JBehave expects the story and its acceptance criteria to be specified in a particular format. The aim is to specify the behaviour of the system through the acceptance criteria.
An example:
Story: Request Cash
As a bank account holder
I would like to withdraw cash from an ATM
so that I do not need to visit my branch.
Acceptance Criteria: Successfully withdraw cash
Given successfully login from user login
and the account is in credit [balance = 50]
When the user requests cash [request 20]
Then reduce balance [balance = balance – 20 =30]
and dispense cash [dispense 20]
and return card
Acceptance Criteria: Prevent cash withdrawal when overdrawn
Given successfully login from user login
and the account is in overdrawn [balance = -50]
When the user requests cash [request 20]
Then refuse cash
and return card
Acceptance Criteria: Successfully withdraw cash when overdrawn but within overdraft limit
Given successfully login from user login
and the account is in overdrawn [balance = -50]
and the account has an overdraft limit [limit = 100]
When the user requests cash [request 20]
Then refuse cash
and return card
Dan North demonstrated JBehave Stories at XP Day. I wasn't there but they were well received.
Dan and I developed JBehave Stories a couple of months ago when we were both on the beach at ThoughtWorks. In reality, Dan did all the hard work and I bought the coffees. JBehave Stories came out of my modelling of the Behaviour Driven Development process and the use of mocks. I blogged the day Dan taught me BDD at the time.
The idea behind JBehave stories is that the Analyst writes the stories and acceptance criteria. JBehave then parses the stories and generates behaviour stubs which lead into behaviour driven development. The developer then fills out the behaviour and JBehave executes the stories in the same way that JUnit executes unit tests. JBehave also generates the stories from the code. The code literally becomes the documentation.
It is nearly ready. Dan needs to do a couple of things and it will be available on the JBehave web site.
I believe in self organising teams. Perhaps the principles applied to teams should be applied to companies. An idea I have been kicking about is that a director on the company's board should be elected by the workers. This is similar in concept to the workers representative on the board of German companies.
As I mused about the idea, I thought, perhaps all the directors of a company should be elected by the workers.
Currently most senior managers are elected by the owners of the company. The workers should have a voice too.
Tim Velvick , a friend of mine has just started Blogging. I am sat next to him as he writes his first Blogs.
Tim has lots of interesting ideas and it will be fun to see them appear over the next few weeks and months.
I have been reflecting on the time that we developed a flexible model but the users entered data in such a way that it restricted the use of the system. See here for the story.
Perhaps the problem was as much to do with the fact that we had developed an abstract model and had not explained it to the business manager in concrete terms. Urm there might be something to that.
It did not help that we had an antagonist relationship with the business manager because we were changing his model. First we should have developed a trusted relationship and then collaborated on developing the model rather than prepare it in isolation.
Alistair Cockburn is right. The Agile Manifesto is a historical document like the American Constitution and should not be changed.
Getting a few people to agree on them at snowbird was hard enough, getting the many thousands of members of the Agile community to change them would be impossible.
That said, I am interested in what additional values people think of as Agile. Sort of constitutional amendments.
Here are mine.
Self Organising Teams Over Hierarchy.
Democracy Over Autocracy.
Business Value Over Working Software.
Trusted Relationships AND Effective Communication.
I would be interested to hear if people have got other "Agile" values or what they think of mine.
I went to a practice run of the NLP Session at XP Day and XP Day Benelux last night. It was awesome.
Dan North and Marco Jansen have created a fantastic experience for people interested in learning about NLP or just learning about themseleves.
The exercises give you real insight into how you come across to other people. It makes you aware of how to achieve rapport with other people and the reflective skills to understand when you do not have rapport.
If you going to XP Day or XP Day Benelux, I heartily recommend the session.
Andy is going to kill me because it clashes with his and Rachel's session on User Stories