Summary
Chapter 22 is Handling Defects. It looks at how defects can be scheduled in (add cards for defects and schedule it in being a very nice way of going about it), that defects tend to remove value from a product/customer. Defects also seem to cluster around points that are painful in one way or another, look into those with a fine tooth magnifying glass.
Chapter 23 is The Conclusion. Oddly, the book chooses to go on for another eleven chapters, but we'll roll with it. Conclusion starts by enumerating the twelve values of XP: On-Site Customer, Small Releases, Planning, Metaphor(?- bad XP folk using non descriptive names), Simple Design, Pair Programming, Collective Code Ownership, Continuous Integration, Coding Standard, Testing, Refactoring, and FOURTY HOUR WEEK. It's just a summarization of the preceding 22 chapters (110~ pages) into a bulleted list.
Chapter 24, "We'll Try", seems to be an overview of an idealized XP response to an impossible request. Basically, if you've broken down the numbers, looked into it, and feel confident in your estimates, you have all the power in the world to say to management "This ain't gonna happen, we can get part of it done, you decide which parts". It's kind of like a union without any supporting labor law.
Discussion
1. Why is this paper interesting or significant?
The idea of handling defects as a 'task', integrated into the schedule with features and other tasks is interesting to me, as traditionally I've seen them handled out-of-band, and I think that integration is a much nicer and more fluid way of handling them.
2. What are the faults of this work?
Meh. Seems alright.
3. What is the possible future work extending from this work?
Forcing management to decide between loved ones (features), like the evil person that I am.
No comments:
Post a Comment