Contracts in XP (Release Plan Optimism)
Cardinality is very important, i.e. the concept
that there are only 3 important values: 0, 1, and more
The difference between no server, 1 server, and many
servers is huge, and needs to be decided early. Similarly
for other things.
Customer has 1 address? Many addresses? Can they have
It affects the database, the code, and the UI. Decide
XP is aimed at customers who don't know what
The previous sentence isn't intentionally provocative. The point
about XP is that it's an agile methodology. If the customers knew
exactly what they wanted, then they wouldn't need a process that
focusses on changing the requirements at any stage, or a process which requires putting a huge amount of effort into keeping the product "releasable" at any point, whether it's due for release or not (just in case the customer suddenly decides to cancel development).
If the project is not ailed by vague and "dynamic" (read:
fickle) requirements, then XP is probably the wrong process to use.
In other words, if the problem domain is well understood, and the
requirements are not likely to change, then you should choose a
process that places less emphasis on the ability to "chop and
change" at any stage.
Conversely, if the requirements are vague or likely to change in
the course of the project, it could be argued that XP still isn't
the best process to use. There are processes that are much better
suited to handling change halfway through a project - providing
requirements traceability and impact analysis (including support
for quickly providing cost estimates so that the customer can make
an informed decision about whether to authorise any changes).
To really get a feel for the impact of any change, you need an
architecture (not a heavyweight document, but a high-level overview of your design and system topology). This gives you a roadmap with which you can easily
trace out the overall impact of any potential change: "If
I change this component, it will affect these other four components
that use it. Plus it means that component X, which hasn't been written
yet, may take a little longer than was originally estimated. But
it covers component Y, which now won't be needed at all..."
With XP, your design only covers what has been written so far.
Thus, it is very difficult to look ahead and plan future components.
The extremeprogramming.org website claims:
"In many software environments dynamically
changing requirements is the only constant. This is when XP will
succeed while other methodologies do not."
The problem with this approach is that it is very reactive, treating
the symptom instead of the illness. They should be educating the
customer, attempting to address the reason why the requirements
are changing so much.
For example, the customer might simply be unsure about exactly
what their business requires. This is where you come in, as a business
consultant: you should be presenting the customer with use cases,
mock screenshots, prototypes (using quickly knocked-together, throwaway
code). This all helps the customer to visualise what they really
want, helping them to pin down the requirements before a single
line of production code is written.
In XP however, the approach is to defer the hard questions until the last possible moment, and to change the design if needed. XPers believe that development is "frictionless", i.e.
change at no cost, no heat, no inertia. However, there is always
a cost associated with change.
Of course that doesn't mean that the project requirements cannot
change once they have been "signed off" by the customer. These sort
of changes should be minimal though, as (taking a non-XP approach) all the really hard thinking
would have been done up front, and all the hard questions would have been asked (and answered). The problem domains have been identified;
the nastiest problems carefully thought through and resolved.
The trouble with encouraging
frequent changes is that it leads to the "just a little bit better"
syndrome (even at a subconscious level). In other words, the developers
get very excited about an idea they (or the in-house customer) have
had, and in chatting about it they become even more excited. In
it goes. But the real customer (that reticent, cigar-chewing man
back at Customer Towers) might not be quite so appreciative of this shiny new feature.
What XP Values the Most
Software Reality XP Forum
<< Back to XP Central
<< Back to the Front Page