Processes + Meta-Processes

XP core practices
The core practices of eXtreme Programming, as described in the first edition of Extreme programming explained can be grouped into four areas (12 practices) as follows:

Fine scale feedback
• Test driven development
• Planning game
• Whole team (original name: Onsite customer)
• Pair programming

Continuous process rather than batch
• Continuous Integration
• Design Improvement (original name: Refactor)
• Small Releases

Shared understanding
• Simple design
• System metaphor
• Collective code ownership
• Coding standard or Coding conventions

The core practices are derived from generally accepted best practices, and are taken to extremes:

• Interaction between developers and customers is good. Therefore, an XP team is supposed to have a customer on site, who specifies and prioritizes work for the team, and who can answer questions as soon as they arise. (In practice, this role is sometimes fulfilled by a customer proxy.)
• If learning is good, take it to extremes: Reduce the length of development and feedback cycles. Test early.
• Simple code is more likely to work. Therefore, extreme programmers only write code to meet actual needs at the present time in a project, and go to some lengths to reduce complexity and duplication in their code.
• If simple code is good, re-write code when it becomes complex.
• Code reviews are good. Therefore XP programmers work in pairs, sharing one screen and keyboard (which also improves communication) so that all code is reviewed as it is written.
• Testing code is good. Therefore, in XP, tests are written before the code is written. The code is considered complete when it passes the tests (but then it needs refactoring to remove complexity). The system is periodically, or immediately tested using all pre-existing automated tests to assure that it works. See test-driven development.

XP values

Extreme Programming initially recognized just four values but a new value was added in the second edition of Extreme programming explained. The five values are:

• Communication
• Simplicity
• Feedback
• Courage
• Respect (the latest value)

Communication
A fundamental task of building software systems is communicating system requirements to the developers of the system. In formal software development methodologies, this task is accomplished through documentation.

Extreme Programming techniques can be viewed as methods for rapidly building and disseminating institutional knowledge among members of a development team. The goal is to give all developers a shared view of the system which matches the view held by the users of the system. To this end, Extreme Programming favors simple designs, metaphor, collaboration of users and programmers, frequent verbal communication and feedback.

Simplicity
eXtreme Programming encourages starting with the simplest solution and refactoring to better ones. The difference between this approach and more conventional system development methods is the focus on designing and coding for the needs of today instead of those of tomorrow, next week, or next month. Proponents of XP acknowledge the disadvantage that this can sometimes entail more effort tomorrow to change the system; their claim is that this is more than compensated for by the advantage of not investing in possible future requirements that may change before they become relevant. Coding and designing for uncertain future requirements implies the risk of spending resources on something that might not be needed. Related to the previous value, "communication", simplicity in design and coding should improve the (quality of) communication. A simple design with simple code can be easily understood by every programmer in the team.

Feedback
Within eXtreme Programming, feedback is related to different dimensions of the system development:

• Feedback from the system: by writing unit tests the programmers have direct feedback from the state of the system after implementing changes.
• Feedback from the customer: The functional tests are written by the customer and the testers. They will get concrete feedback about the current state of their system. This review is planned once in every two or three weeks so the customer can easily steer the development.
• Feedback from the team: When customers come up with new requirements in the planning game the team directly gives an estimation of the time that it will take to implement.

Feedback is closely related to communication and simplicity. Flaws in the system are easily communicated by writing a unit test that proves a certain piece of code will break. The direct feedback from the system tells programmers to recode this part. A customer is able to test the system periodically according to the functional requirements (User Stories). To quote Kent Beck, Optimism is an occupational hazard of programming, feedback is the treatment.

Courage
The Extreme Programming doctrine of "Courage in system development" can be best explained by a couple of practices. One is the commandment to always design and code for today and not for tomorrow. This is an effort to avoid getting bogged down in design and requiring a lot of effort to implement anything else. Courage enables developers to feel comfortable with refactoring their code when necessary. This means reviewing the existing system and modifying it so that future changes can be implemented more easily. Another example of courage is knowing when to throw code away. Every programmer has experienced getting stuck on a complex problem in their own design and code after working on it all day, then coming back the next day with a clear and fresh view and rapidly solving the problem in half an hour.