Also known as XP (eXtreme Programming), this is an Agile methodology based on about 12 core practices


XP is the most well known, most popular, and possibly the most misunderstood of Agile methodologies.  Its core practices are strongly geared toward the production of working code, and, in the untailored methodology, treat the potential for change in requirements as one of the highest risks.


The primary sources are books, but there are a few related websites and at least one online forum.


A discussion on XP could fill a whole website.  We shall leave that to others.  Here follows one version of the list of core practices.

CustomerOnSite, have the customer as a member of the team.

UserStories, placeholders for requirements that will be detailed later, but now are sufficient for estimation.

Short Cycles, IterativeDevelopment constrained to deliver working software in short cycles, usually every two weeks.

AcceptanceTests, written by the customer, give the detailed requirements.

Pair Programming, a constrained variant of DevelopingInPairs whereby developers always work in pairs to write production code.

TestDrivenDevelopment, write the test first, then write code that will make the test pass.

CollectiveOwnership, necessary to ensure the developers have freedom to write the best solution.

ContinuousIntegration, reduces the risk of code merge problems while having non-blocking source control.

SustainablePace, enables reliable calculation of velocity and thus predictions of effort to support planning.

OpenWorkspace, enables optimum freedom of communication.

The PlanningGame, supports prioritized, planned delivery of functionality.

SimpleDesign, minimizes effort in development and maintenance.

ConstantRefactoring, enables integration of changed requirements without degradation of architecture and code structure.

SystemMetaphor, gives a simple ‘big picture’ to help keep on track when making design decisions.