Refactoring Extreme Programming: XP Practice and Reflection

Author: (British) Stephen (Stephens/M.) / (American) Rosenberg (Rosenberg/D.) / Wang Feng / Zhao Hao et al.
Publisher:
Publish Date: 2005-06-01
Features: Breaks the myths of Extreme Programming (XP) and reveals its other side; Conducts a thorough and systematic analysis of XP practices, distinguishing between agility and vulnerability; Proposes better methods that are more broadly applicable and still achieve XP's agile goals.
Dear Readers: We firmly believe that the dazzling halo surrounding Extreme Programming (XP) in recent years is shrouded in thick fog, and there are some very obvious weaknesses in this popular development process. The main challenge faced by teams introducing XP into their organizations is that XP requires a significant mindset shift, from team construction methods to how companies interact with clients. One of the key contents of this book is the refactoring process we recommend, which absorbs the essence of XP while eliminating its extremism. This approach to achieving agile goals only requires minor changes to the existing organization but still maintains XP's agile objectives. We have also discovered some very interesting aspects of XP, so we try to view some of its quirky and humorous suggestions with a positive attitude.
Before we begin, we would like to draw the readers' attention to some very unique elements of this book. It is not an ordinary, general computer science book! We feel that such a topic is suitable for a satirical approach, so we have decided to give it this style. Apart from satire, there are also many elements of dry humor. At times, we do become serious and conduct a rigorous systematic analysis of the inherent flaws and dangers of Extreme Programming (XP). In this regard, this book is not entirely a "critique" of XP. As mentioned later, not all XP is bad. We aim to provide a balanced critique and identify parts of XP that can be salvaged or refactored to achieve the same agile goals in a more robust way.
XP has been subjected to undeserved hype, and new XP books continue to be published at an incredible pace. The excessive enthusiasm surrounding XP has influenced the industry from all sides (some positively, as we seek, but mostly negatively). Given this, we believe it is important to have a book that goes against the XP tide and resists it. Here is a small example of how XP has affected the industry. Matt (the courageous co-author of this book) received an email from a consultant who had recently lost an important contract because he refused to start a project without first conducting some detailed requirements analysis and preliminary design. The client, who had heard about XP programming, told the consultant: "Since XP thinks it's fine to start a project that way, we will find someone to skip requirements and preliminary design and start the project directly!"
While some business professionals, upon hearing about XP, immediately become (as the consultant's story suggests), there are still some who remain steadfast and refuse to change. In reality, one of the main challenges faced by teams trying to introduce XP into their organizations is that XP requires a significant mindset shift throughout the organization, from how teams are organized to how companies conduct business with clients. This book analyzes the shortcomings of XP and proposes an alternative approach to achieving agility, which requires far fewer changes to the existing organization compared to XP while still retaining its agile goals.
You can use this "alternative approach" as a blueprint to set up your own agile methodology (we provide some pointers near the end of the book that point to other agile processes, which we feel are more rigorous than XP). However, the most important purpose of this book is to shatter some of the myths that have emerged with the XP wave, such as the myth that no documentation is needed, that a on-site client and some automated tests are enough to replace written requirement specifications, and the myth that individual needs and comfort are secondary elements of a project (i.e., "join us for pair programming or find another job"). And we intend to achieve this goal in an entertaining and humorous way, because it is good, and the relevant topic requires it.
Target Audience: XP is often introduced into organizations by programmers. This is not surprising, as XP is a "programmer-friendly" method. It elevates the role of programmers (which is essentially not a bad thing) and places them on par with clients. Therefore, if you are a manager or client being persuaded to use XP in the next project, this book provides a valuable counterpoint. If you are a programmer introducing XP into an organization, this book should be helpful to you, as it outlines many of the dangers of XP, which could be potential project killers and are often glossed over in other books about XP. If you are considering trimming XP to extract all its strengths while avoiding the "domino effect" of process changes—where a small change in the process could cause the entire process to collapse—this book offers valuable guidance.