Ron Jefferies, Ann Anderson, Chet Hendrickson
Addison-Wesley
Chapters 22-24:
In these chapters we effectively finish the book, only do find that there are extra bonus chapters that are simply supplements to the important foundations of the book. However before the book ends we do find out about one taboo in extreme programming and that is the idea of defects...or is it bugs....nope we are not allowed to say bugs! In fact the chapter stresses that we need to not call defects in our code bugs one because of the implication that it is a problem that is going to be persistent and two because it honestly scares the customers and we don't want to do that. There are many ways to handle these and of course the foremost among them is making tests for everything and making sure your tests work before adding your code to the program. Ironically enough this is where a lot of the major bu...I mean defects happen is in testing. However this is not to say that one should not test because testing is very important but you need to make sure to handle defects as they come and stay on top of them. The most important practice in extreme programming is having a plan and sticking to it and if you deviate from the plan there are multiple redundant checks to get you back on course. The conclusion of the book are actual testimonies of companies and groups who have used extreme programming and how much more they really enjoy it than their standard practices. Some groups have found a whole new way to run their business and deliver code thanks to extreme programming. They put a lot of emphasis and really reading the text and essentially making sure you follow the 8 basics of the system:
-On site Customers
-Small Releases
-Planning Based on Stories
-Programming Based on Metaphor
-Pair Programming
-Continuous Integration
-Testing
-Forty Hour Work Week
Keeping these and some other details in mind makes sure that the system effecitvely works and make sure that your team is going to get done what it needs to get done. Finally the last part of these chapters is a suppliment talking about stories and keeping to a track called "We'll try" it is the idea that every programmer has spoken these words and in some cases it can mean the end of the program before it even starts. In fact most people will give up on a program when they think that there is a task that they cannot estimate and this ultimately causes the program to fail. This is not the case and in fact some of these things really are as easy to implement as they make them sound like in the book. Sometimes it may be hard to get a start on them but ultimately they are fairly simple and they just need to be followed and practiced.
I think these chapters in the books were almost eye opening in that people think these kinds of things are rather difficult to do when really they are quite simple. I think the most interesting part of this was when they actually had testimonials of different groups talking about how they were able to implement these kinds of things and it completely turned their business around. Even more interesting was the supplement that was added where they covered the same ideas of making user stories and really fleshing them out and then estimating them and telling people that you shouldn't just try these you need to commit to them and really do them. It does seem that at time a new system can be daunting but after reading this book and really trying to understand what theses kinds of different methods do and what these techniques promote in a group I really cannot see doing a system any differently. It seems that all the system does is simply drive forward the idea of writing good code and making sure you deliver it on time and essentially isn't that what any programming company wants to do? I really think this is a very good system and some of these supplements seem like they are going to answer my questions about what kinds of techniques are used in estimating and how pair programming can really help productivity.
No comments:
Post a Comment