Extreme Programming Installed, Chapters 7-9

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


Summary
Chapter seven emphasizes the need to have a short release cycle to get functioning iterations to the customer for real-world use as often as possible, even if the functionality provided is just a subset of the final features list. These short releases allow for quick feedback and for the customer to change their mind or refine their vision so that the programming team can improve and deliver software that more meets the customer's needs. This in turn leads to more useful software, which increases business value. The authors propose that on many complicated systems that are intended to replace an older functioning system, the replacement can take place over time in a piecemeal fashion. This can be done by implementing the new GUI first and tying it into the older system and by delivering functionality in the form of discrete programs that can interact effectively with the older system.


The eighth chapter discusses how the customer goes about defining what makes it into each release. At the basic level, each release is comprised of one or more iterations, each implementing many stories. Therefore, someone must decide which stories to implement in each iteration so that the business value of the upcoming release can be maximized. The process involved with feature selection is done by the customer and consists of three phases: exploration, commitment, and steering. In the exploration phase, the customer writes out the stories that he thinks will increase business value the greatest and the programmers dabble with how to implement these ideas. During commitment the programmers are given these stories and estimate the amount of work required for each, while the customer fields questions and breaks up stories into smaller ones if necessary. The cost assigned to each story is a point value; the team can estimate their work rate in points then, as they become more experienced, they can provide a solid number for the amount of points that can be done per week (called project velocity). Finally, in the steering phase the customer picks which stories to implement based on business value and current velocity.


The ninth chapter concerns iteration planning, which is the process of taking the already decided-on stories and having the programming team break them up into engineering tasks and then having each programmer sign up for work to do. As stated above, each release is only a couple of weeks apart so the tasks need to be broken down small enough to be accomplished in these sort of time-frames. Each team member is expected to understand each story presented and to participate in the brainstorming of engineering tasks. This is the idea of collective ownership, where any programmer has the ability to step in and work on any part of the system. However, it is still optimal for one programmer to take responsibility for all the tasks that make up a story to ensure that it is implemented efficiently.


Opinion
These three chapters were only elaborations on the processes already outlined in the previous chapters. The only interesting part was how the programmers were allowed to choose their own assignments, and to share them with others if need be. Again, I have concerns that the programming team will almost certainly over-estimate their abilities and lead to conflict with the customer over the amount of work being done.

The iterative process