|
Extreme Programming, or XP, is a lightweight
discipline of software development based on principles of simplicity,
communication, feedback, and courage. XP is designed for use with small teams
who need to develop software quickly in an environment of rapidly changing
requirements.
XP was developed by Kent Beck, who wrote the original book on the subject,
Extreme Programming Explained (see below).
Ultimately, any team's software development methodology needs to be
customized to the team and their circumstances. No methodology is just a
collection of rules to be performed in rote fashion, and XP - in spite of its
famous rules - is no exception.
XP is implemented over twelve key practices. Here they are:
The Planning Process
The XP planning process allows the XP
"customer" to define the business value of desired features, and uses cost
estimates provided by the programmers, to choose what needs to be done and what
needs to be deferred. The effect of XP's planning process is that it is easy to
steer the project to success.
Small Releases
XP teams put a simple system into production early,
and update it frequently on a very short cycle.
Metaphor
XP teams use a common "system of names" and a common
system description that guides development and communication.
Simple Design
A program built with XP should be the simplest
program that meets the current requirements. There is not much building "for the
future". Instead, the focus is on providing business value. Of course it is
necessary to ensure that you have a good design, and in XP this is brought about
through "refactoring", discussed below.
Testing
XP teams focus on validation of the software at all times.
Programmers develop software by writing tests first, then software that fulfills
the requirements reflected in the tests. Customers provide acceptance tests that
enable them to be certain that the features they need are provided.
Refactoring
XP teams improve the design of the system throughout
the entire development. This is done by keeping the software clean: without
duplication, with high communication, simple, yet complete.
Pair Programming
XP programmers write all production code in pairs,
two programmers working together at one machine. Pair programming has been shown
by many experiments to produce better software at similar or lower cost than
programmers working alone.
Collective Ownership
All the code belongs to all the programmers.
This lets the team go at full speed, because when something needs changing, it
can be changed without delay.
Continuous Integration
XP teams integrate and build the software
system multiple times per day. This keeps all the programmers on the same page,
and enables very rapid progress. Perhaps surprisingly, integrating more
frequently tends to eliminate integration problems that plague teams who
integrate less often.
40-hour Week
Tired programmers make more mistakes. XP teams do not
work excessive overtime, keeping themselves fresh, healthy, and effective.
On-site Customer
An XP project is steered by a dedicated individual
who is empowered to determine requirements, set priorities, and answer questions
as the programmers have them. The effect of being there is that communication
improves, with less hard-copy documentation - often one of the most expensive
parts of a software project.
Coding Standards
For a team to work effectively in pairs, and to
share ownership of all the code, all the programmers need to write the code in
the same way, with rules that make sure the code communicates clearly.
|