Database Reference
In-Depth Information
Small Releases:
Put a simple system into production quickly, then release new ver-
sions on a very short cycle.
•
Metaphor:
Guide all development with a simple shared story of how the whole system
works.
•
Simple Design:
The system should be designed as simply as possible at any given
moment. Extra complexity is removed as soon as it is discovered.
•
Testing:
Programmers continually write unit tests, which must run fl awlessly for devel-
opment to continue. Customers write tests demonstrating that features are fi nished.
•
Refactoring:
Programmers restructure the system without changing its behavior to
remove duplication, improve communication, simplify, or add fl exibility.
•
Pair Programming:
All production code is written with two programmers at one
machine.
•
Collective Ownership:
Anyone can change any code anywhere in the system at any
time.
•
Continuous Integration:
Integrate and build the system many times a day, every time
a task is completed.
•
40-hour Week:
Work no more than 40 hours a week as a rule. Never work overtime
a second week in a row.
•
On-site Customer:
Include a real, live user on the team, available full-time to answer
questions.
•
Coding Standards:
Programmers write all code in accordance with rules emphasizing
communication through code.
•
Many of these practices are old, tried and tested techniques, but often forgotten by
many, including most planned processes. XP integrates them into a synergistic whole where
each one is reinforced by the others.
XP defi nes the following lifecycle phases of an ideal project:
Exploration
,
Planning
,
Iterations to First Release
,
Productioning
,
Maintenance
and
Death
. According to this, XP
defi nes the main human roles in a typical XP project: Programmer, Customer, Tester, Tracker,
Coach, Consultant and Big Boss. XP is perfect for small to medium teams; the team size
should be between two and 12 project members. Communication and coordination between
project members should be enabled at all times, so they should be even physically collocated.
However, the geographical distribution of teams is not necessarily outside the scope of XP
in the case it includes two teams working on related projects with limited interaction (Beck,
1999). Similar to other agile methodologies, XP minimizes the efforts invested in model-
ing and up-front architectural design. For exploration and planning purposes XP uses user
stories, which are the light, textual version of use cases, while for design purposes the XP
team uses Class-Responsibility-Collaborator (CRC) cards, sketches of, e.g., classes, prose
text and refactoring. For representing a system architecture XP uses a metaphor—a simple
textual representation of the basic elements of the system and their relationships. Along with
that XP can use so-called architecture spikes that provide quick explorations into the nature
of a potential solution. XP does not require any tool support, except a simple whiteboard
for drawing necessary sketches as well as Story and CRC cards.
