Page 299 -

But the most important drawback to XP is that the customer must always be available.
There are many environments in which this is a very difficult requirement to meet. The
users and stakeholders in most organizations have their own jobs to do, and it would be
unreasonable to require that they devote all of their working time to a software project.
Requirements elicitation (see Chapter 6) requires specialized skills and people, which
often makes it difficult to implement in small organizations, but it is much less demanding
of the time of people outside of the engineering team. And once the requirements are
written, they can be reviewed for defects. While it’s generally not possible to catch every
defect before the programming begins, it is possible to find many of them—and it is much
faster to fix defects on paper than it is to fix them in software, especially when they are
not caught until late in the project.
XP proponents often say that face-to-face communication is superior to written communi-
cation, and that XP’s reliance on face-to-face meetings and very little documentation frees
the process from the “bureaucracy” of requirements documentation. However, reliance on
face-to-face communication for detailed requirements introduces its own problems. Defin-
ing the behavior of software is a particularly complex and error-prone process. It is very
easy for people to reach misunderstandings when talking about software behavior. This is
especially risky when a customer has been involved as a project team member since the
beginning of the project. The customer’s expectations will often evolve along with the
project, as a side effect of the influence of the rest of the programming team. The result is
that the customer is more likely to accept the software, even if it does not fully meet the
needs of the people in the customer’s organization who were not on the project team. This
sort of tunnel vision is much easier to avoid when the customer keeps his eye on his task
and his organization’s needs rather than on the details of the project and the developers.
Drawbacks aside, for projects in which the circumstances and team are compatible with
XP, it is a very powerful tool. Many project teams across the world have made a huge dif-
ference in their projects by adopting some or all of the XP practices.

NOTE
Additional information about Extreme Programming can be found in
Extreme Programming Explained: Embrace Change (2nd Edition) by Kent

Beck (Addison Wesley, 2004).

Rational Unified Process
There are many complete software processes that are available and ready to be adopted out
of the box. Typically, such a process will include a complete set of activities to be performed
over the course of the entire software project. These activities usually include scope defini-
tion, requirements engineering, architecture, design, programming, and testing activities.
One of the most popular off-the-shelf processes is the Rational Unified Process (RUP).

PROCESS IMPROVEMENT 291