More on the AGILE Approach to Software Devt
BA Forum Moderator
articulated or modeled by means of 'stories' or 'user stories'.
========================
Extreme Programming for the Customer, Programmer, Manager: What's a
Typical Day
By William C. Wake.
Sample Chapter is provided courtesy of Addison Wesley.
Date: Mar 22, 2002.
In this chapter from his book, Extreme Programming Explored, William
Wake gives a practical, you-are-there glimpse into what happens in a
typical day during an XP iteration from the perspective of customer,
programmer, and manager.
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.
==============================================
read more of the chapter in:
http://www.awprofessional.com/articles/article.asp?p=26068&seqNum=3