Page 297 -

approach, adopting a specific process requires revolutionary, rather than evolutionary or
incremental, changes. It is usually much harder to convince people to adopt an entire new
process rather than one specific tool or technique. It also requires determined management
support to gain acceptance, because it requires a complete change to the entire lifecycle.

Extreme Programming
Extreme Programming (or XP) was developed in the 1990s by Kent Beck when he was
working on a project at Chrysler (although its roots stretch back to SmallTalk projects that
he and Ward Cunningham worked on at Tektronix in the mid-1980s). It represents one of
the fastest growing movements in the software world today, and many of the techniques
in this book will seem familiar to people who have worked in an XP environment.
XP consists of a set of rules and practices that govern all areas of software development:
planning, designing, coding, and testing. These practices emphasize interaction and collab-
oration between the engineering team and the stakeholders and users, as well as the abil-
ity to respond quickly to changes in order to produce working software. The goal of XP is
to lower the cost of change. Uncontrolled changes are the most common cause of software
project failure (see Chapter 6); by putting basic XP principles and practices in place, a
project team can control the changes.
The specific planning practices employed by XP are intended to be as lightweight and agile
as possible, and have a high level of user involvement. XP projects are planned in short
iterations using the Planning Game (see Chapter 3) in order to make frequent small
releases. The requirements are documented as user stories, which are written by the users.
Each user story is a brief, three-sentence description of a specific behavior that must be
performed by the software. It is much less detailed than a use case or a requirement, and
should only contain enough information to allow a developer to create a basic 1, 2, or 3-
week estimate. Once 80 or so user stories are created, a release plan is built by the develop-
ers; they divide the project into 1- to 3-week iterations. An iteration plan is developed
when each iteration begins. Project velocity is a metric that gauges how much work is get-
ting done on the project by comparing the sum of the estimates for the user stories
planned in the current iteration with the estimates for the tasks actually performed (simi-

lar to variance, in Chapter 4).
The main principle behind XP design is simplicity: a simple design is always more efficient
to build than a complex one. Classes and methods should be named consistently; a meta-
phor should be used to help guide developers in creating consistent names. Functionality
should never be added before it is scheduled. The developers should “refactor merci-
lessly”—that is, they should refactor the design and code whenever possible (see
Chapter 7).

XP coding employs some familiar practices: test-driven development (see Chapter 7) and
pair programming (see Chapter 5). In addition, one important principle in XP coding is
that the customer must always be available to the developers. This allows them to get con-
stant feedback and clarifications. Users and stakeholders are an active part of the develop-
ment team, and the developers have face-to-face communication with them throughout

PROCESS IMPROVEMENT 289