12 XP Practices

Small releases - 

By the end of each iteration( 2 to 3 weeks long)  the team is responsible for delivering working, tested code that can immediately be put to use.

The planning game - 

Prior to the start of each iteration, the team and customer plan the iteration.This involves selecting the highest priority stories that can be completed in the iteration and then identifying the specific tasks necessary to complete the story.

Refactoring - 

Refactoring (Fowler 1999; Wake 2003) refers to the restructuring or rewriting of code so as to improve the code without changing its external behavior.Refactoring is one of technique used by XP to replace upfront design.

Testing - 

XP puts the tests right up front in a practice called test-driven development (Beck 2003; Astels 2003). On an XP project the developers write automated unit tests and the customers write acceptance tests, which are often automated either by the customers themselves or with some help from the developers.

Pair programming- 

While pair programming may sound tremendously inefficient, Alistair Cockburn and Laurie Williams (2001) have studied it and found that not to be the case. They found that for a 15% increase in total programming time.

Sustainable pace -

It is up to the team to determine their sustained pace, and it is likely to be different for different members of the team. The belief is that an XP team moving at a consistent but brisk pace will achieve more over a period of time than will a team working at a pace they cannot sustain over a long period.

Team code ownership - 

All code is owned by everyone. Under this model of team ownership, any pair of developers can change any code. In fact, because of the refactoring practice, pairs are expected to change code they didn’t write.

Coding standard - 

The coding standard lays out the main rules and conventions team members will follow when writing code: how will variables and methods be named? how will lines be formatted? and so on.

Simple design- 

XP teams pursue a goal of having the simplest possible design that delivers the features a customer needs.

Metaphor -

XP teams support the quest for simple design by finding a metaphor that can be used for the whole system. The metaphor provides a frame of reference for how they think about the system.

Continuous integration -

XP teams know the answer and they integrate at least daily. We learned long ago about the benefits of a daily build and smoke test (Cusumano and Selby 1995).Integration problems are fixed one at a time in extremely small batches as soon as they occur.

On-site customer -

The customer writes the stories and the acceptance tests and also is on hand to answer questions as soon as they arise.If the customer is not on site, delays will disrupt the predictable progress of the XP team.

Source- Mike Cohn's book