wiiki - ExtremeProgrammingPractices

Here are the definitions for terms used in the ExtremeProgrammingEnablingChart:

Commitment to XP / On-site customer -- It helps a lot for there to be some management or customer support for Extreme programming for it to work well. An involved customer on site an involved marketing person on-site can be invaluable. See: WhoIsTheCustomer OnSiteCustomer
Business knowledge of XP The leadership on a project knows how the DeveloperBillOfRights is supposed to work.
Technical knowledge of XP The technical staff on the project knows how the CustomerBillOfRights is supposed to work.
UbiquitousLanguage The WholeTeam uses the same names for the same things, consistently, from the top of the GUI to the bottom of the database.
UserStory Definition and Estimation Stories for chunks of functionality the system will have and rough estimates for how long each will take to implement. Estimates of how long it will take to build each story are done by marketing and development together. There are directions for how to do this in the XP books. See: UserStory UserStoryExamples StoryCard
CollectiveCodeOwnership If each of us own all the code, we can work on it, modify it, and improve it. Test first programming keeps us from breaking the code while we do this. Most importantly, people do not become too attched to ?their? code. Collective owner ship seems to be a cause and effect of the other techniques.
Priorities and ReleasePlanning The on-site customer prioritizes the stories, picks a release cycle length, And chooses which stories go into it based on the estimates and what is necessary for the first release to have business value. See: ReleasePlanning
SpikeSolution A spike solution is used when not enough is known about a technology or user story to be able to estimate it. The team stops what they are doing and investigates this in a proof of concept kind of mode until they understand the technology enough to estimate tasks in it.
CommonWorkspace all engineers, and (usually) the OnsiteCustomer, work in the same room, at PairStations. Not just "on the same floor of the same building". This way all developers can PairPromiscuously.
PlanningGame for task definition and estimation. 1. identifying the tasks that will need to be done to complete a story (customer desired fuction) 2. HAving developers sign up for tasks that they want to do or think will be fun to do. 3. Having the selector estimate how long eash of these tasks will take. 4. Reshuffling tasks if it looks like some developers have too many and some too few. ONe important thing is that a developer working on a task must have been the one to make the estimate on the task.
Develop TestFirst expertise -- I may remove this and refactor the diagram to put coding standards back in
YouArentGonnaNeedIt (YAGNI) -- Don't Build if yet if You Aren't Going to Need It yet. If you don't need it yet, then you don't know if you are ever going to need it, or if you will need it, whether you know enough to build it right yet.
Technical Specifications Detailed specifications on how the system will work technically. Not generally considered part of ExtremeProgramming, they can be useful in passing along information to support, QA, and testing personnel, and the next generation of programmers. See: TechnicalSpecification
TestDrivenDevelopment This is the critical part of Extreme programming. Before code is written, tasks are converted to tests. Then only that programming that is necessary to pass the test is written. TestFirstProgramming has many many benefits including most of the items below.
PairProgramming, walk-through's and help
Continuous integration / Acceptance Tests Nightly and frequent daily builds, along with an acceptance test suite to make sure the integrated product has not been broken.
RefactorMercilessly This is what gives Extreme Programming its EmergentDesign. Constant refactoring until the design is simplified optimally and keeping it that way allows very rapid reactions to chaning business limates and company and customer needs. To be able to use refactoring however one needs to have a number of techniques implemented, especially test first design (and YAGNI and continuous integration, and pair programming etc.). This is what the ExtremeProgrammingEnablingChart is all about. See OnceAndOnlyOnce
YouDontNeedItAnymore - get rid of any code that is not actually used.
Extreme technical support extreme technical support becomes possible once the technical support staff have data coming straigh out of the development process, systems that are simple for people to use, and a large suite of tests to track dowon problems. Under these conditions, the support staff can do the more high value work of wokring on the most difficult problems that crop up and finding out what customers think of the product.
SmallReleases and DailyDeployment
Code Reveals all intention
Evaluation by offsite customers
Simple Evolutionary design
High data input marketing Once you have repeated evaluation of your product by customers, and a support system that is geared to working with with most difficult cases then you have some pretty poerful data to build marketing plans on.
Rapid Design / Product Conforms quickly to Market Need
Summary Design diagrams / simple planned design
Sales campaign schedule planning
High data input marketing
active idea solicitation / application / generation / research
BusinessValue The bottom line in business is the bottom line in extreme programming. Extreme Programming is driven by business value and is geared to gerate the most busienss value the fastest in the best sustained manner. Business value means things like getting to market quickly with the product people want, knowing who they are, and rapidly improving the product in response to their needs.

Here is a list of wiki pages describing each ExtremeProgramming practice:

CategoryExtremeProgramming