Rating: 
Summary: Great methodology, book should be shorter and clearer
Review: I'm an XP believer, no doubt about that. And, it's hard to be the one who says something negative in the context of all the positive hype surrounding XP and this book in particular. But, I have to say it: for a methodology that's all about simplicity, this book describing it is vague, chatty, and downright weak in many spots.The book does not exactly teach you how to do XP. Mostly, it gives you a meandering, blurry outline of XP, throws in an inadequate number of facts and tasks, and fills in the rest with a folksy, down home chattiness about how to approach software engineering. This chattiness can be entertaining at times, but more often it ranges from silly to grating. It gets particularly grating when you realize that you are spending your time reading someone's idea of humor/advice instead of real facts on how to do XP. It starts to bug you after awhile that these people tell you to strive for simplicity and "saying what you mean" in your code, but fail to do the same thing in their book. Some key facts that are either vague or missing in this book are: what is the relationship between the "points" for tasks in iterations versus the "points" for stories in releases? Is a point really a week or not? How many iterations should one fit into a release (they say about 2-3, but this really needs more discussion)? Acceptance tests, acknowledged by the authors to be a crucial part of XP, get almost no attention or description at all. There is no brief outline that shows how an XP project should run, from beginning to end. The annoying prose really comes to a head when talking about the aforementioned "points" system, which seems to be the heart of XP planning and estimation. Not only are the authors unclear about "points" in the way I mentioned above, but just look at the place where they introduce the concept: "We'll estimate story difficulty, using a simple point system. Local naming rules for these points apply. Some teams call them perfect engineering weeks . . . Some projects call them Gummi Bears. No, really . . . Ron's favorite name, this week, is just to call them points. You'll see in a bit that we recommend doing initial estimates by thinking in terms of time. Pass over that for now . . . " Here we get all the shortcomings of the book wrapped up into one: lack of clarity, a cavalier attitude toward important concepts, and annoying humor. How are we supposed to sell the customer or manager on a controversial new methodology, when the key book describing the methodology casually tells you that you can measure the most important metric of the process with "Gummi Bears", if you'd like? Rest assured that despite what the authors say above, the book never really goes on to elucidate the relationship between points and time. Or, maybe it does, but I lost it in the midst of all the meandering, jokes, and folksy phrases. Finally, there are a couple of chapters that just do not bear reading: Chapter 7, "Small Releases," is full of a lot of obvious common sense; and Chapter 14, "Test First, by Intention" - what should be a crucial illustration of unit testing - is unreadable to anyone who doesn't know Smalltalk, despite the authors' reassurances to the contrary. XP is a great methodology, but this is not a great XP book. It could easily have been half as long and twice as informative. I guess I need to look elsewhere in the rapidly growing XP book "franchise" for a clear, no-BS illustration of the process.
Rating: 
Summary: If you read only one book on XP, this should be it.
Review: I've read several of the original XP books (Explained & Planning) and to me this is the one that best explains XP and how to implement it. This book was a revolution for me, and I haven't looked at software development in the same way since I read it. It's hard to convert a company (especially managers) to XP, even at a new company on a new project. Managers typically want developers to agree to schedules based on business goals. XP will show you how to do this, but XP won't let you do the impossible. There are tradeoffs, functionality for time. Less time equals less functionality. Sometimes managers just don't understand this (they want it all and they want it now). In that case, it's best to find a new job! But if you are able to apply the XP method, you will love your work, your customer and manager will be happy, and software development will be a pleasant and enjoyable experience. A final note, I've read this book twice and several sections probably over a dozen times. It can be a little skimpy on details and examples in a few places. I've recently glanced through the new XP books and they give examples and fill in details, but they're expensive and you'd have to spend hundreds of dollars to buy them all and get all the details! Instead look to the web. There's an XP newsgroup (search for it with Google). This book won't take you 100% but it will get you close enough to make it the rest of the way. And of course if you can afford to buy XP Explained and Planning XP I think they're worth it.
Rating:
Summary: If you read only one book on XP, this should be it.
Review: I've read several of the original XP books (Explained & Planning) and to me this is the one that best explains XP and how to implement it. This book was a revolution for me, and I haven't looked at software development in the same way since I read it. It's hard to convert a company (especially managers) to XP, even at a new company on a new project. Managers typically want developers to agree to schedules based on business goals. XP will show you how to do this, but XP won't let you do the impossible. There are tradeoffs, functionality for time. Less time equals less functionality. Sometimes managers just don't understand this (they want it all and they want it now). In that case, it's best to find a new job! But if you are able to apply the XP method, you will love your work, your customer and manager will be happy, and software development will be a pleasant and enjoyable experience. A final note, I've read this book twice and several sections probably over a dozen times. It can be a little skimpy on details and examples in a few places. I've recently glanced through the new XP books and they give examples and fill in details, but they're expensive and you'd have to spend hundreds of dollars to buy them all and get all the details! Instead look to the web. There's an XP newsgroup (search for it with Google). This book won't take you 100% but it will get you close enough to make it the rest of the way. And of course if you can afford to buy XP Explained and Planning XP I think they're worth it.
Rating:
Summary: It's great to see that XP is actually being implemented
Review: I've seen people speaking about it and know of small projects trying it out, but now that Chet Hendrickson and Martin Fowler are working for the same company, I hope to see many more books on really impressive success stories. I am telling my managers to read this book!
Rating: 
Summary: Maybe the best of the series
Review: Much better than XP Planned. Its decent but a little expensive relative too its small size. It explores XP more deeply that XP explained.
Rating:
Summary: Achieveable programming utopia is described
Review: Once the theory has been assimilated, it comes time to execute. From the theoretical side, Extreme Programming(XP) is intuitively obvious. However, as we all know, theory and practice sometimes have only a passing acquaintance. Implementing and maintaining the principles of XP requires many traits, some of which are all to rare.
Since XP does not allow for the slipping of a deadline, it is sometimes necessary for someone to summon up a good deal of courage. It may be necessary to go to a supervisor and lay the cards on the table and say you can't have it all. Since those cards would contain a list of the requested features, this is guaranteed to make you unpopular. If that supervisor is one whose idea of motivation is to raise the level of fear and hours of uncompensated overtime, then it could be your last act at that company. That possibility is the one area where I have concerns about this book and XP in general. To implement it requires the commitment of all persons in the chain of command. If at any point someone at one level gives up the faith, then it is hard to see how it can be recovered.
This book is a story of how XP looks when it is being used as described. Although somewhat idealistic in its premise of forty hour weeks, limited overtime and keeping the goals within reach, there is no doubt that as described here, it does work. In fact, to most programmers, it sounds like the ideal work environment. For some time, I have pondered the choice of the word extreme to describe this mode of programming. After reading this book, I now understand why it is applicable. Using the XP method to build software requires extreme commitment from all parties to the endeavor. From the customer to the programmers up to the highest levels of management, everyone must believe in it.
In the end, XP will rise or fall based on the performance of those who adopt it. If they create programs cheaper, better and with more features, then it will be adopted. If not, then we will see a return to the locked in the cubicle mentality. However, it must be implemented in its entirety to be properly tested, and this book will show you how to do that.
Rating:
Summary: Practical Simplicity, Communication, Feedback & Courage
Review: People are starting to take XP very seriously simply because it delivers quality code instead of just documents about code. The core philosophy can be summed up: "A feature does not exist unless there is a test for it." (P.83) This means that coders (pairs of programmers in XP) first construct unit tests of product features before the attempt to code the features. What this means in practice, is that the code that XP delivers (continuously in 3 week long iterations) can never be broken! I'll say that again just to make sure you read it: XP code can never be broken! I really think XP's adaptive, test-first philosophy is the best thing that has happened to software engineering since Dijkstra told us that the "Goto Statement is Considered Harmful" in 1968. This book is the best of the XP series if you've actually made the decision to use XP. If you're not sure about what XP is or what it's limitations are, go to google and do your homework. When you're ready to actually install an XP project, get this book.
Rating:
Summary: Practical Simplicity, Communication, Feedback & Courage
Review: People are starting to take XP very seriously simply because it delivers quality code instead of just documents about code. The core philosophy can be summed up: "A feature does not exist unless there is a test for it." (P.83) This means that coders (pairs of programmers in XP) first construct unit tests of product features before the attempt to code the features. What this means in practice, is that the code that XP delivers (continuously in 3 week long iterations) can never be broken! I'll say that again just to make sure you read it: XP code can never be broken! I really think XP's adaptive, test-first philosophy is the best thing that has happened to software engineering since Dijkstra told us that the "Goto Statement is Considered Harmful" in 1968. This book is the best of the XP series if you've actually made the decision to use XP. If you're not sure about what XP is or what it's limitations are, go to google and do your homework. When you're ready to actually install an XP project, get this book.
Rating:
Summary: Best of the XP series, but still wordy
Review: The books in the series have a lot of whitespace and are chatty andrehashes of each other and this cuts down on the amount of information they impart. Contrast that with Steve McConnells books. This is the best book of the series with some great ideas. They addressed many of the software engineering concerns I had.
Rating:
Summary: good for medium-size teams
Review: The concepts in this book are very simple. The testing and integration technique alone is more valuable than all the management and testing theory together that I have read so far! BUT... DO NOT (I repeat, DO NOT) read this book before you read its predecessor, Extreme Programming Explained! You WILL NOT understand key points, otherwise. As in the other book. you must implement all of this technique or none of it -- with the exception of testing and integration. The theory is exceedingly simple, but you must have stick-to-it-iveness (otherwise known as self-discipline) to make it work. Although I have not proven this, I believe that the testing and integration technique will work with any size group, including one-man teams. The rest is optimized for medium-size teams, and NOT extremely large (definitely not extremely small) teams.
| 
