Extreme Programming

Extreme Programming is an agile approach to software development that stresses customer satisfaction and teamwork. XP delivers clean designs and high quality software on a realistic schedule.

Many of the existing approaches to software development recognize the high cost of change and try to eliminate it early in the lifecycle using rigorous techniques for requirements gathering, planning and design.

Agile approaches recognize that change is inevitable and are tuned to adapt to changing requirements.

Agile approaches focus on delivering useful, working software early and often. Practices that do not contribute to this single-minded goal are considered unnecessary.

XP teams have a laser-like focus on testing.

Every line of code is written test-first. A unit test is written for all production code before the production code is written. All unit tests are run several times per hour to ensure that no bugs creep in. All code is reviewed as soon as it is written.

Automated acceptance tests are written for each feature. If a feature does not have an automated test, it is not a feature. All the tests must pass before a feature is accepted.

Customer requirements are captured as stories. A story is a description of a feature

• in plain English
• that delivers value to the customer
• and can be estimated and tested

The details of the story are passed from the customer to the rest of the team in face-to-face conversations and via automated acceptance tests. The headline of each story is written on an index card for planning purposes.

Stories are prioritized by the customer and worked on in two week increments called iterations. At the end of each iteration, the software product is ready to ship. The customer gets early and frequent feedback that the software is delivering exactly what is expected.

XP strictly divides the responsibilities of the team between the programmers and the customers.

• Business people make business decisions
• Technical people make technical decisions

The whole XP team, including the customer, works together in a room. Programmers work in pairs with each pair sharing a monitor and keyboard. Each pair shares the responsibility for designing, testing and writing the code to complete a task. Pairs rotate frequently.

The team evolves an architecture for the system and collectively owns all of the code. XP encourages a coding style where code written by one programmer cannot be distinguished from that written by another. Anyone can and does change code in any part of the system avoiding the single points of failure introduced by a guru working in private.

An XP project starts with a planning game where customers outline the requirements on story cards. The cards do not need a lot of detail - just enough to give the programmers a rough idea of how long the story will take to implement. Programmers estimate each story and the customer orders the stories according to business value. It's not important to be precise at this stage since the priorities and details are expected to change anyway.

Story estimates are given in relative terms or points. An arbitrary story is designated as a one point story and other stories are estimated as

• about the same size
• about twice as big
• about three times as big

Stories that are bigger than this need to be split into smaller stories by the customer. A one point story should take a couple of days or so.

The customer selects the stories for the first iteration based on the team's best guess at how many they can complete in two weeks. Each iteration is kicked off with a planning meeting where the team discusses the stories and breaks them down into engineering tasks. Individual programmers sign up for tasks.

At the end of each iteration, the team adds up the number of story points completed in that iteration to determine the team's velocity. The stories for the next iteration are selected according to Yesterday's Weather.

After each iteration, the customer is free to change the priorities of the project to reflect a changing business environment and a better understanding of the software solution as it evolves.

XP teams acknowledge the uncertain nature of the future and design for today, not tomorrow. A consistent desire to do the simplest thing that can possibly work drives every design decision. Complexity is added only to address the needs of the task at hand - not to address some future need that may never materialize.

Whenever new code is added, the existing code is refactored mercilessly to eliminate duplication and make sure the code expresses the intent of the programmer. The resulting design contains no unnecessary complication and can easily be molded to meet tomorrow's needs - when they arrive. The 100% coverage provided by unit tests ensures that refactoring does not introduce bugs.

New code is integrated with the main codebase several times a day to prevent the integration hassles that arise when modules are developed in isolation.

The resources page provides links to many of the best web sites and books that can help your organization reap the benefits that Extreme Programming provides.