Kent Beck defines Extreme Programming as a lightweight methodology
for small-to-medium-sized teams (2-10 people) developing software in the
face of vague and changing requirements.
In short, XP promises to reduce project risk, improve responsiveness
to business changes, improve productivity throughout the life of a system,
and add fun to building software in teams — all at the same time.
XP Values
-
Communication — The team's view of the system matches
the users's view of the system.
-
Simplicity — Developers focus their efforts on designing and
coding for today's needs instead of those of tomorrow.
-
Feedback — This includes feedback from the system, from the
customer and from the team.
-
Courage — Developers feel comfortable with refactoring their
code when necessary.
-
Respect — People should not negatively impact on the work
of others.
XP Principles
Fundamentals of XP include:
-
Distinguishing between the decisions to be made by business interests
and those to be made by project stakeholders.
-
Writing unit tests before programming and keeping all of the tests
running at all times.
-
Integrating and testing the whole system — several times a day.
-
Producing all software in pairs, two programmers at one screen.
-
Starting projects with a simple design that constantly evolves to add
needed flexibility and remove unneeded complexity.
-
Putting a minimal system into production quickly and growing it in
whatever directions prove most valuable.
XP Practices
Teams
XP projects share the following characteristics:
-
Every XP programmer participates in all of the critical project
activities every day.
-
An XP project starts with a quick analysis of the entire system
and XP programmers continue to make analysis and design decisions
throughout development.
-
Delivering business value is the heartbeat that drives XP projects.
-
Communication in XP projects occurs face-to-face, or through efficient
tests and carefully written code.
Addressing Risks
XP addresses risk at all levels of the development process.
| Risks |
Rules |
| Schedule slips |
XP calls for short release cycles: a release consists of one- to
four-week iterations with one- to three-day tasks per iteration.
|
| Project canceled |
XP asks the customer to choose the smallest release that makes the
most business sens (greatest software value).
|
| System goes sour |
XP creates and maintains a comprehensive suite of tests, which are
run and re-run after every change (possibly several times a day).
|
| Defect rate |
XP tests from the perspective of both programmers and customers.
|
| Business misunderstood |
XP calls for the customer to be an integral part of the team.
|
| Business changes |
XP shortens the release cycle, so there is less change during the
development of a single release.
|
| False feature rich |
XP insists that only the highest priority tasks are addressed.
|
| Staff turnover |
XP asks programmers to accept responsibility for estimating and
completing their own work and incorporates an explicit model of
staff turnover.
|
Further Readings
-
Extreme Programming Refactored: The Case Against XP
by Matt Stephens and Doug Rosenberg, 2003
APress
-
Extreme Programming Explained - Embrace Change
by Kent Beck, September 1999 (1st Ed.)
(ISBN: 0-2016164-1-6)
About the Author
Stéphane Micheloud is a senior software engineer. He holds a Ph.D in
computer science from
EPFL and a M.Sc in
computer science from
ETHZ. At EPFL he
worked on distributed programming and advanced compiler techniques and
participated for over six years to the
Scala project. Previously he was professor in computer science at
HES-SO // Valais in
Sierre, Switzerland.
Other Articles
