ClassificationIn 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.
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
IntroductionXP[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.
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:
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]:
There is a considerable set of practices in XP: 12 core practices and many ancillary ones. Speaking of these, Wells writes [Wells01]:
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:
|