HomeStreek ResourcesClient AppsDeveloper ResourcesTalksHowTo Docs
 

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.