|
 Continuing
the series on Extreme Programming (XP), PRADYUMN SHARMA discusses
the planning process of this methodology and shows how it helps
achieve results
In the previous article, we had discussed some
aspects of ‘The planning game’, an important practice
of Extreme Program-ming (XP). To summarise the points from the previous
article before we discuss this practice further:
- At the start of each release, a release plan
is made, based on the selection of user stories by the customer.
The key factor in making this selection by the customer is the
value that each user story would add to them.
- Within an iteration, at the start of each
iteration (typically of one/two/ three weeks duration), user stories
from the current release plan are broken down to smaller tasks
of a few days duration, and developers commit to the individual
tasks. Also included in an iteration plan are any incomplete user
stories from the previous iteration.
 Executing
the iteration plan
As an iteration gets underway, programmers start
implementing the programming tasks they have committed for. They
seek partners to pair with them, write test cases for their tasks,
write the code for implementing the tasks, and integrate their code
with the rest of the system.
The onsite customer is available to the team
for providing clarifications from time to time as the team members
proceed with their implementation. The customer also writes acceptance
tests for user stories taken up for the current iteration. As soon
as a programming task is reported to have been completed by a programmer,
the acceptance tests are run to verify that it works as required.
The daily huddle
You start every day with a small, 15-minute meeting
of the entire team, including the onsite customer. This meeting
is not held in a round-table conference room, but is a stand-up
meeting, preferably held around the coffee vending machine. The
stand-up nature of the meeting ensures that it does not linger on
unnecessarily.
I like to call this a daily huddle, as it is
more like the famous ritual of the Indian cricket team, before the
start of every innings of the opponent, or after the fall of every
wicket.
 In
this meeting, there is a quick review of the project status and
of current programming tasks on hand. Everybody updates everybody
else on the progress made. Small achie-vements of the previous day’s
work are celebrated, ideas are thrown around and shared, and plans
for the day are made, pair partners are sought. If there are problems
or roadblocks, slippages, disappointments, they are also discussed
and corrective actions are chalked out.The customer is also a part
of this meeting. This gives the customer a good idea of the progress
(or lack of it), the issues being faced, the likely completion status,
etc. The customer may also be able to provide some suggestions about
changes in priorities, alternative approaches that may work, etc.
Involvement of the customer
As can be seen from the above discussion, there
is a significant involvement of the customer in the planning process,
along with the developers. It is, in fact, a mutual, consultative
approach of planning where the customer and the developers both
play equally important roles.
The customer chooses the scope based on the value
added by user stories, and decides the priorities. The customer
also decides about the dates of releases and the composition of
these releases. But these are not arbitrary, unilateral decisions.
Developers make estimates for all user stories
and smaller programming tasks. These estimates are not forced from
the top by someone. Detailed scheduling within a release is also
decided by the developers, with the view of tackling the greatest
risks at the earliest instance. Of course, it calls for an open,
mature and honest team to make reasonable estimates, and not pad
them up with buffers.
 Developers
also make the technical decisions and evaluate their consequences.
Even the fine-tuning of the entire process is done by them.
Metrics
You need to measure things to see how they stack
up against plans. XP projects have their share of metrics for this
purpose, although the emphasis, expectedly, is on keeping them small
in number and simple to use.
For example, the velocity (ratio of estimated
development time to calendar time) is estimated in the planning
process. But what is the actual velocity achieved by the team? So,
somebody collects the data for maintaining this metric and plots
it on a chart where every team member can see it.
There is no prescribed set of metrics. Have a
few metrics, based on what are the main problems that the team is
facing or the areas where improvements are sought. If you find that
enough tests are not being written, devise a metric for measuring
the adequacy of tests, and update it regularly.
Once the problem area has been brought under
control, discard the metric and move on to some other problem.
The benefits
The benefits of the XP approach of planning are
many:
- It truly empowers the developers, enabling
them to make all the technical decisions and effort estimates.
This makes them motivated and excited about the project.
- Customers are involved in the entire planning
process, thereby making them better aware of the progress being
made as well as the problems being faced.
- Small releases and small planning cycles give
the entire team a more realistic picture of project and its planned
activities. You cannot anticipate or plan what you would be doing
four months later, but you can better predict and control what
you would be doing ten days from now.
Pradyumn Sharma is the CEO of Pragati Software.
He is a trainer and consultant in the areas of Object-Oriented Analysis,
Design, Design Patterns and Extreme Progra-mming. E-mail: pradyumn.
sharma@pragatisoftware.com
|
