The 12 Practices of Extreme Programming

The Planning Game
In XP, planning (characterized as “The Planning Game”) is both iterative and collaborative. It is iterative in that the “game is played” at the beginning of each increment of development. It is collaborative in that it is played among the technical team members and the customer and management (referred to as
the business people). During the Planning Game for each increment, the business people and the technical people negotiate to establish an achievable plan that best meets the business needs. During this negotiation, the customer identifies what system features would be most valuable to develop next, the technical team determines the feasibility and effort for developing that functionality, and management ensures that the project stays within any relevant parameters (e.g., cost).

Small releases
An XP project team develops the system in the smallest reasonable chunks that provide demonstrable value for the customer. Because each increment should take only a few weeks to develop, the functionality that can be developed in that time is very constrained. But even when it is not feasible to actually release an increment for use, that increment is still demonstrated for customers so they can verify that it is progressing toward meeting their needs and appears to be usable.

Metaphor
An XP project’s Metaphor is the overall concept of the system that the team will build. The Metaphor uses similes to describe what the system will be like, in terms that are readily recognizable to both the development team and customer. This very high-level vision is the XP project’s overall requirement, and there is an expectation that it will remain relatively stable throughout the project.

The actual descriptions of the system features are documented separately in “Stories.” Each feature is documented in a separate Story that describes the feature’s essential attributes and actions. These descriptions are also quite brief, comprising only the text that can be written on a 3x5-inch card. The stories on an XP project tend to change dynamically as the development team and customer learn about the product they are building and gain a better understanding of the customer’s needs. The Stories, taken together with the project’s Metaphor, form the requirements from which the system is planned and developed.


Simple design
This practice is the heart of XP’s value of “Simplicity.” It advises that programmers avoid designing for the features that they “know” are coming (even if they will be implemented within the current increment). Instead, they must use the simplest possible design that will allow the current Story to be implemented.

XP is based on the philosophy that this “simple design” practice will result in less rework than designing for the future. This is because we are often wrong when we design for the future, and when we are, the rework can be significant. Beck sums up this practice: “If you believe that the future is uncertain, and you believe that you can cheaply change your mind, then putting in functionality on speculation is crazy”.

Test First
One of XP’s defining philosophies is “Test First.” This philosophy states that before a pair of programmers writes a single line of code, they must implement the automated tests that will be required to verify the Story they are about to write.

In addition, customers also develop a set of functional tests One of XP’s defining philosophies is “Test First.” This philosophy states that before a pair of programmers writes a single line of code, they must implement the automated tests that will be required to verify the Story they are to verify the Story according to their own needs. Coding the XP way consists of code a little, test a little, code a little, test a little—with the test results being the programmers’ measure of progress on the Story at hand. Work on the Story is not complete until all the tests run 100% clean. Successful integration is also defined in terms of these automated tests.


Refactoring
XP’s Refactoring practice prompts each pair of programmers to ask themselves before they begin work on a Story if there is a way to redesign the system so that the final result “is the simplest thing that could possibly work”. Then, after they have completed work on the Story, Refactoring prompts them to ask the same question again. In either case, if the answer is, “Yes,” then the redesign is implemented as part of the work on that Story. Refactoring is used to ensure that the “simple” designs that programmers start with do not grow into needless complexity as more Stories are added.


Pair Programming
The most visible practice of XP is Pair Programming. This practice calls for all technical work (from design to coding to test) to be done by a pair of programmers working together at a single workstation. Pairs form and change dynamically throughout the project according to the needs of each story. The member of each pair who is not typing has a very special job. That person is to be thinking about the wider impacts of what is being implemented— to be continuously asking questions like, “Is there a simpler way to do this?” “Do we need tests that we did not yet create?” “Are there defects in this code?” “Will this strategy work?” Pair Programming has been called the ultimate in peer reviews, because it entails a continuous, real-time review of everything that is done. This is one more example of XP’s strong emphasis on technical excellence.

Collective ownership
XP takes a position on code ownership that is quite different from the standard model of assigning responsibility for each code module to a specific person. XP goes to the opposite extreme—stating that code should never be “owned” by any individual. When anyone identifies a need to change any code, it is that pair’s responsibility to implement that change. Every member of the team owns all code collectively.


Continuous integration
XP goes beyond the concept of daily builds to require that integration of the product being built goes on continuously. As a pair completes each Story, their last step is to integrate their new and changed code (along with their automated tests) into the baseline system. They then run the entire test suite all of their own automated tests, as well as those for all the Stories that are already part of the system. If any test fails, the new Story and tests are backed out, and the pair must resolve the problems before they can try again. When all the tests run 100% clean, the Story has been successfully integrated and becomes part of the project baseline. Because there are several pairs of programmers working on different Stories at all times, this practice results in someone integrating something almost all the time.

40-hour week
XP calls for overtime to be rare. It explicitly suggests that overtime should not be worked 2 weeks in a row. The intention with this practice is to keep everyone fresh so they can continue indefinitely on an aggressive but sustainable pace.

On-site customer
One of the key members of an XP project team is the on-site customer. This is a person who will be a real user of the system being built, or some other person who can authoritatively stand in for the customer/user. This practice ensures that an appropriately knowledgeable person is continuously available to the team to review work, try things out, answer questions, and make implementation decisions when they are needed.

Coding standards
Several other XP practices (most notably Pair Programming and collective ownership) give rise to the importance of good coding standards. In a team that is collaborating this closely, appropriate standards are the only way to maintain order.Additionally this practice is support knowledge flow and knowledge management in your team.



References
Beck, K., Extreme Programming Explained, Reading, MA: Addison-Wesley Longman, Inc., 2000.