Extreme Programming (XP) Rules

The rules of Extreme Programming (XP) were documented by Don Wells and can be read at: www.extremeprogramming.org/rules.html. They are categorised by the following five headings:

1. Planning
2. Managing
3. Designing
4. Coding
5. Testing

XP Planning Rules

XP Rule	Further Information
User stories are written.	Practice: Stories
Release planning creates the release schedule.	Practice: Quarterly Cycle
Make frequent small releases.	Practice: Regular Releases
The project is divided into iterations.	Practice: Weekly Cycle
Iteration planning starts each iteration.	Practice: Planning Game

XP Managing Rules

XP Rule	Further Information
Give the team a dedicated open work space.	Practice: Co-location/Sit Together
Set a sustainable pace.	Practice: Sustainable Pace/Energised Work
A stand up meeting starts each day.	Event: Daily Stand-up
The Project Velocity is measured.
Move people around.
Fix XP when it breaks.

XP Designing Rules

XP Rule	Further Information
Simplicity.	Value: Simplicity Practice: Simple Code and Design
Choose a system metaphor.	Practice: Common Vocabulary???
Use CRC cards for design sessions.
Create spike solutions to reduce risk.
No functionality is added early.	Value: Simplicity
Refactor whenever and wherever possible.	Practice: Refactoring Value: Courage

XP Coding Rules

XP Rule	Further Information
The customer is always available.	Value: Communication Value: Feedback Practice: Whole Team Practice: Real-Customer Involvement
Code must be written to agreed standards.
Code the unit test first.
All production code is pair programmed.
Only one pair integrates code at a time.
Integrate often.
Set up a dedicated integration computer.
Use collective ownership.

XP Testing Rules

XP Rule	Further Information
All code must have unit tests.
All code must pass all unit tests before it can be released.
When a bug is found tests are created.
Acceptance tests are run often and the score is published.