Reference Information
Title: Extreme Programming Installed
Author: Ron Jeffries, Ann Anderson, Chet Hendrickson
Editor: Addison-Wesley Professional, October 2000
Summary
Chapter 19 discussed the idea of steering due to changing of changing priorities and estimates. The idea is to learn throughout the project, and adjust planning for the project accordingly. Adjustments should include reestimating similar stories to ones that are taking longer than planned, and rearranging and splitting stories to fit them into the time needed.
Chapter 20 discussed how to steer the iteration by tracking and improving estimates. Since the goal of an iteration is to complete stories, or to complete as many as possible within the time given, the team should track how the project is going, check progress against the estimates, and reallocate resources as needed to steer the project in the right direction. The purpose of steering is to get as many stories completed as possible, so to do this, a tracker is appointed to check every few days on the status of each story the programmers are working on. He identifies problem areas and gives the team a chance to deal with them. If the team cannot solve the problem, they go to the customer to solve it. This tracking gives the team the best chance to recover from a problem area.
Chapter 21 discussed how to steer the release by tracking what's done, how fast you're going, and how well the system works. At this level, you need to know when you're going to release and what you'll have done when you release. This is done by controlling the scope. By deciding what to do next and what to defer, by release time there can be a system that does what it needs to with the best features possible in the amount of time given.
 |
| A steering wheel, for steering. At least it applies more than the book's image of a steer. Source: http://www.r32argent.ca/ |
These chapters all seemed to be saying the same thing: Steer the project so it does what it needs to by the release time. Each chapter redefined steering, and presented some new ways to actually do it.The information probably could have been presented only once, but I did like the idea of tracking, as it seems like keeping track of progress so frequently would really help keep things under control. Especially since the chapter suggested ways to deal with problems discovered from tracking, recommending that the programmer present the issue to the team to be dealt with by everyone. I feel like it's a good way to solve the solution before ever having to alert the customer that there's something wrong. I think we should probably implement some sort of tracking system for our capstone project, as it would help us to stay on track from week to week and hopefully complete our production goals for the project.
No comments:
Post a Comment