'''The 12 XpXtude''''''s of ExtremeProgramming grouped into four categories''' * Fine scale feedback * TestDrivenDevelopment via ProgrammerTest''''''s and CustomerTest''''''s (were UnitTest''''''s & AcceptanceTest''''''s) * PlanningGame * WholeTeam (was OnsiteCustomer) * PairProgramming * Continuous process rather than batch * ContinuousIntegration * DesignImprovement (was RefactorMercilessly) * SmallReleases * Shared understanding * SimpleDesign (DoSimpleThings, YouArentGonnaNeedIt, OnceAndOnlyOnce, SimplifyVigorously) * SystemMetaphor * CollectiveCodeOwnership * CodingStandard or CodingConventions * Programmer welfare * SustainablePace (original name: FortyHourWeek) The above practices are listed and explained in the book ExtremeProgrammingExplainedEmbraceChange by KentBeck - 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 for contrast. ---- '''Practices as presented in XPE, 2nd edition''' * PrimaryPractices * '''SitTogether''' * '''WholeTeam''' * '''InformativeWorkspace''' * '''EnergizedWork''' * '''PairProgramming''' * '''Stories''' (UserStories) * '''WeeklyCycle''' * '''QuarterlyCycle''' * '''Slack''' * '''TenMinuteBuild''' * '''ContinuousIntegration''' * '''TestFirstProgramming''' * '''IncrementalDesign''' * CorollaryPractices * '''RealCustomerInvolvement''' * '''IncrementalDeployment''' * '''TeamContinuity''' * '''ShrinkingTeams''' * '''RootCauseAnalysis''' * '''SharedCode''' * '''CodeAndTests''' * '''SingleCodeBase''' * '''DailyDeployment''' * '''NegotiatedScopeContract''' * '''PayPerUse''' ---- '''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. * Exploration * ReleasePlan * SpikeSolution * TestDrivenDesign * CodeUnitTestFirst * RelentlessTesting * NoBugDatabase * Architecture * BridgeThread * Design * DontRepeatYourself, also OnceAndOnlyOnce. * EngineeringTask''''''s * CrcCard''''''s (WriteItOnaCard) * AgileModeling - JustEnoughDesign * Teamwork * CodeStewardship * ProjectVelocity * ThereMustBeFood * TheyreJustRules * ExtremeRoles (TheCoach, TrackerRole, etc.) * CustomerBillOfRights * DeveloperBillOfRights * Shared understanding * PairPromiscuously * StandUpMeeting''''''s * AllEngineersInOneRoom * ContinuousIntegration and VersionControl * FrequentReleases * TheIntegrationStation * ScopeControl * SustainingBehaviours * Slack time to read books, articles, experiment... (''aka O''''''nlyPairSixHoursPerDay'' ;-) * TakeRegularBreaks * IterationRetrospective * ExtremeProgrammingLevels * OneButtonTesting Debate in progress as to whether these help or hinder ExtremeProgramming: * BuyDontBuild ---- 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