Extreme Programming Installed
Jeffries, et al
Addison-Wesley Professional, 2000
Summary
Chapter 25, called How to Estimate Anything, primarily uses an example to explain how a large problem can be broken down into smaller parts, which are easier to estimate and implement. The work being done needs to be put in terms that the customer can understand so that they can maintain the direction of the project. The team must break up each large story into a number of smaller ones that focus more on implementation. These are what the programming team actually uses.
Chapter 26, entitled Infrastructure, discusses why the programming team should only design and implement for the features that are currently at hand, and not those that could be in the future. On a typical project, the programmers waist considerable time at the beginning writing infrastructure. The author suggests that this is waisted effort. The goal is to deliver business value, which is best accomplished by working on the problem at hand and not for potential future problems. Any absolutely necessary infrastructure work should be tied in to an existing story. If a story cannot be found that is suitable, the infrastructure probably is not necessary. Coding should focus on simplicity and be refactored out later if changes are needed.
Chapter 27 simply describes an example where someone took the blame for every problem, even though everyone know it was not actually his fault.
Opinion
There is too little material to actually form an opinion. All of this material is rehashed anyway, except for the Chet example, which was ridiculous.
No comments:
Post a Comment