XP: Extreme Programming

• XP: Extreme Programming
  • Definition
  • History
  • Rules
    • Coding
    • Testing
  • Practices
    • Fine Scale Feedback
    • Continuous Process
    • Shared Understanding
    • Programmer Welfare

Definition

XP is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements.

As a type of agile software development, it advocates frequent releases in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.

The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to extreme levels.

As an example, code reviews are considered a beneficial practice; taken to the extreme, code can be reviewed continuously (i.e, pair programming).

History

Kent Beck developed XP dasuring his work on the Chrysler Comprehensive Compensation Cystem (C3) system payroll project. He began to refine the development methodology used in the project and wrote a book on the methodology (Extreme Programming Explained).

The first version of rules for XP was published in 1999 by Don Wells at the XP website. 29 rules are given in the categories of planning, managing, designing, coding, and testing.

Another version of XP rules was pdroposed by Ken Auer in XP/Agile Universe 2003. He felt XP was defined by its rules, not its practices. He defined two categories: Rules of Engagement which dictate the environment in which software development can take place effectively, and Rules of Play which define the minute-by-minute activities and rules within the framework of the Rules of Engagement.

Rules

Coding

• The customer is always available.
• Code the unit test first.
• Only one pair integrates code at a time.
• Leave optimization until last.
• No overtime.

Testing

• 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 before the bug is addressed. A bug is not an error in logic; it is a test that was not written.
• Acceptance tess are run often and the results are published.

Practices

XP has 12 practices, grouped into four areas, derived from the best practices of software engineering.

Fine Scale Feedback

1. Pair Programming
2. Planning Game
3. Test Driven Development
4. Whole Team

Continuous Process

1. Continuous Integration
2. Design Improvement
3. Small Releases

Shared Understanding

1. Coding Standard
2. Collective Code Ownership
3. Simple Design
4. System Metaphor

Programmer Welfare

1. Sustainable Pace