|
 In
this article of the series on Extreme Programming, Pradyumn Sharma
builds upon the earlier discussed practice of small releases to
explain the planning process in this development methodology
As we saw in the previous article of this series,
the Extreme Programming (XP) methodology advocates small releases,
maybe every six to eight weeks. The planning cycle of an XP project
revolves around these releases.
When you are starting work on a new project,
you have only a limited idea about the size and scope of the project.
Perhaps you do have a better idea about the likely complexity of
the system. Based on these, you only have some tentative estimate
of the effort involved, and the likely time horizon. Whatever you
know about the requirements may also not remain valid a few months
down the line.
Exploring for the release plan
At the start of the project (the first release
cycle), as well at the start of subsequent release cycles, the customer
identifies the user stories (XP term for use cases) they would like
to include in that release, based on what adds most value to their
business. They write down a brief description of the user story,
a few paragraphs usually, to provide an idea of what the system
needs to do.
The development team goes through these user
stories and makes a rough time estimate for each story. The estimate
is in terms of Ideal Engineering Time—the time one would spend
in implementing a story if that was the only task one had and there
were no interruptions.
For some stories, the developers are not in a
position to estimate. The stories are not clear, or are too big
to estimate the effort involved. They seek clarifications from the
customer, or ask for the stories to be split. Sometimes while splitting
a story, the customer may realise that only a part of the original
story is really important for the current release cycle; the other
parts can possibly be taken up in a later release.
Committing to a release plan
We now have a list of user stories that the customer
wishes to include in the next release, along with some estimates
for them. Now the customer sorts the stories based on their business
value, as (a) most critical; (b) not critical but providing significant
business value; (c) nice to have.
The developers sort the stories based on the
risk, as (a) those they can estimate precisely; (b) those they can
estimate with some confidence; (c) those they cannot estimate at
all. The development team also tells the customer how much Ideal
Engineering Time they can complete per calendar month. This ratio
is known as the velocity.
Based on all of the above, the customer chooses
which stories to include in the next release. This choice can be
made in either of the two following ways:
(a) The customer sets a target completion date
for the next release, and chooses user stories that can be accomplished
within the specified time-frame based on estimates provided by the
developers and the expected project velocity.
(b) The customer selects the user stories they
want in the next release. The likely date of completion is derived,
again, based on the estimates for each story and the expected project
velocity.
Exploring for the iteration plan
Let us say a release cycle has been estimated
to take two months. We would now break it down to small iterations
of one to three weeks. Two weeks is a good average, and a reasonable
time-frame for individual iterations.
At the start of each iteration, an exercise similar
to the one described above is repeated, albeit on a more micro level,
and with greater detail. The customer chooses a set of stories from
the current release plan to include in the new iteration. At the
end of each iteration, including the first one, the system must
run from end to end, even if without doing much real work.
The developers break down a story selected for
the current iteration into smaller tasks, usually in durations of
one to three days. If a task is bigger than three days, it should
be broken down into smaller tasks. A small story may have only one
task. A bigger story may have a couple of reasonably independent
and clearly distinguishable tasks. Some tasks may support more than
one story.
Other considerations for an iteration plan
An iteration plan not only considers new stories,
it may also involve adding further functionality to a story already
(partially) implemented. In addition, the following also have an
impact on the planning for an interation:
- Some user story selected for the earlier iteration
may have failed acceptance tests. The developers have to include
it in the new iteration plan.
- Developers may realise, based on results of
the earlier iterations, that they have overestimated the velocity
(ideal engineering time per calendar month). As a result, there
may be a realisation that the release plan is likely to fail.
They then request the customer to defer some of the user stories
to the next release, retaining the ones that are most valuable
to the customer.
- Sometimes, developers may realise that the
actual pace and progress is significantly different from the plan
for the release, they may negotiate with the customer to re-estimate
all the remaining stories for the release and set velocity again.
Committing to an iteration plan
As tasks are being identified for the new iteration,
different programmers individually take up the responsibility for
various tasks. With more information available for the user stories,
and therefore the tasks, the programmers make more confident estimates
for these tasks, again in ideal engineering days. These estimates
may at times be subject to the condition of getting help from another
programmer who may be more familiar with the code to be modified,
or with more experience with similar tasks in the past.
Programmers would not be writing code all the
time. They would also be helping other programmers by pairing up
with them, or coaching others, and so on. The percentage of time
a programmer spends in actual programming in an iteration is called
the load factor.
Programmers choose their own load factor, normally
estimating it is based on the average time spent by them in the
preceding few iterations. A very high load factor is frowned upon,
as it means that the concerned programmer would not be helping others.
A low load factor is quite common for new members of the team and
for the coaches.
Each programmer then adds up their estimates
for the tasks and multiplies it by their load factor. If a programmer
is overcommitted, they shed some of their tasks. Other programmers
who may be under-committed may pick up some of them. If the entire
team is overcommitted, then they have to drop or postpone some less
essential tasks, or request the customer to either reduce the scope
of some of the stories, or even defer some stories to the next iteration.
(Discussion on the planning game practice of
XP to be continued and completed in the next article of the series).
Pradyumn Sharma is the CEO of Pragati Software.
He is a trainer and consultant in the areas of Object-Oriented Analysis
and Design, Design Patterns, and Extreme Programming. E-mail: pradyumn.sharma@pragatisoftware.com
|
