Book review: Extreme programming Explained

Extreme programming Explained
Embrace change 2nd Edition
Written Kent Beck with Cynthia Andrea & Forewords by Eric Gamma
ISBN-13: 978-0-321-27865-4

My opinion... 6/10. I like & follow some XP practices since at least 6 years at work and in my homework.....But, let's get started with more details about the book, i hope it help you deciding if you would read it or not!

The author presents XP in 3 steps. First he presents XP's values. This part looks very long but they are the reason why XP is. And Values & Principles are notions that you can take in your bag for your own lifestyle improvement! Too much psychological to me (but maybe it can push for change like a hidden message)

Communication,Simplicity,Feedback,Courage,Respect are basic XP values.

Chapter about Principles was quick & full of interest. They are: Humanity, Economics, Mutual Benefit, Self-Similarity, Improvement, Diversity, Reflection, Flow, Opportunity, Redundancy, Failure, Quality, Baby Steps and Accepted Responsibility. In fact they are just global notions to give a better view of what the practices are intended to accomplish.

I read the chapter about Practices really easily. Author describes team & resources organization, "Sit together" or in other words build a comfortable open space while maintaining place for personal space,

install place for project informations (to quickly see how projects goes).

About "pair programming", it give some advice that we could follow. In my own experience of "pairing", i was a bit frustrated at the end of day. I felt i should have make much more. But after, reading i think i could plan more dev in pair!

Stories definition is also really good. And it was follow by cycles definition. The "quick iteration" and the "quarterly cycle". Priority management of user stories and how put in place a slack of task that the team can made (refactoring, optimization, design, research on a future topic) without interfering with new features development.

Ten-minute build is something we should work. The quicker you have feedback, the quicker you can change or fix! Continuous integration, Test-First are also something i use but being more Extreme could help!

Incremental Design is the last but not the least as XP is about change. It explain why we try to start with a basic & simple design and every time we need, we improve it based on experience & feedback.

The corollary practices are: customer involvement, incremental deployment, Team continuity, Shrinking teams, root cause analysis, shared code, code & test, single code base, daily deployment.

A chapter talk about roles in XP team.But in the end of this book the 2 most interesting chapters from my developer point of view are 13 and 14. Chapter 13 talk of testing (first, early and often) of test automation 

I think that deploy a beta version at the end of each iteration or at least at the end each important user story implementation to use & demonstrate, is a target i should keep in my mind.

And 14 is about design (it's funny as we are talking about design at work those last days...). The author recall that design for design is not a good thing and that perfection is not in this world. Even if you start with 2 weeks of design, you will have to rework it a some point because of change. So use basic principles, KISS, DRY, but don't procrastinate yourself when, based on experience, feedback and need, you have to modify the design!

I had a look for the remaining chapter but they are more for manager, describing how XP can scale when team or organization grows, how measure XP usage and effectiveness.