Extreme Programming Refactored: The Case Against XP is meant to provide an independent look at Extreme Programming. It is meant to cut through the marketing hype of Extreme Programming and expose a number of weaknesses with this approach to software development. It tries to draw a distinction between true "agility" in a software process and "fragility" inherent in techniques such as oral documentation. Extreme Programming (XP) is a consummate mix of good goals, some good advice, and lots of bad advice. The goals and the good advice draw people in; the bad advice can potentially cause projects to fail. The XPers' theory is that when applied together, this mixture of rules will somehow magically be safe. XP therefore represents a high-risk process, wrapped in a "feel-good" methodology. The marketing, hype, and earnest self-assurance of its authors will convince many project leaders to try out XP on their next project. In Extreme Programming Refactored: The Case Against XP into a more viable process, Rosenberg and Stephens are not attempting to define a new methodology, as there are plenty of those in the World already. Instead, they will be examining XP in the context of existing methodologies and processes such as RUP, ICONIX, Spiral, RAD, DSDM, etc - and showing how XP goals can be achieved using these existing processes (with a slight emphasis on RUP and ICONIX), using software wisdom that has been tried and proven to work again and again."Any one [XP] practice doesn't stand well on its own (with the possible exception of testing). They require the other practices to keep them in balance.” - Kent Beck, Extreme Programming Explained, (Chapter 11)

“Well, from my experience, most teams that say they're doing XP don't actually do the practices.

“Houston, we have a problem.” - Jim Lovell, Apollo 13

Extreme Programming Refactored: The Case Against XP (featuring Songs of the Extremos) takes a satirical look at the increasingly hyped Extreme Programming methodology. It explores some quite astonishing Extremo quotes that have typified the XP approach— quotes such as, “XPers are not afraid of oral documentation,” “Schedule is the customer's problem,” “Dependencies between requirements are more a matter of fear than reality” and “Concentration is the Enemy.”

In between the chuckles, though, there is a serious analysis of XP's many flaws. The authors also examine C3, the first XP project, whose team (most of whom went on to get XP book deals shortly before C3's cancellation) described themselves as "the best team on the face of the Earth". (In a later chapter, the authors also note that one problem which can affect pair programmers is overconfidence— or is that "eXcessive courage"?). The authors examine whether the problems that led to C3's “inexplicable” cancellation could also afflict present-day XP projects.

In the final chapter (Refactoring XP) Matt and Doug suggest some ways of achieving the agile goals of XP using some XP practices (used in moderation) combined with other, less risk-laden methods." -->

 Please note that by using the bookgo.org service you agree to all Rules and notices. These policies may change whenever necessary. All the resourses are from internet for interest only .you must delete it in 24 hours after download, and the copyright belongs to the related authors and the press. If you think those matters violent your copyright, it would be deleted immediately,all right belong to the original author.