Learning To Become More XP

I'm still fascinated by the Agile XP methodology. So when I came across the overview of XP in the Appendix of...

User Stories Applied: For Agile Software Development (The Addison-Wesley Signature Series) by Mike Cohn

Roles

The XP customer role is responsible for writing stories, prioritizing stories, and writing and executing tests that demonstrate that stories were developed as expected.
The XP programmer role encompasses a broad range of technical skills. XP projects tend not to draw distinctions between programmers, designers, DBA's and so on.
XP teams benefit for the use of an XP coach and possibly a project manager. The coach is responsible for monitoring the team's use of the XP practices and gently nudging them back on track when they stray.

Project progress in a series of iterations, which are typically 1 to 3 weeks long. Features are fully delivered within a single iteration.

This is the name for release and iteration planning where developers and customers collaborate to make predictions about the future.
Prior to planning, the customer has written user stories on note cards and developers have estimated the cost of magnitude of each story and have written the estimate on the story card.

Refers to the restructuring or rewriting of code so as to improve the code without changing its external behavior.
XP advocates constant attention to refactoring. Whenever a programmer makes a change to code that should be refactored, she is required to refactor it.
She's not encouraged to refactor it; she's required to refactor it.
Instead of spending time upfront thinking through a system in advance of coding it, and therefore taking guesses at some aspects of its behavior, XP systems are refactored and kept in a state that perfectly meets known, implemented requirements.

The developers write automated unit tests.
The customers write acceptance tests.
In test-driven development, tests are written before the code. Developers follow a short cycle of test-code-test-code... No operational code may be written except in response to a failing test.

Refers to 2 programmers sharing one computer and 2 brains to write code. One programmer types the code, the second is watching the code develop and thinking more broadly about the code.
This leads to lower defect counts, less code is written to solve the same problem, problems being solved more quickly, more people understand each piece of code, an increase in developer satisfaction.
It requires discipline to refactor every time you notice poorly structured code.

The believe 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 of time.
It is up to the team to determine their sustained pace.
A team will typically devote around 6 hours per day to pairing and spend the remainder of the day in other activities.
An XP coach is responsible for monitoring the team for burnout.

It's common in non-XP teams for individuals to "own" portions of a systems code. This leads to comments like "We can't change the billing source code until Eli gets back from vacation."
All code is owned by everyone.
Pairs are expected to change code they didn't write.
A strong suite of unit tests ensures that changes do not introduce unanticipated side effects.

XP teams collectively own their source code, so it's important to follow a coding standard.
A small, close-knit team may be able to get by without a written, formalized coding standard.

Pursue a goal of having the simplest possible design that delivers the features a customer needs.
The operational code and the test code fully convey the programmers intent.
There is no duplicate code.
The system uses the least number of classes.
The system uses the least number of methods.

Quest for simple design by finding a metaphor that can be used for the whole system. The metaphor describes how they think about the system.
E.g. "The system is like a chalkboard and various parts of the system can write on the chalkboard. When a user is done with the system she can either save the contents of the chalkboard or erase them."

Code is integrated continuously.
A developer completes a small change, he checks the change into source control, where the CI box initiates a full build. When the build is finished a full set of unit tests are run. If any tests fail, the developer is notified by email and told about the failure.
Integration problems are fixed one at a time in extremely small batches as soon as they occur.

The customer is expected to sit with and be part of the development team. The customer writes the stories and the acceptance tests and is also available to answer questions as they arise.
If the customer is not on site, delays will disrupt the predictable progress of the XP team.