Extreme Programming (XP)

What is extreme programming?

Key rules of extreme programming

In the extreme programming agile framework, there are 5 key sets of rules at the heart of an XP project.

eBook

Agile: Best Practices and Methodologies

Read now

Planning

• User stories are essential, written from the perspective of the customer. They are three sentences long and avoid technical language

• Releases should be planned, which lays out the overall project. This is then used to create a release schedule

• Releases should be small and frequent, to get real user feedback as quickly as possible

• The project must be divided into iterations, which are planned just before starting

Management

• Teams should have a dedicated and open workspace

• Each day starts with a standup

• The pace of delivery should be sustainable

• Velocity should always be measured

• Staff should be trained cross disciplines and rotated to avoid having exclusive specialists for parts of the project. This is called 'Collective Code Ownership'

• When XP doesn't work, it should be discussed in a retrospective

Designing

• Designs should be simple

• Use CRC cards when designing the system

• Do 'spike solutions' to learn and explore technical problems

• Don't add unneeded functionality

• Refactor and change the design of the software as and when required

Coding

• Developers should have access to the customer for feedback

• Code must be written to agreed standards

• Use test-driven methodology

• Pair program all production code

• Use source control

Testing

• All code must have unit tests

• All code must pass these tests before being released

• When a bug is identified, create a test around it, then resolve the issue