by Ron Jeffries, Ann Anderson, and Chet Hendrickson
In Chapter 16 of Extreme Programming Installed, the authors summarize a list of things that you should and should not do in the Extreme Programming methodology. Mainly, they focus on the issue of designing for the project. Design should not be done all at the beginning of the project; design should be done throughout the project. Requirements change, and as you start writing code you start to understand exactly what the customer meant and how you can implement that section. Everyone should be involved in design, and there should be lots of communication throughout the process. Instead of producing giant design documents at the beginning, layout diagrams, or freezing the requirements before coding is even started, design a little bit and update as you go. Usually if you try to do everything at the beginning, it will all change and become obsolete anyway. Don't waste your time if you're just going to throw it away. And always code for "today" only, not for "tomorrow." This means that you follow the customer's priorities exactly and don't try to generalize or expand the program to make it easier to add things later. It turns out that if you design simple and easy-to-understand code then adding things later will be very easy.
Chapter 17 focuses on the estimation of tasks, and how experience can help you with that estimation. When estimating tasks, you won't always be right at the beginning. Just give your first estimate and go with it. As you continue to program for that task, watch the amount of time that it takes to actually code the solution. Don't include time thinking, or planning, or drawing any diagrams. If you over or underestimate, learn from your mistakes so that you can better estimate tasks in the future. Once you learn to estimate the size of tasks accurately, it is really easy to decide that a new task is equal, half, or double the time of the last task that you completed.
In Chapter 18, the authors focus on how to track your programming, design, and project progress for the programmer, customer, and manager. In XP, it is important to track a number of different things: scope, which includes the number of stories total, in progress, and completed; quality, which concerns the number of tests that have succeeded on the code over time; and time, concerning the release schedule and iterations that have been completed. And nothing else needs to be tracked. The success of an XP project is measured in Resources, Scope, Quality, and Time. Another thing you need to do is watch your team closely and how they are acting. If they seem nervous, tense, and mad at each other, then there is a problem with something and this will give you a better indication of something going wrong before you will notice it in your tracking metrics.
I definitely agree with the do's and don'ts that the XP authors put forth. When you do all of your design at the very beginning, you don't really know all that the coding will entail. In my experience, you need to sit down and start writing code. Even if that code doesn't make it into the final product, you have a much better understanding of the steps required to finish the solution. Why write down a possible procedure for the programming and then later realize it's not feasible and you must find another way to do it? All you have done is wasted the time it took to write the requirements document. Instead, try a little bit of coding that will tell you if it's possible or not, and write the documentation once you're sure that you can do it that way. In this way, you still have the documentation to keep you on the right track but you're also sure that they way you wrote down is feasible.
No comments:
Post a Comment