Certified Associate in Project Management (CAPM)

Extreme Programming (XP) practices explained for the CAPM

Extreme Programming (XP) is an agile method for small software teams, built from a set of rules grouped under planning, managing, designing, coding and testing. Its best-known coding rules are pair programming, writing the unit test first, integrating often and collective ownership of the code.

When XP fits

XP was created for problem domains whose requirements change, for example when customers do not have a firm idea of what the system should do, or its functionality is expected to change every few months. It was also set up to reduce project risk, such as a new system needed by a fixed date that is a new challenge for the group.

XP is set up for small groups of 2 to 12 programmers, and cannot be used on a project with a huge staff. It needs an extended team in which managers and customers work alongside the developers, and it needs a system that can be tested with automated unit and functional tests.

The coding practices

Pair programming: all code sent into production is written by two people at a single computer. The partners work as equals, even if one has much more experience. It is not mentoring.

Test first: write one unit test for a small part of the problem, then the simplest code that makes it pass, then the next test, until nothing is left to test. When all the unit tests run, the work is done.

Integrate often: each pair integrates and commits its code every few hours and never holds changes for more than a day. This avoids fragmented development and finds compatibility problems early. Only one pair integrates at a time.

Collective ownership: any developer can change any line of code to add functionality, fix bugs, improve designs or refactor, so no one person becomes a bottleneck. A full unit test suite that must pass at 100% before any release makes this safe.

Design and pace

Refactoring means removing redundancy, eliminating unused functionality and renewing obsolete designs. XP says to do it throughout the project to keep the design simple.

XP's managing rules include a dedicated open work space, a sustainable pace, a daily stand-up meeting and measuring project velocity. XP says overtime makes a team tired and less productive, so when a release is at risk the answer is to change scope or timing at a release planning meeting, not to push people harder.

Where the exam catches people

Believing pair programming means a senior coaching a junior: XP says the partners work as equals and that it is not mentoring.
Believing tests are written after the code in XP: the unit test is written first, then the simplest code that passes it.
Believing each programmer owns their own classes: under collective ownership anyone may change any line of code.
Believing XP suits any team size: it is set up for small groups and cannot be used with a huge staff.
Believing overtime is the fix for a slipping XP iteration: XP changes scope or timing instead and keeps a sustainable pace.