ExtremeProgrammingCorePractices

Last edit April 2, 2011
The 12 XpXtudes of ExtremeProgramming grouped into four categories

The above practices are listed and explained in the book ExtremeProgrammingExplainedEmbraceChange by KentBeck - first edition.

There are a large number of XpXtudes. The ones up there are kind of at the top. But the practices are not XP, and just doing the practices doesn't make you an XPer. Doing the practices long enough with your mind open ... that might make you an XPer. It could take a while. Took me five years. Now I think I'm starting to get it. -- RonJeffries

See also ExtremeValues for contrast.

Practices as presented in XPE, 2nd edition

Support practices

Those follow more or less naturally from the core practices. They are consequences of defining XP as the above 12 practices rather than part of the definition. The boundary is, as one might expect, not entirely clear-cut; the "12 practices" bit is an innocent act of marketing, so to speak. Put another way, the checklist above qualifies you for XpCertification, but both checklists indicate you will PlayToWin.

Debate in progress as to whether these help or hinder ExtremeProgramming:
See http://xprogramming.com/what-is-extreme-programming/

I should add that DesignImprovement (previously known as RefactorMercilessly) is a very important practice in XP to be left out of the picture. All XP practices support each other, and the practices work as a team, together, just like an XP team.

As to BuyDontBuild, I would call it AdoptDontBuild, since that would also include OpenSource software as well, like Tomcat or Hibernate, for example, and not only CommercialOffTheShelfSoftware. I think that in XP, you should treat ExternalSoftware just like InternalSoftware: TestDrivenDevelopment, ContinuousIntegration, the works.

-- GastonNusimovich

CategoryExtremeProgramming