Extreme Programming Installed, Chapters 16-18

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


Summary
Chapters 16-18 of Extreme Programming Installed act as a guide to implementing the ideas presented in the previous chapters. The chapters covered general ideologies of extreme programming as well as offering specific measures that can be used to gauge completion.


An extreme programming produced piece of software should be well designed, well crafted, flexibly structured, properly documented, tested, and should meet known and documented requirements. To achieve this, the team should follow these guidelines:

• Do not design the entire system before implementation since requirements are liable to change
• Practice continuous design, refactoring where necessary
• Requirements should not be frozen at the start of the project - let the customer change his mind
• Take stories in any order
• Do not produce design documents until the end when the design is actually final
• Focus on writing clear code and communicating with the customer
• Do not make documentation that is not being used
• Publish progress reports frequently
• Let team members be both a designer and a coder
• Do not design and implement for predicted future requirements, only design for what is needed now

Estimating tasks becomes much easier as the programmers gain experience, which then makes selecting which stories to implement a much simpler and more efficient problem. The programmer simply has to estimate each task that is assigned to him in terms of implementation time, without including design time. After completing the tasks, the programmer will then have a base for comparing new tasks so as to be able to more accurately predict their cost. Each iteration the estimate should become more accurate.

A program must be constantly tracked for progress in this categories: resources, scope, quality, and time. The quantity of resources committed is simply the number of developers, computers, on-site customers, etc. The best way to measure scope is by using a bar graph where the hight of the bar represents the total number of stories and the shading on the bar shows the number of completed stories. Each completed iteration should have a bar on the graph. Quality is tracked by graphs on unit test scores (which should always be 100%) and acceptance test scores. These can be further broken down by product area. Critically, the programming should be observed carefully because any trouble to the project will show up there first. They will become less playful and more stressed if the project begins to fall behind or become overloaded.

Opinion

Chapter 16 provided a succinct summary for the entire extreme programming ideology. The most interesting part of the recommendations is that requirements should not be frozen at the beginning. I know this to be true since I have seen first-hand what freezing the requirements leads to in a large project. It actually defeats the whole purpose of agile development if any new ideas cannot be implemented because they are not part of the original specification. It leads to an unsatisfying situation where both the programmers and the customer know that the project could have turned out better but was restricted by the original fixed plan.

 Dos and Don'ts