Rating: 
Summary: Well, duh !
Review: To summarize :A lot can be accomplished with a small hand-picked group of people who are emotionally stable, secure, honest, and communicate well who have a nice work environment, lots of feedback, and a diligent but benevolent boss. Well, "duh!" Under those conditions *anything* would work. The author pretty explicitly rules out most real life situations at the end of the book. If these principles of XP are a revelation to a manager, that manager is so far in the hole that they'd better stick with traditional management structures before they do real damage. Consultants can look for business restoring traditional structure to many groups in 2002 .....
Rating: 
Summary: Your Next Job Interview Will Ask About Your XP Experience.
Review: There are four books about eXtreme Programming, and this one was the first. If you still believe in paper books, buy it, but paper books are not really an eXtreme form of documentation, are they? You can learn a lot - and chat with the author -...which is also the world's first Wiki website, so get the book by Cunningham and Leuf at the same time...
Rating: 
Summary: The best of the serie for a good explanation of XP
Review: If you want to know what XP is, and the philosophy behind XP, then this book is the best of the collection. It is very well written, concise and easy to read.
Rating:
Summary: anecdotal and sometimes silly
Review: XP has some good ideas, but this book could have been reduced to a paper by removing some of the silliness and the many anecdotes.
Rating:
Summary: Best Commercial Practices
Review: What do you want me to say? This book is but one of a series. It is not a panacea for all your ills. It only talks about developing quality software when you're under the gun. My colleagues agree that these guys put together the best commerical practices of the past 20 years into one adaptive methodology. The cool thing about this is that you don't have to impliment the thing en todo to get the results you want. Find what you like and start there. Overall I found this book a delightful read. The chapters are short, like XP's iteration cycle. Short is sweet when you're an over-worked programmer like me. At first I was underwhelmed by this approach, but it works! The annotated bibliography in the back of this book (and others in this series) helps understand the author better and give you context. This book offers practical advice.
Rating:
Summary: Excellent , a quick read
Review: Excellent book for software developers and managers alike. This short but insightful book can be read in a couple sittings. The simple, practical ideas can be put into use immediately. Order it without hesitation.
Rating:
Summary: A great overview of a true software engineering approach
Review: I believe that XP is one of the most important breakthroughs in quality-focused development in the past decade. It is a language-independent approach that embodies what is best in software engineering, project planning and control, and attention to quality. This book is a fast overview of XP and should be required reading for any development manager who wants to get control of cost, schedule and quality. Despite its small page count, it covers all of the key points and will demonstrate to those who are put off by the name, "Extreme Programming", that this is a viable approach. As I read through this book I saw a lot of parallels in the author's description of XP to some of the best practices and key process areas of the capability maturity model. I was especially surprised at how close XP is to Watts Humphrey's personal and team software processes. These similarities show that XP is a serious software engineering approach and a good fit into companies that have invested in improving their capabilities through attainment of the higher CMM levels, software engineering process groups, etc. Indeed, the metrics that are collected and used by XP practitioners will feed valuable data into an SQA group for transformation into meaningful data for process and quality improvement. Don't let the title "Extreme Programming" or the short page count of this book deter you from taking it seriously. Mr. Beck clearly describes XP and amply proves its value in this brief survey. If you want to see just how serious XP as a software engineering and project management discipline, read this book, then get a copy of Watts Humphrey's A Discipline for Software Engineering. I give this book 5 stars and my highest recommendation.
Rating:
Summary: Simple and elegant introduction to a fast paced methodology.
Review: Extreme Programming (XP) is an interesting concept-- I haven't decided if it's completely feasible or not, but it certainly is interested. Beck outlines his methodology in a very simple and elegant manner. The book is light-reading,b ut never childish. XP promotes several worthwhile concepts-- collective owenership (if you find a problem, you fix it, you don't find the owner of the problem), authomated unit testing (write tests once, run them everytime you make a change), heavy communication, and severe flexibility. The element that most people bite on beyond this is pair programming-- two programmers side by side working on one problem. Another reviewer felt that programming requires a certain depth of concentration to perform, and that a second body could be deterimental to this. I tend to disagree, but I also have a very light-weight, on-the-fly style in my software development style. But then again, I'm a jazz musician writing code, so that only makes sense. :) Even if you don't embrace all of it (and I'm still not convinced on some issues, like pair programming), it's a worthwhile read for the unit testing bits alone.
Rating:
Summary: Do it to the extreme!
Review: Kent Beck has put down the outline for a software development methodology that we heuristically employ in tight situations. While I read this book for the first time, I was going "Hey! I do this all the time!.. He has succeeded in putting a name tag on my hunch." almost in every chapter. The word "extreme" turns off most managers, so you have to feed 'em the information using force if necessary. >:-=[ The "extreme" is actually very reasonable: if it's good, go to the extremes to do it, if it's not, go to the extremes to avoid it; eg., if code reviews are good: do it all the time. Some ideas can be overdone, though, watch your waist line when you keep food around the project site ;-). (I am still trying to loose the extra 20kg (~40pounds) gained during my first XP project) Some of the ideas are not easy to live with for the "more organized". Most managers I know would wake up a couple of times a night in sweat if they were working on a software without their long-term plan (some previous commenter declared some of the ideas downright dangerous). All clients think they are cheated out of a professional effort to get their software done when you do not a supply a detailed long-term plan for the completion of the project. That, you have to put up with until your first XP project finishes.
Rating: 
Summary: A Not Fully Thought Out Developmental Methodology
Review: This book is an easy read and does have some good ideas such as: having a dedicated tester for each XP team, and writing tests. However, I felt that the author's main assumptions such as flattening out the change curve and ideas such as refactoring and allowing for changing requirements throughout the life of a project were both unsupported and even dangerous. The author, Kent Beck, conflicts himself several times on the issue of the flattened curve. In the beginning of the book he states that using Object Oriented Design and programming code in a flexible manner will allow for requirements to change without an exponential time increase in reprogramming/refactoring. Later, in his book, he states that the programmer should write simple code for simple, short specific requirements and nothing further, in short, not account for future change or flexibility. This avoidance of flexibility blows his argument of a flattened curve away. Any programmer or manager who has survived a major project knows that changing requirements, especially near the end of a project, means lost time, perhaps even severe lost time due to redesigning...etc. In addition, daily refactoring, as supported by the author also means that code is constantly being rewritten, again causing lost time. A manager cannot allow for such inefficiencies when deadlines have to be met. In my view, if code is properly designed first, taking into account the full requirements of the task, refactoring should be unneccessary. Beck strongly supports pair programming, but fails to understand that programming requires deep concentration and is not best done with someone staring over one's shoulder or talking in one's ear. In my view, pair programming can be replaced by creating a team atmosphere and encouraging or even requiring programmers to share their designs before writing code so that other programmers can offer input for improvement. Finally, Beck does not support programmer documentation. This is a huge blunder. Any programmer who has faced the task of maintaining undocumented code knows that documentation is a must. Overall this book left me wondering if the author really understood programming or had actually headed up any successful projects. To me, the idea of Extreme Programming as explained by this author presents a methodology which is both inefficient and insufficient. A better book for software development and management is 'The Dynamics of Software Development' written by Jim McCarthy.
| 
