Extreme Programming for the Customer, Programmer, Manager: What's a Typical Day
This chapter is from the book
This chapter is from the book
This chapter is from the book
Customer: Questions, tests, and steering
Programmer: Testing, coding, and refactoring
Manager: Project manager, tracker, and coach
Assume we've been through release planning and iteration planning. What happens in a typical day during an iteration?
Customer
As a customer of Extreme Programming (XP) software, you will sit with the team full-time to 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 in the marketing group said he thought the experience was great, because he was answering questions right when they came up and he could see the progress resulting from his answers. He admitted that when he was back in his office, he'd get a voicemail, but 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" (Peters, 1999, 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).
The customer has four key jobs during the iteration:
- Answer questions
- Write acceptance tests
- Run acceptance tests
- Steer the iteration
and one job (after several iterations) when the release is ready:
- Accept the release
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 asked a question, answer right away if you can 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. For example, if you've said you want some data cleaned up, the programmers may present you with options, but you have to tell them which one you want.
Once you've answered a question, you'll want to keep track of your answer. The best way to do this is to write an acceptance test or (more rarely) write a story.
Write Acceptance Tests
For each story in the iteration, determine what would make you 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 will want to spend some story or task points to get a tool to run these tests automatically. Also, you may have a programmer or tester who will help: you specify the test, and the programmer or tester will implement it. Be aware that if you require a programmer to work on the tests, this will affect the number of story points the person can deliver.
Software testing is a discipline unto itself; a good starting point would be Kaner et al. (1999) or Beizer (1995).
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 to 9999, 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 a chain reaction with too many problems to examine. If tests are 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 expected to be implemented by the end of the iteration. Let the team know which tests pass and which fail. The manager (tracker) will keep a graph where everybody can see it. After you run these tests by hand for a few days, you'll see why you will prefer automated tests.
By the end of the iteration, you want 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 release date.
Iteration planning: You choose what stories are in each iteration.
On the fly (within the iteration): You choose what the team does right now.
There will be times when you need to adjust the plan. Perhaps the development team is not progressing as quickly as planned, and they need to drop some features for the iteration. Given the team's progress, you are best able to decide which story is more crucial or whether a story can be meaningfully split.
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 reprioritize 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. Do a new release plan whenever you need to.
Accept the Release
As you get closer to release time, 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.
A release is a big deal; celebrate with the team, then relax and explore a little before jumping in to the next release.
Q&A
But I've got a job to do. How can I spend all my time with this team? Well, hopefully it won't have to be all your time. You'll probably be able to do a little work other than this, but this is definitely an investment. Fortunately or not, an on-site customer is the best person to guide an XP team, by deciding what to do, setting priorities, and answering questions.
Can't I just talk to analysts and let them translate what I want? XP has no analyst role per se; the customer works directly with the programmers. XP strives for the high-bandwidth communication of having the person with the problem talk directly to someone who might be able to solve it.
What if there are many customers? The development process needs input that is prioritized into a single stream of requests. The potential customers need to find a way to trade off their particular requirements.
What if there are many, many customers? "Customer" is a role; there may be product managers or marketing people who can stand up and make the necessary business decisions.