Practices of eXtreme Programming
Practices of eXtreme Programming
Summarized from [BECK] XP explained.
Whole Team
All the contributors to an XP project -- developers, business analysts, testers, etc. -- work together in the same open space, members of one team. The walls of this space are littered with big visible charts and other evidences of their progress.
If geography and facilities make this impossible, the team should build a virtual open space, and paper its virtual walls with artifacts of progress.
Planning Game
Planning is continuous. Every two weeks, for the next two weeks, developers estimate the cost of the candidate features, and customers select those features to be implemented based upon cost and business value.
Customer Tests
As part of selecting each desired feature, the customers define automated acceptance tests to show that the feature is working.
Simple Design
The team keeps the design exactly suited for the current functionality of the system. It passes all the tests, contains no duplication, expresses everything the authors want expressed, and contains as little code as possible.
Pair Programming
All production software is built by two programmers, sitting side by side, at the same machine.
Test-Driven Development
The programmers work in very short cycles, adding a failing test, then making it work.
Design Improvement
Don't let the sun set on bad code. Keep the code as clean and expressive as possible. Refactor ruthlessly, and often.
Continuous Integration
The team keeps the system fully integrated at all times.
Collective Code Ownership
Any pair of programmers can improve any code at any time.
Coding Standard
All the code in the system looks as if it was written by a single -- very competent -- individual.
Metaphor
The team develops a common vision of how the system works.
Sustainable Pace
The team is in it for the long term. The work hard, at a pace that can be sustained indefinitely. They conserve their energy, treating the project as a marathon rather than a sprint.


