Planning Extreme Programming

Skepticism about new techniques is a natural state for programmers and those who manage them. Hype amid the desperate search for effective strategies is one of the many factors contributing to the poor rate of success in the business. Extreme programming, where development is broken up into a series of microcycles performed by small teams, is an apparent step backwards in the evolution of the planning of software projects. I was initially very skeptical about it, for the primary reason that not all things can be broken up into executable cycles of approximately two weeks in length. However, this book, packed with some of the most sensible advice you can find, sold me on the concept, if not the implementation. The approach is an admirable one, let the customer decide. If the project and customers are worth having, then there will be more features than can be implemented in the allotted time. Since slipping the release date is NOT considered an option, it is the responsibility of the customer to choose what is to be delayed or eliminated. A synergy between developers, marketers, and customers where all work together and know where they stand is certainly a desirable goal. The reason for my skepticism is that in my experience, the customers are not as cognizant of their priorities as those ideals used in the book. However, the advice given here will help you approach this ideal state of affairs. The tactic is to refer to all features and descriptions as stories. I am generally not one who is fond of someone taking semantic license in describing circumstances. However, in this case, it does fit. The description of software is very much like a story in that your ideal is a fiction that may never be achieved. Since you are not sure exactly what you have created, the documentation is somewhat exaggerated and the end result is unknown until it happens. In a brilliant use of terminology, the authors use ideal time in planning rather than real time, and this is something that all programmers will enthusiastically applaud. Ideal time is that amount of time actually spent in working on the project as opposed to that spent in distractions. When it comes time for projecting completion dates, the developers then use ideal time rather than the false alternative. This is the most sensible strategy that could ever be used and if any one idea in this book is adopted, this should be it. Another simple and very effective strategy is the yesterday's weather approach to predicting future performance. The analogy is simple. Enormous amounts of money can be spent on hardware and sophisticated computer models in an attempt to predict what the weather will be like tomorrow. However, you can be almost as accurate if you simply say that it will be much like today. Taking the same approach to development, you can say that the rate of development achieved by each programmer on the next project will be very similar to what they did on the last project. You may not be ex

Planning XP is well-written, just like Robert's Uml Distilled and Refactoring. Reading it was as easy as reading a child's story book. Of course, the content of it are serious, for developers, customers as well as project managers.This book talks in details the planning and requirement gathering part in XP process. The order of reading the three books would be XP Explained, XP Installed followed by Planning XP. One shortcoming of the book IMHO would be that the example on the travel booking system should be elaborated on. We all learn from examples and it would be great if the content of the book is develop around this example to give a better understanding of the subject. Even so, this book is great in explaining about subject, simply because it's practical. It tells you how to go about doing it and not what you should do. Do not refuse to read it just because you do not believes in XP. XP books are always littered with good tips which are applicable even if you are using other processes. Comparing prices, this book is rather expensive, considering that I can get the GoF book one dollar cheaper here in my country. The GoF book is thicker and comes with hard covers.Even though it is expensive, I would still recommend it, as I feel that this should be a book that everyone in a project team should own. Rush to your nearest bookstore now!

Kent Beck and Martin Fowler wrote an excellent book about the planing process for Extreme Programming (XP). Although it helps to have read Kent Beck's 'Extreme Programming Explained', I found the book useful even without knowing too much about XP beforehand. The book is easy to read (more like a story then a scientific book) and well structured. Beck and Fowler also let the reader focused on the importent issues and did not try to discuss every possible sub-case (which they could have done very easily to blow up the size of the book). Knowing Addision-Wesley quality books, I was a little disappointed about the way the book was put together. E.g. 'Velocity' is defined (using bold letters) on page 43, but that page is not mentioned in the index.