Extreme Programming

Extreme programming (XP) is all about managing change. Rather than plan a project with tasks, schedules and all the usual paraphernalia XP suggests you should prepare yourself with research to help you understand the problem then jump in and make something. Then change it, and change it, and change it again based on feedback from in-team end users and the developers themselves.

Paradoxically for such a chaotic method discipline is at its core. Central control is replaced by rigid policies which produce an emergent structure rather than an externally imposed one. XP is mostly comprised of these policies.

Small Releases: Produce a simple version early then update it frequently based on the feedback each release generates. The feedback is the gold dust.

Common Project Naming System: Because XP is so fast moving everything needs to be done to enhance communication. A great deal of care is taken to design and police a system of names which the whole team use.

Simple Design : A simple design is always preferred over a complex one. Simple designs produce fewer bugs and are much more amenable to change and reuse. Future proofing is not seen as reason to allow complexity.

Lead With a Testing Strategy: Tests are written first the code is written to those tests. This creates a strong analysis of requirements then gives the developer clear target to aim for.

Re-factor often and hard: Many managers resist rewriting because it is seen as effort expended for no headway but this is a false economy the benefits of clean simple code far out weigh the time spent doing them. Plus re writes are very fast to do because they are base on experience and have a very narrow scope.

Program in pairs: Programmers should write all 'production' code in pairs, two programmers working together at one machine. This seems counter intuitive but it far, far better to code well than code cheaply - plus the practice has built in redundancy.

Integration Continuously: The longer a code branch is developed in parallel to the main code the harder it will be to integrate and the greater the chance of negative consequences after the integration.

40-hour Week: Tired programmers make more mistakes.

End User On Site . It is crucial to XP that project team contains someone who will use the software at the end and is empowered to make decisions about its requirements

Coding Standards : Having the whole team code in a specific way serves a number of purposes
It ensure code which is most likely to be changeable
It helps programmers work in pairs
It allows any member of the team to make changes to code they did not write.