The 12 XpXtudes of ExtremeProgramming grouped into four categories
- Fine scale feedback
- Continuous process rather than batch
- Shared understanding
- Programmer welfare
The above practices are listed and explained in the book ExtremeProgrammingExplainedEmbraceChange
- first edition.
There are a large number of XpXtude
s. 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
Practices as presented in XPE, 2nd edition
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
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
just like InternalSoftware?
, the works.