XPlorations
| XP123 → XPlorations → Customer in XP (June 2000) |
| How to Be a Customer of XP Software | June, 2000 |
Extreme Programming ("XP") is a fairly new
software development methodology. We discuss these three aspects:
|
XP is a Different Approach
Extreme Programming ("XP") is a fairly new software development method. It brings together a number of practices that help a team perform at maximum speed.First, let's consider a traditional approach:
| The user's group arranges with the development group to have an analyst assigned for a project. Over a series of weeks and months, the analyst meets with the users for several hours a week. The analysts produce a set of documents, perhaps including things like a Vision Statement or Use Cases. The users (and perhaps the programming team as well) review these documents and negotiate a release. The programmers take this information, and several months later produce a system that more or less does what it was intended to. It's often a close call at the end, as people find out what they missed, and realize what's changed since the documents were written. In the end, the customers come in to do a user acceptance test, and the system is released. Often the whole process took longer than anybody had expected, and the quality is not where the users want it. |
By contrast, the XP approach emphasizes testing and customer involvement:
The Customer contacts an XP development group to start a
project. An XP team insists that the Customer sit with their team
the whole time they're developing. An XP project typically has
three phases:
|
Extreme Programming believes that there is a fundamental split in
the roles of Customer vs. Programmer. The Customer owns "what you
get" while the Programmer owns "what it costs". This shows up in
who gets to make which decisions. The Customer gets to decide:
[summarized from Extreme Programming Explained, p. 55]
Scope - what the system must do
Priority - what's more important
Composition of Releases - what must be in a
release to be useful
Dates of Releases - when is the release
needed.
The Programmers get to decide: [ibid.]
Estimated time to add a feature
Technical consequences - Programmers explain the
technical consequences of choices, but the Customer makes the
decision
Process - how the team will work
Detailed Scheduled - within an iteration
The practices of XP help enforce this split. This division of responsibilities helps keep the whole team on track, by making the consequences of decisions be very visible. For example, if a Customer wants a report this week, the XP team is happy to provide it. They'll outline any technical risk, and estimate what it will cost. Then the Customer gets to pick what will be dropped to make time for the development.
What happens if there's a conflict? What if the Customer wants
these features by this date, and the Programmers estimate that it
will take longer than that? XP provides several options: the
Customer can accept less scope, the Customer can accept a later
date, the Customer may spend time or money exploring an
alternative, or the Customer can find a different programming team.
What XP doesn't let you do is say, "Let's try anyway - we'll catch
up later."
XP Practices
Extreme Programming has a number of key practices. In Extreme Programming Explained, Kent Beck identifies these:
|
|
|
Roughly half of these involve the Customer's role. We'll look at these practices in particular:
On-Site Customer
In XP, the customer will sit with the team full-time. They'll write tests, answer questions, and set priorities. Having the customer with the team is crucial in helping the team go as fast as possible.I once worked with a cross-functional team that had moved into one large room for a key project. In the "lessons learned" session, a manager of the marketing group said he thought the experience was great, that he was answering questions right when they came up and he could see the progress. He admitted that when he was back in his office, he'd get a voicemail, and he'd put off answering for a day or two. (Meanwhile, the developers either made a guess, or worked on something less important.)
It takes many decisions to develop software. If a team can get its answers or decisions in minutes instead of hours or days, its speed will be much higher.
XP is not the only approach that recognizes the value of an
on-site customer. Tom Peters says: "Make clients an integral part
of every project team." [The Professional Service Firm 50,
p. 105] and "If the client won't give you full-time, top-flight
members, beg off the project. The client isn't serious." [ibid., p.
106].
Planning Game
XP uses the notion of a planning game for planning the release (weeks to months) and for planning iterations (1 to 3 weeks). The planning game uses two players, and defines which type player can make which move. In this way, the process maintains a critical division of labor: Customer determines value, Programmer determines cost.In the release planning game, the goal is to define the set of features required for the next release. It is centered around user stories. The Customer writes them, the Programmers estimate them, and the Customer plans the overall release. The iteration planning game is similar. The Customer chooses the stories for the iteration, and the Programmers estimate and accept the corresponding tasks.
Both games help make development tradeoffs explicit. If the
Customer wants more stories, it takes more time. If they want the
stories sooner, they have to give up scope. The games help clarify
roles: Customers aren't permitted to make estimates, and
Programmers aren't permitted to choose which features come
first.
Testing
XP uses testing two ways: Customers develop acceptance tests that determine the overall behavior of the system, and Programmers create unit tests while programming.As a Customer, you'll create tests for each story you request. You'll measure the progress in developing the system by running these tests. The Manager who is tracking development may maintain a graph showing how well the system is doing over time. For example:
Having to write your own tests is a challenging experience. An XP team might have a Tester or Programmer who will work with you (you specify - they implement), but you own the tests.
In many development approaches, the customer is expected to help specify the requirements, and one of the attributes of a good requirement is that it is testable. XP moves this testing toward the front of the development process. You may find that when you write a story, you're challenged to explain what the test will be like. This is healthy - it means the Programmers want to do what you want.
During development, Programmers will come to you with questions, which are either to get information they need, or to get you to make a decision. When you provide an answer, find a way to make a test that will tell you whether they've followed your answer.
Finally, you should strive to have your tests automated. This
may mean spending some task development points, but you'll find
it's worthwhile. You don't need a fancy screen - just a way to
specify the inputs and the expected result. Some teams have been
able to use spreadsheets for this: the user has a familiar
interface, and the Programmers can read the spreadsheet with a
small program to run the test.
Metaphor
The metaphor in XP is a conceptual framework for talking about your solution. You and the Programmers will seek a metaphor that will give you a shared vocabulary and a mental picture of the system. If you don't find one, you'll use the "naive metaphor", using the vocabulary of your problem domain.Small Releases
XP specifies that releases should be as small as possible. An XP team is trying to learn, and the more feedback they get (especially from actual use), the better. Although the release should be small, it needs to make sense: only "whole" features should be included.Projects that don't release for months and months, or even
years, accumulate a lot of risk - technology will change, the
business environment will change, the team will change. Targeting
small releases reduces this risk.
40-Hour Week
Finally, XP teams maintain a 40-hour week. Too many teams have taken the short-term expedient of requiring lots of overtime, only to pay for it in increased bug rates, increased turnover, and increased overall cost. An XP version of the rule for 40-hour weeks is "Don't work two weeks of overtime in a row." Occasionally, a little extra time might be important. But if it's needed week after week, it indicates a systemic problem.Be sensitive to this rule. Expect pushback when you want
something "right now": expect the answer "what do you want to give
up to get it?" Keeping your team well-rested will pay itself back
many times over the project's life.
Customer Activities on an XP Team
We'll talk in more detail about the activities in the three phases:Exploration:
Release Planning
Game
Write a Story
Split the Story
Iteration:
Iteration
Planning Game
Answer
Questions
Write Acceptance
Tests
Run Acceptance
Tests
Steer the
Iteration
Release:
Accept the
Release
Celebrate the
Release
Exploration
Release Planning GameDuring the exploration phase (typically 1 to 4 weeks), the team works together to play the release planning game. This game embeds the rights of Customers and Programmers into the rules. You can think of the game as looking like this:
Customers Write a Story. The Programmers try to estimate it. If it's too big, they pass it back to the Customer to Split the Story. If the Programmers don't know how to implement it, they do an investigation called a spike. If the Programmers think the story will take 1 to 3 story points ("weeks") of work, they pass it to the customer to sort. (Story points don't correspond exactly to real weeks: the Manager will let you know how many story points to expect the team to accomplish per iteration.)
To sort the stories, the Customer arranges them in order of importance (most important first). To indicate what will be in the release, the Customer will clip the back cards together: everything before the clip is planned to be in the release. For best results, make the release as soon as possible.
The unclipped stories tell you the due date as well: knowing the total story points and the number of story points per iteration will tell you how many iterations. If you're trying to hit a particular date, you may need to include fewer stories; if you're trying for a particular set of stories, you'll have to be flexible on the date.
If you don't like what you're getting, you have a few options:
change the stories, accept a new date, change the team, or work
with a different team entirely.
Write a Story
To write a story, take a blank file card and write "Story: story
title" on the top. Add a short paragraph describing some feature of
the system. (Try to keep it small enough that the Programmers will
estimate 1 to 3 story points.) Give the card to the Programmers to
estimate.
If you need to, cite or attach supporting materials. A story card doesn't need all the details though - it's as much a promise to discuss a feature as a description of it.
Remember that the story must be testable. And since you're the
one specifying the tests (later on), this means you have to
know how to test it.
Split the Story
You may want to split a story for more flexibility, or because the
Programmers say it is too big for them to estimate. (If the
Programmers want it split, you have to split it, even if it doesn't
sound that bad to you. Smaller stories tend to be less risky, so
it's worth the trouble.)
Take the original story card. Write two or more new story cards,
each simpler than the original, that when taken together cover the
original story. Rip up and throw away the original card. Give the
new stories to the Programmers to estimate.
Iteration Phase
Iteration Planning GameOn the first day of each iteration, the team will decide which stories to focus on.
The team accomplished some number of story points in the previous iteration. (For the first iteration, assume 1/3 story point per programmer per week.) Select as many story cards as you'd like, provided they add up to that many story points or fewer. The stories don't have to be in the order they were in the release plan; you can request them in whatever order you like. In fact, you can introduce new stories if you're willing to give the team time to estimate them.
In the first phase of the game, read each story card, and work with the team to brainstorm the tasks it might involve. At the end of this phase, the Programmers will have a pile of task cards, corresponding to the story cards you selected. (A given task may support many stories.)
The second phase is mostly the Programmers' job. They will select the tasks, estimate them, and accept the ones they will perform. In addition to conversations to clarify what you need, you may be involved in this phase for two reasons:
- If they can't fit in all the tasks, they'll ask you to defer or split a story.
- If they have more time than tasks, they may ask you add in another story.
Answer Questions
One of the main reasons you're an on-site customer is so you can
answer questions for the Programmers while they're implementing
tasks.
When they ask, either answer or promise to find out (and do so quickly). This feedback cycle of minutes instead of hours or days is one of the key things that lets an XP team move quickly.
Many questions are not questions of fact: they require you to make a decision. Your decisions are important: they're how you get what you need.
Once you've answered a question, you'll want to keep track of
your answer. The best way to do this is to Write Acceptance Tests or (more rarely)
Write a Story.
Write Acceptance
Tests
For each story in the iteration, determine what you would need to
know to be confident that the story was properly implemented, and
write a test to verify it. Progress in the iteration will be
measured against the tests, so the sooner they're available, the
better.
In the simplest form, a test will be a card with the title: "Test: test-title FOR story-title", containing information about the test. In a better case, you may be able to specify the test in a spreadsheet; you may want to spend some story or task points to get a tool to run these tests automatically. Alternatively, you may have a Programmer or Tester who will help - you specify the test, and they'll implement it.
When you're designing tests, think about the input and the expected result. (You need to capture both.) Test both what should happen when things are right, and what should happen when they go wrong. For example, a word processor test might specify what happens when the disk is full. It can also be revealing to have tests that are at a boundary condition and on either side of it. For example, if you're allowing numbers 1-99999, try 0, 1, 2, 9998, 9999, and 10000 as test values. (There's certainly a lot more to testing than this brief introduction.)
Try to keep your tests fairly independent of each other: when one test breaks, you don't want too many problems to look at. If they're independent, you can run them in any order, without a lot of setup.
Acceptance tests are crucial: they're your "gauge" so you can
measure how good the program is.
Run Acceptance Tests
Every day, run the acceptance tests for all stories to be completed
by the end of this iteration. Let the team know which tests pass
and which fail. The Manager will keep a Big Visible Chart
(described earlier). After you run these tests by hand a few days,
you'll see why you might prefer automated tests.
By the end of the iteration, you'd like all tests to pass,
although it won't necessarily be so.
Steer the Iteration
You have three key opportunities to guide the team:
- Release planning: you choose what's in, what's out, and the date.
- Iteration planning: you choose what stories are in this iteration.
- On the fly (within the release): you choose what the team does right now.
Or, there may be a change in business conditions. Perhaps
marketing has identified a killer feature that would enable sales
to book many orders if only it were available by the show date. In
this case, you can introduce the new story, get it estimated, and
re-prioritize the team's activities. You prefer not to interrupt an
iteration in progress if you can avoid it, but if you ask, the team
will set aside - or throw away - what they've done, and devote
themselves to the new features.
Release Phase
Accept the ReleaseAs you get closer to the end of the release, the Programmers will be handling the final tasks of installing the software. Once they're ready, you'll want to run the acceptance tests one last time, along with whatever else you need to be sure the software is ready to go live.
When the software is in, and you're satisfied, take a deep breath and declare, "We accept the release." Notify anybody who needs to know.
Celebrate the
Release
You've hit a major milestone: releasing the software. The Manager
will arrange an appropriate celebration, inviting all who helped
create this success.
Relax and explore a little before jumping in to the next
release.
Conclusion
We've explored several aspects of the role of the Customer in Extreme Programming.First, we considered the things that make XP a different approach, including the presence of an on-site customer, and the way Customers define value while Programmers define cost.
Next, we looked at several of XP's practices, and how the Customer is involved in them: On-Site Customer, Planning Game, Testing, Metaphor, Small Releases, and 40-Hour Week.
Finally, we considered the phases of an XP project, and the
activities of the Customer in
those phases.
Exploration: Release Planning Game, Write a Story, Split
the Story.
Iteration: Iteration Planning Game, Answer Questions, Write Acceptance Tests, Run Acceptance Tests, Steer the Iteration.
Release: Accept the
Release, Celebrate the
Release.
I hope this introduction has encouraged you to explore Extreme Programming more deeply. The key starting point would be Kent Beck's Extreme Programming Explained. Another book out now is Extreme Programming Installed by Jeffries et al. Finally, there are two online places to get information (although they tend to be populated more by Programmers than Customers): http://c2.com/wiki?ExtremeProgrammingRoadmap and http://www.egroups.com/group/extremeprogramming.
Resources and Related Articles
- Extreme Programming Explored, by Bill Wake. This article is the basis for chapter 9.
- Extreme Programming Explained: Embrace Change, Kent Beck.
[Written 6-10-2000.]