Reference Information
Title: Extreme Programming Installed
Author: Ron Jeffries, Ann Anderson, Chet Hendrickson
Editor: Addison-Wesley Professional, October 2000
Summary
Chapter 22 discussed how to handle defects. The point that the authors made was to never call defects bugs, since they were put there by programmers. The idea is to make it easy to report problems, and to schedule corrections into the iteration, keeping in mind that these things take time. Most importantly, the prevention of defects was discussed, including determining where previous defects originated.
 |
| It's not a bug, it's a defect. Source: allempires.com |
Chapter 24 discussed trying to reach an impossible deadline. Instead, the authors suggest creating a realistic deadline by knowing all the things that have to be done, having a solid feeling for each of them, and knowing how many real days it takes to get a perfect engineering day. Using user stories and project velocity, a realistic estimate can be created. They suggest that these real estimates should be told to management, and that programmers should stand up for themselves against managers.
Discussion
First of all, I found it interesting that we read the conclusion chapter, and almost half of the book is still left to go. Basically, these chapters said that defects are bad and that programmers are afraid to give real estimates to their managers. Both of these statements are fairly obvious, and didn't really need entire chapters to explain. In particular, the advice to keep insisting to managers that their estimates are wrong and that your very long-term estimates are the ones that should be followed seem like it could easily put you in a bad position, as in out of a job. However, the idea of handling defects and bugs as soon as they occur, and factoring them into the schedule seems like good advice that we should probably follow in the future.
No comments:
Post a Comment