Extreme Programming Practice Adoption Order


MercilessRefactoring requires UnitTests. SimpleDesign requires MercilessRefactoring.

CollectiveCodeOwnership needs tests, to give people courage to edit any piece of code. CollectiveCodeOwnership is supported by PairProgramming, which increases familiarity with the code.

PlanningGame is supported by OnsiteCustomer. UserStory on cards needs OnsiteCustomer.


UserStory on cards needs OnsiteCustomer.

Could you expand on this relationship? I just don't see it.

A user story is a short summary of what needs to be done. The OnsiteCustomer is there to provide more detail, should it be required.


There are really two different questions here.

In the first case, PairProgramming and OnsiteCustomer would be the last (or among the last) practices that I would suggest. In the second case, these would be among the first.

In either case, CollectiveCodeOwnership and UnitTests would top my list for practices to start early.


It would seem to me that UnitTests are the core to anything and should be the first practice adopted, especially with existing code.


It really depends on your situation, amount of legacy code, schedule, etc. For projects already underway, the business/development interaction practices make an ideal starting point. The programmers need to get practice pairing and estimating, and they have to make sure that their build situation is under control. After that, you need to know what you are delivering and that you aren't breaking things (testing), then you can concentrate on being terrifyingly effective in code. People doing greenfield have more possibilities. -- MichaelFeathers


See


CategoryAdoptingXp


EditText of this page (last edited July 18, 2003) or FindPage with title or text search