eXtreme Programming
The first Extreme Programming project was started March 6, 1996. Extreme Programming is one of several popular Agile Processes. It has already been proven to be very successful at many companies of all different sizes and industries world wide.

Extreme Programming is successful because it stresses customer satisfaction. Instead of delivering everything you could possibly want on some date far in the future this process delivers the software you need as you need it. Extreme Programming empowers your developers to confidently respond to changing customer requirements, even late in the life cycle.

Extreme Programming emphasizes teamwork. Managers, customers, and developers are all equal partners in a collaborative team. Extreme Programming implements a simple, yet effective environment enabling teams to become highly productive. The team self-organizes around the problem to solve it as efficiently as possible.

2001, Kent Beck, Ward Cunningham & Ron Jeffries.
Extreme Programming has been described as having 12 practices, grouped into four areas:

Fine scale feedback
  • Pair programming - means that all code is produced by two people programming on one task on one workstation.
  • Planning Game - is a planning meeting that occurs once per iteration, typically once a week.
  • Test-driven Development - unit tests are written before the eventual code is coded.
  • Whole team - within XP, the "customer" is not the one who pays the bill, but the one who really uses the system.
Continuous process
  • Continuous integration - will avoid delays later on in the project cycle, caused by integration problems.
  • Refactoring or design improvement - refactor the code by changing the architecture, making it simpler and more generic.
  • Small releases - the delivery of the software is done via frequent releases of live functionality creating concrete value.
Shared understanding
  • Coding standards - is an agreed upon set of rules that the entire development team agree to adhere to throughout the project.
  • Collective code ownership - means that everyone is responsible for all the code; this, in turn, means that everybody is allowed to change any part of the code.
  • Simple design - programmers should take a "simple is best" approach to software design.
  • System metaphor - is a story that everyone - customers, programmers, and managers - can tell about how the system works.
Programmer welfare
  • Sustainable pace - the concept is that programmers or software developers should not work more than 40 hour weeks, and if there is overtime one week, that the next week should not include more overtime.

We would like to suggest you the following list of usefull resources on the topic: