Ron Jeffries, Ann Anderson, and Chet Hendrickson
These three chapters cover steering, steering the iteration, and steering the release. Steering is basically the idea of estimating actively. If you can tell that a particular story is going slow, look for similar stories and estimate them again based on what you learned from the story that was slowing you up. For steering in an iteration, you need to focus on getting tasks done. having 9 out of 10 tasks completely done is better than having 90% of ten tasks done. You don't want to get to your deadline without having anything completed. Steering allows you to move and adjust stories on the fly during an iteration so that things don't fall behind. It also might be useful to have a tracker. This person stays up to date with each story that a person has picked up and makes sure that it is staying on time or running behind. If it is late, he needs to find out why. The two main things to you will not at the release level is when you are going to be done and what you are going to have done when you get there. You should have a fairly good estimate by the time of release just exactly what your team can accomplish by then. This is due to the fact that your programmers should know how much they can accomplish each sprint.
Steering for the most part seems like something every good manager should do. They need to keep track of the pace of their employees and make it easier for them to get their work done. This is by no means just an extreme programming idea. If companies can't keep track of the pace of their projects, they are not going to be able to accurately estimate their completion. If they can't do that, then they are really susceptible to pushing back deadlines. By steering your project, you can almost guide it to a specific release date just because you are in tune with the flow of your project.
No comments:
Post a Comment