Most Helpful Customer Reviews
|
|
18 of 18 people found the following review helpful:
5.0 out of 5 stars
The most practical book among all the XP books, December 26, 2002
This is the most practical book among all the XP books ever published. You do only need to read Kent Beck's XP manifesto "Extreme Programming Explaining" before studying this book. Then you may skip all other books from the "Extreme Programming Series" and start to interpret written material about individual XP practices:- Design Improvement: " Refactoring: Improving the Design of Existing Code " by Martin Fowler;
- Test-Driven Development: "Test Driven Development: By Example " by Kent Beck;
- Sustainable Pace: "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency" by Tom DeMarco;
- Pair Programming: "Pair Programming Illuminated" by Laurie Williams and Robert Kessler;
- Whole Team: "Agile Software Development" by Alistair Cockburn;
- Planning Game: "Planning Extreme Programming" by Kent Beck, Martin Fowler;
- Small Releases: "Software Project Survival Guide" by Steve C McConnell. This book covers most of the XP practices at a glance, but with sufficient level of details. It tells in practice: - How to introduce XP, how to overcome managers' and developers' resistance, how to set the right attitude (Part One);
- How to remember XP core values, how to handle exceptions if something has broken, e.g. the customer won't write stories or the number of developers is odd, how to do pair programming or stand-up meetings, how to steer and how to plan the whole project and the individual iterations, how to write tests, to create the pair-friendly space, how to refactor, and how to reduce the risk (Part Two);
- How do design the simple, what collective ownership means, how to automate acceptance tests and not get distracted by the code, why the overtime is not the answer and how to coach and keep the score (Part Three);
-How to "sell XP" (commercial aspects of XP projects, e.g. how to bill the customer), how to "scale XP", and how to "measure XP" (Part Four). Enough said, this is the most practical book among all the XP books ever published.
|
|
|
21 of 22 people found the following review helpful:
5.0 out of 5 stars
You have to read this book if you're serious about XP!, May 20, 2002
This is the first in-depth book on Extreme Programming (XP). If you are at home with the concepts of XP, but have lots of questions that you feel the XP literature doesn't answer -- this is the book for you! I myself have been into XP for little over two years, and I can't think of any questions I've had, that aren't addressed thoroughly by this bookThe book is focused on introducing XP, dealing with things like how to tackle resistance from developers and managers; which XP practices should be implemented first; what factors are important in order to successfully implement XP, and so on. The authors list six of the XP practices as "the bare essentials". Not that the other practices are unimportant, but they can wait until the first six are in place. The six are: Planning Game, Small Releases, Testing (unit testing only; acceptance testing can be addressed later), Pair Programming, Refactoring and Continuous Integration. These six practices are very thoroughly described, dealing with the how and why a practice works, how to start doing it, and so on. As for the remaining practices, they also explain why each practice can wait until the first six are in place. I tried to read this book with a critical mindset, so I kept notes of things I thought they failed to address properly -- only to find that they returned to them later in the book, forcing me to cross out items on my list. What was left on my list were only minor details, except one item: I would have liked them to deal with the System Metaphor as exhaustively as the rest of the practices. Just as "XP Explained" by Kent Beck and "XP Installed" by Ron Jeffries, et al, this book basically says that, well, it is good if you can come up with a metaphor, but if you can't, that's not too big a deal. In these books, the topic of the metaphor and how it relates to the concept of architecture, is given only a few pages (2.5 pages in XP Applied). This is a pity, because I feel that it is an important issue. (I suggest reading "XP Explored" by William Wake, which has two very good chapters on this.) If you only intend to buy one book about XP, I would recommend this book over "Extreme Programming Explained: Embrace Change" by Kent Beck (which is the XP manifesto). This is not to say that "XP Explained" is a bad book, though -- I nominate that book to be one of the most important software development books, ever. But if your aim is to learn as much about XP as possible, this book is in a league of its own. If you can afford more than one book, I would suggest starting with either "Extreme Programming Installed" by Ron Jeffries, Ann Anderson and Chet Hendrickson, or "Extreme Programming Explored" by William C. Wake. I think that one of these books is a good start, since they both are very practically oriented. After reading one of them, I think it's a good time to read "XP Explained", which very elegantly describes the philosophy behind XP. Finish off with "XP Applied" to get answers to all your questions. I bet that you'll have a very solid understanding of XP by then.
|
|
|
19 of 20 people found the following review helpful:
4.0 out of 5 stars
One of the best in the series, albeit rehashed, March 7, 2002
Right up front, I have to say that this review suffers from a bit of XP fatigue. Addison-Wesley has published a series of books on Extreme Programming (XP) and I have read them all. The reason for the fatigue is that there just does not seem to be all that much new in this book that has not been covered in the previous ones. It starts with a description of XP, the values of pair programming, the "restricted" forty hour week, relentless unit testing and so forth. This is followed by a set of scenarios about how to deal with objections to XP from developers to management. Once again, this is not all that much different from what is in previous books.
This is not to say that the book is poorly written or without value. The description of XP is well done and easy to follow. I have no doubt that XP is a methodology that works well in small projects. The set of tactics used in XP are those that developers have used for years, with the most important being the second set of eyes and brain constantly examining the code. Every developer has experienced many of those incredible moments where hours of fruitless debugging are suddenly rendered moot when another looks at the code and in less than a minute finds the problem. I am also now convinced that XP will work on big projects as well, but with one enormous proviso.
If, and this is a very large and difficult qualification, the big project is properly parsed into small sections, then XP will work. The problem is of course effectively reducing the problem into one where the pieces are small enough to be handled by XP. That has always proven to be the biggest problem in software development, and there is no reason to think that it will change in the future. Chapter 29 is devoted to this problem, with some progress, but the book would have been more valuable if there had been more treatment of this topic. It is less than ten pages, and comes across as little more than a statement that few things really scale well and XP scales as well as the others. Certainly not a convincing argument in favor of conversion to XP.
I believe that this was the fifth book in the A-W XP series that I have read. As I pounded through the pages, it was difficult to continue as there was so little that has not appeared in a previous issue. Therefore, my final advice is to read this book if you have not read one of the others in the series. If you have already read another, then skipping this one will not be a great loss.
|
|
|
Most Recent Customer Reviews
|
