Extreme Programming Practices

Extreme programming (XP)
Definition
Extreme programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements.
History
Extreme Programming was created by Kent Beck during his work on the Chrysler Comprehensive Compensation System (C3) payroll project. Beck became the C3 project leader in March 1996 and began to refine the development methodology used in the project and wrote a book on the methodology (in October 1999, Extreme Programming Explained was published. Chrysler cancelled the C3 project in February 2000, after seven years, when the company was acquired by Daimler-Benz.
Many of extreme programming practices have been around for some time; the methodology…show more content…
Each feedback of the customer that specifies revised requirement becomes the basis of a new design, and the process of design-coding-tests-listening repeats itself. If the customer remains satisfied with the test results the iteration ends there, and the design for the new iteration starts, which again follows the design-coding-testing-listening

Extreme programming practices
The 12 core practices of XP are:
 The Planning Game: Business and development cooperate to produce the maximum business value as rapidly as possible. The planning game happens at various scales, but the basic rules are always the same: o Business comes up with a list of desired features for the system. Each feature is written out as a User Story, which gives the feature a name, and describes in broad strokes what is required. User stories are typically written on 4x6 cards. o Development estimates how much effort each story will take, and how much effort the team can produce in a given time interval (the iteration). o Business then decides which stories to implement in what order, as well as when and how often to produce production releases of the system.
 Small Releases: Start with the smallest useful feature set. Release early and often, adding a few features each time.
 System Metaphor: Each project has an organizing metaphor, which provides an easy to remember naming…show more content…
When the suite runs, the job is done. Tests in XP come in two basic flavors. o Unit Tests are automated tests written by the developers to test functionality as they write it. Each unit test typically tests only a single class, or a small cluster of classes. Unit tests are typically written using a unit testing framework, such as JUnit. o Acceptance Tests (also known as Functional Tests) are specified by the customer to test that the overall system is functioning as specified. Acceptance tests typically test the entire system, or some large chunk of it. When all the acceptance tests pass for a given user story, that story is considered complete. At the very least, an acceptance test could consist of a script of user interface actions and expected results that a human can run. Ideally acceptance tests should be automated, either using the unit testing framework, or a separate acceptance testing framework.
 Refactoring: Refactor out any duplicate code generated in a coding session. You can do this with confidence that you didn't break anything because you have the tests.
 Pair Programming: All production code is written by two programmers sitting at one machine. Essentially, all code is reviewed as it is