Method Overview

Classification

In terms of cycles and ceremony, XP classification is illustrated in Figure 8.1. For average projects, the recommended length of a timeboxed iteration is between one and three weeks somewhat shorter than for UP or Scrum.

Figure 8.1. XP on the cycle and ceremony scale.

cycles and ceremony

XP is low on the ceremony scale; it has only a small set of a predefined, informal workproducts, such as paper index cards for summarizing feature requests, called story cards.

A refreshing quality of the original XP description was the statement of known applicability: It had been proven on projects involving roughly 10 developers or fewer, and not proven for safety-critical systems. Nevertheless, it has been more recently applied with larger teams. Consequently, in terms of the Cockburn scale, XP perhaps covers the cells shown in Figure 8.2.

Figure 8.2. XP on the Cockburn scale

Cockburn scale

Introduction

XP^[1] [Beck00], created by Kent Beck, is an IID method that stresses customer satisfaction through rapid creation of high-value software, skillful and sustainable software development techniques, and flexible response to change. It is aimed at relatively small team projects, usually with delivery dates under one year. Iterations are short usually one to three weeks.

^[1] Some writers capitalize the full name as "eXtreme Programming" but Beck does not.

As the word programming suggests, it provides explicit methods for programmers, so they can more confidently respond to changing requirements, even late in the project, and still produce quality code. These include test-driven development, refactoring, pair programming, and continuous integration, among others. In contrast to most methods, some XP practices truly are adopted by developers they sense its practical programmer-relevant techniques.

XP is very communication- and team-oriented; customers, developers, and managers form a team working in a common project room to quickly deliver software with high business value.

XP is distinctive in not requiring detailed workproducts except for program code and tests. However, it doesn't disallow other detailed workproducts. Although all evolutionary methods avoid detailed up-front specifications and plans that span the entire release cycle, most of these methods encourage writing down details for at least the next iteration. In contrast, XP emphasizes oral communication for requirements and design. For example, a feature is summarized "Find lowest fare" on a handwritten paper index story card. Then, when work starts on the feature, the programmers learn details by talking with the customers working full-time in the project room. This may sound disorganized or naive, but Beck is experienced and well aware of the implications of sloppy requirements. Instead, XP is posing this interesting question:

Is there a sane and disciplined way to quickly succeed on typical small projects by focusing on code and tests, while avoiding most other documentation overhead?

XP's premise isn't hacker code-and-fix programming; rather, its premise is that there is a new, structured, and sustainable way to succeed with a focus on rapid code production and oral communication, while avoiding most other overhead. To reiterate, XP is not hacking. Quite the contrary, an XP project involves constant practice of highly disciplined yet agile software development practices and values.

XP consultant Don Wells explains the influence of the XP values [Wells01]:

XP improves a software project in four essential ways; communication, simplicity, feedback, and courage. XP programmers communicate with their customers and fellow programmers. They keep their design simple and clean. They get feedback by testing their software starting on day one. They deliver the system to the customers as early as possible and implement changes as suggested. With this foundation XP programmers are able to courageously respond to changing requirements and technology.

There is a considerable set of practices in XP: 12 core practices and many ancillary ones. Speaking of these, Wells writes [Wells01]:

It is a lot like a jig saw puzzle. There are many small pieces. Individually the pieces make no sense, but when combined together a complete picture can be seen.

Many of these practices work in synergy, and thus it is risky to customize XP by removing some elements. For example, XP aims to produce software quickly by in part avoiding detailed requirements documentation. But, this is compensated by the practice of onsite customers sitting in the project room to fill in the details.

The word extreme in XP comes from Beck's conviction that it is hard to have too much of a good thing in software development. That is, take known good practices and "turn the dial up to 10," or to extreme levels. For example:

• Testing is good, so write unit tests for (almost) all code, and acceptance tests for all features.

• Code reviews are good even better close to creation date so do code reviews in real time and all the time via pair programming.

• Frequent integration of code across all team members is good, so do it 24/7 with an automated, continuous integration process on a dedicated build machine.

• Short iterations and early feedback are good, so make iterations one or two weeks long, if possible.

• More customer involvement is good, so bring customers into the project full-time, sitting in the common project room.

• Communication is good, so have everyone sit together, pair program, include onsite customers, and involve the customer frequently in planning, steering, and evaluation.