Extreme Programming

Extreme Programming (or XP) is a set of values, principles and practices for rapidly developing highquality
software that provides the highest value for the customer in the fastest way possible. XP is a
minimal instance of RUP. XP is extreme in the sense that it takes 12 well-known software
development “best practices” to their logical extremes.

The 12 core practices of XP are:

1. 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:
􀂃 Business comes up with a list of desired features for the system. Each feature is written
out as a user story (or PowerPoint screen shots with changes highlighted), which gives
the feature a name, and describes in broad strokes what is required. User stories are
typically written on 4×6 cards.
􀂃 Development team estimates how much effort each story will take, and how much effort
the team can produce in a given time interval (i.e. the iteration).
􀂃 Business then decides which stories to implement in what order, as well as when and how
often to produce production releases of the system.
2. Small releases: Start with the smallest useful feature set. Release early and often, adding a
few features each time.
3. System metaphor: Each project has an organising metaphor, which provides an easy to
remember naming convention.
4. Simple design: Always use the simplest possible design that gets the job done. The
requirements will change tomorrow, so only do what’s needed to meet today’s requirements.
5. Continuous testing: Before programmers add a feature, they write a test for it. Tests in XP
come in two basic flavours.
􀂃 Unit tests are automated tests written by the developers to test functionality as they write
it. Each unit test typically tests only a single class, or a small cluster of classes. Unit tests
are typically written using a unit-testing framework, such as JUnit.
􀂃 Customer to test that the overall system is functioning as specified, defines
acceptance tests (aka Functional tests). Acceptance tests typically test the entire
system, or some large chunk of it. When all the acceptance tests pass for a given user
story, that story is considered complete. At the very least, an acceptance test could
consist of a script of user interface actions and expected results that a human can run.
Ideally acceptance tests should be automated using frameworks like Canoo Web test,
Selenium Web test etc.
6. Refactoring: 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.
7. Pair Programming: All production code is written by two programmers sitting at one machine.
Essentially, all code is reviewed as it is written.
8. Collective code ownership: No single person “owns” a module. Any developer is expected to
be able to work on any part of codebase at any time.
9. Continuous integration: All changes are integrated into codebase at least daily. The tests
have to run 100% both before and after integration. You can use tools like Ant, CruiseControl,
and Maven etc to continuously build and integrate your code.
10. 40-Hour Workweek: Programmers go home on time. In crunch mode, up to one week of
overtime is allowed. But multiple consecutive weeks of overtime are treated as a sign that
something is very wrong with the process.
11. On-site customer: Development team has continuous access to a real live customer or
business owner, that is, someone who will actually be using the system. For commercial
software with lots of customers, a customer proxy (usually the product manager, Business Analyst etc) is used instead.
12. Coding standards: Everyone codes to the same standards. Ideally, you shouldn’t be able to
tell by looking at it, which developer on the team has touched a specific piece of code.

A typical extreme programming project will have:
• All the programmers in a room together usually sitting around a large table.
• Fixed number of iterations where each iteration takes 1-3 weeks. At the beginning of each
iteration get together with the customer.
• Pair-programming.
• Writing test cases first (i.e. TDD).
• Delivery of a functional system at the end of 1-3 week iteration.

Advertisement