Extreme Programming is a discipline of software development based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation.
The 12 rules of Extreme Programming, true to the nature of the method itself, are concise and to the point. In fact, you could almost implement XP without reading a page of Beck’s book.
· The Planning Game: At the start of each iteration customers, managers, and developers meet to flesh out, estimate, and prioritize requirements for the next release. The requirements are called “user stories” and are captured on “story cards” in a language understandable by all parties.
· Small Releases: An initial version of the system is put into production after the first few iterations. Subsequently, working versions are put into production anywhere from every few days to every few weeks.
· Metaphor: Customers, managers, and developers construct a metaphor, or set of metaphors after which to model the system.
· Simple Design: Developers are urged to keep design as simple as possible, “say everything once and only once”.
· Tests: Developers work test-first; that is, they write acceptance tests for their code before they write the code itself. Customers write functional tests for each iteration and at the end of each iteration, all tests should run.
· Refactoring: As developers work, the design should be evolved to keep it as simple as possible.
· Pair Programming: Two developers sitting at the same machine write all code.
· Continuous Integration: Developers integrate new code into the system as often as possible. All functional tests must still pass after integration or the new code is discarded.
· Collective ownership: The code is owned by all developers, and they may make changes anywhere in the code at anytime they feel necessary.
· On-site customer: A customer works with the development team at all times to answer questions, perform acceptance tests, and ensure that development is progressing as expected.
· 40-hour Weeks: Requirements should be selected for each iteration such that developers do not need to put in overtime.
· Open Workspace: Developers work in a common workspace set up with individual workstation around the periphery and common development machines in the center.
Practitioners tend to agree that the strength of Extreme Programming does not result from each of the 12 practices alone, but from the emergent properties arising from their combination.
Highsmith lists five key principles of XP, all of which are enhanced by its practices: communication, simplicity, feedback, courage, and quality work.
Extreme Programming Values and Principles
The XP values are:
· Communication
· Simplicity
· Feedback
· Courage
An XP project relies on these four values. If your organization or team doesn't truly share these values, then an XP project will fail. Of course, most of those values are motherhood-and-apple pie –it would be hard to find an organization that said that it didn't believe in them. XP tries to remove some of the vagueness from these values by describing principles that embody the values.
· Open, honest communication
· Quality work
· Rapid feedback at all levels
· Assume Simplicity
· Embrace change
· Play to win
· Concrete experiments
· Small initial investment
· Incremental change
· Accepted responsibility
· Honest measurement
· Travel light
· Teach learning
· Local adaptation
Limitations of XP
Practitioners of XP clearly state where the model works and where it does not.
· Team size: Because the development team needs to be co-located, team size is limited to the number of people that can fit in a single room, generally agreed to be from 2-10.
· Iteration length: XP has the shortest recommended iteration length of the Agile Methods under consideration, 2 weeks.
· Support for distributed teams: Because of XP’s focus on community and co-location, distributed teams are not supported.
· System criticality: XP is not necessarily geared for one system or another. However, most agree that there is nothing in XP itself that should limit its applicability