Extreme Programming Installed, Chapters 22-24

Reference Information
Extreme Programming Installed
Jeffries, et al
Addison-Wesley Professional, 2000


Summary
Chapter 22 is entitled Handling Defects. Firstly, defects should never be called bugs. Defects reduce the business value of the software and also take away future value because time must be spent in correcting them. Defect correction should use a similar scheduling system as the extreme programming already uses: note cards. The customer (or reporter, as it were) would simply write the issue on a card and schedule its completion for an upcoming iteration. More urgent fixes may need to push other jobs out of the current iteration so that they can be completed in time for the next release. If many issues arise, programmers could be assigned to handle incoming reports on a rolling basis. The presence of a bug in released code indicates that there is an issue with both the unit and acceptance tests; this must be rectified to ensure that further bugs do not slip through. Bugs typically manifest at the edge of what is being tested - just outside what is expected. Many times bugs will cluster around a particular system, which means this system needs extensive checking or even reshuffling of the programming team.


Chapters 23 concludes the main portion of the book and lists many of the topics that were discussed in detail earlier. Extreme programming allows the programming team to better communicate with each other, the customers, and managers. The core values of extreme programming are simplicity, communication, feedback, and courage. The topics that the conclusion deems important are:

• On-site customer
• Small releases
• Planning
• Metaphor
• Simple design
• Pair programming
• Collective code ownership
• Continuous integration
• Coding standard
• Testing
• Refactoring
• Forty-Hour Week

Chapter 24 discusses ways to estimate the time of completion and how to bargain with customers and management to ensure that maximum value is delivered in a timely manner without overloading the programming team. Time should be estimated in perfect engineering days, which is the amount of work a programmer could get done if he had a full day to work without interruptions. The authors recommend planning to take three times longer than what would be accomplished in perfect engineering terms. All the stories are analyzed and assigned a cost that corresponds to this estimated work effort. The team needs to keep the customer and management up-to-date on progress and the expected delivery date, which changes based on velocity. 

Opinion

There is nothing really new presented in these three chapters. The only thing of note is the stipulation that it may be necessary to assign people full-time to handling incoming bug reports. If it got to that point, the team must not have been following extreme programming very well or the product is very poor.