author: Ronald E. Jeffries
In Extreme Programming Installed, we describe the four elements of the XP “Circle of Life”: the on-site customer, working with the programmers, uses the planning game to select user stories to make up the most valuable small releases. Critical to this cycle are the user stories.
User stories have three critical aspects. We can call these Card, Conversation, and Confirmation.
Card
User stories are written on cards. The card does not contain all the information that makes up the requirement. Instead, the card has just enough text to identify the requirement, and to remind everyone what the story is. The card is a token representing the requirement. It’s used in planning. Notes are written on it, reflecting priority and cost. It’s often handed to the programmers when the story is scheduled to be implemented, and given back to the customer when the story is complete.
Conversation
The requirement itself is communicated from customer to programmers through conversation: an exchange of thoughts, opinions, and feelings. This conversation takes place over time, particularly when the story is estimated (usually during release planning), and again at the iteration planning meeting when the story is scheduled for implementation. The conversation is largely verbal, but can be supplemented with documents. The best supplements are examples; the best examples are executable, We call these examples confirmation.
Confirmation
No matter how much discussion or how much documentation we produce, we can’t be as certain as we need to be about what is to be done. The third C in the user story’s key aspects adds confirmation that we sorely need. This component is the acceptance test.
At the beginning of the iteration, the customer communicates to the programmers what she wants, by telling them how she will confirm that they’ve done what is needed. She defines the acceptance tests that will be used to show that the story has been implemented correctly.
Teams who are not yet very experienced with these ideas often want to try use cases, spreadsheets showing calculations, sketches of proposed window layouts, even multi-page documents looking much like conventional specifications. These may be useful in rare cases, but looking back over the years I have almost never found this kind of document to be ideal. Even for quite complex situations, confirmation using examples, preferably automated, works better. You may find some paper or computerized details to be valuable, but in my experience, they are more likely to slow you down. I’d suggest starting with card, conversation, confirmation, and adding in other documents only if they are clearly needed.
The programmers implement the story, and they also implement the acceptance tests. (Some teams build tools that let the customer enter the tests herself, and other teams have QA people or testers who help with the job. But one one way or another, the acceptance tests get done.
At the end of the iteration, when the story is done, the programmers show the customer that the story is done, confirming success by showing that the acceptance tests run correctly.
The confirmation provided by the acceptance test is what makes possible the simple approach of card and conversation. When the conversation about a card gets down to the details of the acceptance test, the customer and programmer settle the final details of what needs to be done. When the iteration ends and the programmers demonstrate the acceptance tests running, the customer learns that the team can, and will, deliver what’s needed. The confirmation, in terms of acceptance tests, is what keeps the Circle of Life turning. And the Circle of Life … that’s what keeps your project alive.
コメント