Knocking It Down . . . and Then Rebuilding It

At this point we should remind ourselves that the title of this book is Extreme Programming Refactored , meaning that we intend to tweak and hone the XP practices into something that s semantically the same because it still achieves XP s agile goals, but does so in a much more rigorous and less risky manner. The process that we d like to end up with should also be applicable to a much wider variety of projects and shouldn t require significant organizational change.

To get there, we analyze the not-so-good aspects of XP (in fact, most of this book analyzes the not-so-good aspects of XP, although we make no apologies for this because there are already plenty of positive books about XP out there). As a sneak preview, we present here a quick summary of the refactored process that we re aiming for.

If you d like to read the more detailed description of the refactored process, skip ahead to Chapter 15. That chapter also contains a case study of an XP-like project that is very close to our refactored process.

 

Some of what we describe here is XP, and some of it isn t. We emphasize that this is intended as a discussion point, possibly a crib sheet for when you re tailoring a methodology for your own project ”but this is far from being a methodology in itself.