|
 In
this part of the series on Extreme Programming, Pradyumn Sharma
discusses the need for greater involvement from a customer in a
software project for mutual benefit
One of the main strengths of agile software development
methodologies such as Extreme Programming (XP) is that they work
well with changing requirements. More formal development methodologies
work well only if the requirements are very clearly defined in the
beginning.
If the requirements for a software project are
documented unambiguously and with great clarity and in sufficient
detail, and everybody in the development team can understand such
documents without any help, and the requirements are never going
to change, great. You then, perhaps, do not even need to bother
about reading about this fourth practice of Extreme Programming
that I am going to discuss here.
But we know that in most of the projects, the
requirements do change. In fact, in many a project, at the start,
the customer is not in a position to state all the requirements.
Customers do have some idea (often a fairly good idea) of what they
require, but as development proceeds, they also start getting more
clarity about what will be useful to them.
Religious devotion to gather all requirements
and document them in a water-tight manner may mean that the development
does not begin till very late. That, in turn, means that the customer
does not start seeing any value for a very long time.
Even when requirements are well-defined and documented
in detail, most of the time they still change. The competitive pressure
may sometimes require new features being added. Or the planned features
may become irrelevant in the changed business conditions. New statutory
requirements may have their own demands on the functionality of
a system. As technology advances, customers expectations also escalate.
As a result, you may be merrily proceeding with
coding, but an increasing proportion of the code you write may already
have become useless or invalid for the customer. The more volatile
the customer’s requirements, the greater the risk that the
business problem that you embarked on solving six months ago has
already changed significantly, if not beyond recognition.
Even with documented and stationery requirements,
you often need lots of clarifications for small unusual circumstances
that come to your mind in the middle of implementing some functionality.
Not every doubt that may enter a developer’s mind later may
have been anticipated and addressed by the original requirements
document.
Of course, even greater risks may sometimes be
existing, which we may be completely oblivious to, such as grossly
misunderstood requirements, or an overdose of features that excite
our creativity but fail to excite the customer.
What can we do to avoid wasting the time in writing
code that does not fulfill the customer’s requirements or
does not add value to the customer?
Well, there is no magic formula. No single recipe
that can address the problems associated with volatile requirements.
But the XP practice of onsite customer can make a significant difference.
XP considers the customer to be an important
and integral part of the development team. This is not a printing
mistake, a part of the development team, no less. XP advocates that
one real customer person should be available to the development
team throughout the development stage.
What does the customer do with the development
team? At the start of a project, he (or she) provides an overview
of the user stories (XP term for use cases) anticipated in the system,
based on which the development team may make some rough, tentative
estimates of the time required for individual user stories. These
estimates are expected to be inaccurate because the user stories
have not been elaborated upon.
The customer’s representative chooses the
user stories that should go in the first release. Business objectives
are the main consideration for such prioritisation. The customer
then writes the user stories, describing them in greater detail
than earlier, so that the developers can make more accurate time
estimates and get down to work. There are no frozen specifications
at the beginning, they continue to evolve in this manner, driven
by changing business priorities and requirements, and the release
plans.
As the development proceeds, the programmers
will need more clarifications about finer aspects and special cases.
The customer person is there all the time to provide such inputs.
The customer also writes acceptance tests for
user stories (assisted by the developers if required), runs them
and confirms the results. He also participates in iteration planning
and even the daily review of the progress made by the team, helping
make course corrections whenever required.
Is it economically justifiable for the customer
to spare one real person for the development team for a long period?
It normally should be. The business must be getting more value from
the software than the cost or opportunity loss due to one person,
else why would they need the system in the first place.
In practice, I doubt if most projects by even
the die-hard XP followers really get a customer person with the
development team. But I have no doubt that wherever it can happen,
there will be immense benefits to both the customer and the development
team, such as:
- Priorities can be adjusted in real-time by
the customer, based on changing business scenario, or changing
assessment of business value offered by various functionalities.
- In the face of unclear or changing requirements,
commencement of work need not wait till the requirements are frozen,
as that may never happen.
- Customer is always available to help make
course correction as clarity emerges about the details of user
stories, and consequently about the time estimates for their implementation.
Customer participation in the planning and review
meetings gives them a better appreciation of the development process
and its problems, and a better idea about the progress being made.
Pradyumn Sharma is the CEO of Pragati Software,
Mumbai. He is a trainer and consultant in the areas of object-oriented
analysis and design, design patterns, and XP. E-mail: pradyumn.sharma@pragatisoftware.com
|
