The 12 practices in XP are as
Test-driven development (via unit tests and customer tests, aka acceptance tests)
The planning game
Whole team (was on-site customer)
The list changes occasionally; for example, 40-
An important XP practice that didn t make it into the official list of 12 is emergent design.
We discuss emergent architecture and design in Chapter 12.
Another XP practice that wasn t on Kent Beck s original list but has since become central to XP (in the form of the whole team practice), is that of
We discuss how
colocatedteams affect scalability in the section When XP Starts to Fail, in Chapter 14.
This practice is a combination of the practice of testing the code and the design (unit testing) and the practice of testing that all the requirements have been implemented (acceptance testing). Unit tests (aka programmer tests ) are always written by the programmers, and acceptance tests (also known as functional tests and customer tests ) are, if possible, written by the customer.
XP takes a test-first approach to programming. That is, for each class (or task), you first write the unit tests, run them, see that they fail, and then write the code that s necessary to prevent the unit tests from failing.
An increased emphasis on unit testing and on the use of automated testing tools is probably the most useful benefit to have emerged from the XP
Planning in XP involves
involves breaking the project into very short 1- to 3-week iterations and taking the project one iteration at a time. For each iteration, the customer needs to decide which
Any piece of work that takes time is written up as a
and assigned its own little piece of cardboard (the
). User stories must be testable and
Each story represents a week or two of work. To make work allocation and estimating easier, each story is broken down into smaller
The story cards
If the customer (or higher management)
As the project progresses, estimating of user stories, in theory, becomes more accurate. The rate of user stories completed per fixed iteration is known as the project velocity. A key goal in an XP project is to maintain a consistent ( therefore predictable) velocity.
As we ll see in Chapter 11, some Extremos regard constant velocity as more important than deadlines.
From Extreme Programming Explained :
A real customer must sit with the team, available to answer questions, resolve disputes, and set
small-scalepriorities. By ˜real customer I mean someone who will really use the system when it is in production. 
The definition of an XP customer has actually changed since the
The following quote is from XP author Michael Feathers:
Some larger teams doing XP have teams of customers. The important thing isn t so much that there is a single customer, but that the ˜customer speaks with one voice. [6 ]
This is an important aspect of the XP customer (in fact, of any customer in any project). The customer must speak with one voice ”that is, the programmers must receive clear, unambiguous, nonconflicting instructions on what to create.
The Feathers quote also indicates that the concept of the customer role has evolved still further, that the customer may be an entire team. In his foreword to Pete McBreen s
Questioning Extreme Programming
, Kent Beck
I will suggest that as you read this, you keep in mind one mistake of early XP thinking for which I am entirely responsible ” ˜the customer doesn t mean one person. It means a team, as big or bigger than the development team. 
Beck doesn t specify whether the customer team should be in the same room as the development team. This raises some questions about how the XP customer can still speak with a single voice. If they re colocated in the same room, it would be rather difficult to
Back to Extreme Programming Explained :
Put a simple system into production quickly, then release new versions on a very short cycle. 
Although this approach does have advantages, there are also certain risks that must be contained (these are discussed later). In fact, we ve noticed a small caveat being added onto this practice more recently: The (typical) 2-week iteration doesn t
Also from Extreme Programming Explained :
It is far better to plan a month or two at a time than six months or a year at a time. A company shipping bulky software to customers might not be able to release this often. They should still reduce their cycle as much as possible. 
The theory behind small releases is that
In XP, the software architecture is complemented with a single unifying metaphor. The
is a simple shared story of how the system works. All naming and design
Similarly, a contract management system would be spoken of in terms of contracts, customers, and endorsements, and an online e-commerce system would be described in terms of products, a shopping cart, and a checkout procedure.
The system metaphor is often a bone of
A simple design is quicker to code and easier to maintain than a complex design.
In XP, a driving design
As we mentioned earlier, a fundamental XP practice, which didn t make it into the original list of 12 practices but was added later, is emergent design , the concept of growing a design as your understanding of the problem (and best solution) evolves. Emergent design is discussed in an article by Ron Jeffries on his Web site ( http://www.xprogramming.com ). It could be thought of as a combination of refactoring, test-driven development, simple design, and metaphor, and of the XP designing activity.
We discuss emergent design in Chapter 12.
Refactoring is the practice of improving the design of existing code. XP advises that you strive for simple designs. Therefore, refactoring in XP means looking for ways to simplify the design of existing code while still running all of the tests. And, because XP eliminates up-front design before coding (aka big design up front [BDUF]) you ve always got plenty of code that needs improving. We like to call this Constant Refactoring After Programming.
XP does recommend that you only refactor code that really needs it (e.g., where there is
Although the code is existing, it might have been written only a few seconds ago. The theory is that refactoring is a constant and integral part of programming. By continuously thinking about how to simplify your code (and of course doing it), you theoretically end up with a better code-level design (or, in Extremo jargon, better smelling code ).
More on refactoring in Chapter 9.
Everyone is responsible for the entire code base. If a programmer sees something she doesn t like about any piece of code in the project, she (and her pair-programming buddy) can go in and change it.
Although XP has collective code ownership, it has individual task ownership.
This means that each programmer signs up for tasks at the start of each iteration and is responsible for completing that task by the end of the iteration. Usually, a programmer will sign up for tasks that interest him or that fall under his own
We discuss collective ownership in the What If Programmers Take Ownership of Code? section in Chapter 3.
You can code on your own for nonproduction code
To keep pairs from becoming stale, and to facilitate collective ownership, XP encourages people to move around and switch
When people are allowed to choose their own pairs, they ll usually choose to work on parts of the project that interest them most or that they re most suited to. If you like to write stored procedures, then whenever a user story comes up involving a stored procedure task,
The XP literature is quite clear that pair programming is mandatory for all production code. That is confirmed online by XP author Robert C. Martin:
The only constraint that XP puts on you is that any production code has be [sic] written by a pair. Your preferences and
comfortdo not supercede the delivery of quality to the project, or your parcitipation [sic] in the team. 
Alternatively, you could take XP author Ron Jeffries advice:
XP says that ˜all production code is written by two people sitting together at one machine . That s the rule. As far as I know, no project has ever done that, including many that I consider to deserve the
nameXP. So what s the rule about? It s an ideal. It s what we strive for. It is a stretch goal. 
Elsewhere, to confuse us even more, Ron also says:
The definition of doing Level 0 XP is quite unambiguous and clear: the 12 practices, all the time. 
Whichever XP author s advice (Ron s or his evil twin s) you choose to follow, if you strive for pair programming, then you might find that the pairing up mindset becomes habitual: Extreme Programming Explained even recommends pair integrating.
We discuss pair programming further in Chapter 6.
In Chapter 13, a practicing (though skeptical) XPer describes a project in which pair progress-bar watching was mandatory for all.
Code is integrated and
As mentioned previously, pair programming can lead to habitual pairing in other aspects of XP, including pair integrating:
When the machine is free, a pair with code to integrate sits down, loads the current release, loads their changes (checking for and resolving any collisions), and runs the tests until they pass (100% correct). 
The upshot is that a 40-hour week (as this practice used to be known) is quite a good thing, really. Sustainable pace will result in higher productivity levels in the long run than making frequent mad dashes that quickly burn out your programmers.
Coding standards are important in any programming project, and more so in an XP project, because any pair of programmers can change any part of the code at any time.
Coding standards also help a lot in making your code clearer, as in easier to read and decipher. Encouraging programmers to give their
 See http://www.objectmentor.com/writeUps/TestDrivenDevelopment and Kent Beck, Test-Driven Development: By Example (New York, NY: Addison-Wesley, 2002).
 Beck, Extreme Programming Explained, op. cit., p. 60.
[6 ] Michael Feathers posting to the newsgroup comp.software.extreme-programming, subject: Re: On-site Customer Liaison; was The Case against XP, December 29, 2001.
 Pete McBreen, Questioning Extreme Programming (New York, NY: Addison-Wesley, 2002), p. xvi.
 Beck, Extreme Programming Explained, op. cit., p. 54.
 Beck, Extreme Programming Explained, op. cit., p. 56.
 See http://www.jera.com/techinfo/xpfaq.html .
In this book we use production code to mean source code that s being
 Robert C. Martin posting to the newsgroup comp.object, subject: Re: Pair Programming ” Yuck! October 28, 2001.
 Ron Jeffries, Misconceptions About XP, http://www.xprogramming.com/xpmag/Misconceptions.htm, January 21, 2002.
 See http://www.c2.com/cgi/wiki?IfXpIsntWorkingYoureNotDoingXp.
 Beck, Extreme Programming Explained, op. cit., p. 59.