Extreme Programming (XP) is a no nonsense, code first approach to software delivery that emphasises four basic activities: coding, testing, listening, and designing.
It was the first Agile method to truly challenge traditional Waterfall methods. It did away with traditional requirements gathering techniques, brought testing to the forefront of the delivery process, and helped popularize core software engineering practices like automated testing, refactoring, continuous integration (CI), and test-driven development (TDD).
|The Planning Game||
Business and development cooperate to produce the maximum business value as rapidly as possible. The planning game happens at various scales, but the basic rules are always the same:
Start with the smallest useful feature set. Release early and often, adding a few features each time.
Each project has an organizing metaphor, which provides an easy to remember naming convention.
At every moment, the design runs all the tests, communicates everything the programmers want to communicate, contains no duplicate code, and has the fewest possible classes and methods. This rule can be summarized as, 'Say everything once and only once.'
Before programmers add a feature, they write a test for it. When the suite runs, the job is done. Tests in XP come in two basic flavors.
Refactor out any duplicate code generated in a coding session. You can do this with confidence that you didn”t break anything because you have the tests.
All production code is written by two programmers sitting at one machine. Essentially, all code is reviewed as it is written.
|Collective Code Ownership||
Every programmer improves any code anywhere in the system at any time if they see the opportunity
New code is integrated with the current system after no more than a few hours. When integrating, the system is built from scratch and all tests must pass or the changes are discarded.
|40-Hour Work Week||
No one can work a second consecutive week of overtime. Even isolated overtime used too frequently is a sign of deeper problems that must be addressed.
A customer sits with the team full-time
Everyone codes to the same standards. Ideally, you shouldn't be able to tell by looking at it who on the team has touched a specific piece of code.
XP was is a bet that hard problems become easier when tackled continuously all the time.
Here are some great books on XP. Start with Kent's white book (1st Edition) on the left. Then move onto the green and the pink ones. There is a 2nd Edition white book, but I recommend reading the 1st edition first and then the 2nd if you like it.