Specific ExtremeProgramming practices:
- DoTheSimplestThingThatCouldPossiblyWork encourages us not to over (or under)-engineer;
- AskTheCode because it knows; CodeSmells if it has a problem; ListenToTheCode;
- UnitTests ensure that we don't break one another's code;
- AcceptanceTests tell us how we're progressing against user needs;
- An OnsiteCustomer to make sure we build business value;
- ContinuousIntegration helps avoid IntegrationHell;
- ContinuousIntegrationRelentlessTesting ditto;
- RefactorMercilessly keeps the code clean and speeds progress;
- and see also WikiPagesAboutRefactoring;
- PairProgramming gives higher quality, great cross-training, and higher speed; (mailing list: PairProgramming);
- SpikeSolution helps explore the area we're working on;
- ModelFirst plus SpartanUserInterface helps us concentrate on real customer value
- ExtremePlanning suggests quickly building a map of the whole imagined system and incrementally refining it
- The PlanningGame formalizes the rituals and roles of planning
- CountDownToRelease discusses how to use the ExtremePlanning practices when you're getting close to release
- ExtremeReuse - adopting third party software and making it XP-compatible by building tests
- TossIt - making projects trim and keeping projects trim
- SystemMetaphor - how we communicate the system to ourselves and others
- XpDesign - who does the design in an XP project, and when?
- XpSimplicityRules
- OnceAndOnlyOnce
- ExtremeDocuments - we do documentation, sometimes differently
- SupportCrisis - what to do until the doctor comes
- IncrementalDelivery
- LazyOptimization and EarlyProfiling
- OpenWorkspace
- UserStory - like use cases, but different
- EngineeringTask - a UserStory gets broken down into these
- IterativeDevelopment - tends to be a natural result of ContinuousIntegration and ContinuousIntegrationRelentlessTesting andDoTheSimplestThingThatCouldPossiblyWork at each iteration
- DynamicDesign - from RefactorMercilessly and short Code-Compile-Debug cycle
- FewerWorkHours [important]