XP - The 12 Steps
- Planning game. Customers decide the scope and timing of releases based on estimates provided by programmers. Programmers implement only the functionality demanded by the stories in this iteration.
- Small releases. The system is put into production in a few months, before solving the whole problem. New releases are made often anywhere from daily to monthly.
- Metaphor. The shape of the system is defined by a metaphor or set of metaphors shared between the customer and programmers.
- Simple design. At every moment, the design runs all the tests, communicates everything the programmers want to communicate, contains no duplicate code, and has the fewest possible classes and methods. This rule can be summarized as, "Say everything once and only once."
- Tests. Programmers write unit tests minute by minute. These tests are collected and they must all run correctly. Customers write functional tests for the stories in an iteration. These tests should also all run, although practically speaking, sometimes a business decision must be made comparing the cost of shipping a known defect and the cost of delay.
- Refactoring. The design of the system is evolved through transformations of the existing design that keep all the tests running.
Notes:
Kent provided a list of the 12 or 13 XP Practices in the sidebar to his original paper reprinted in the IEEE Dynabook: Feel free to read over the quick summary’s of each of the major practices in XP.
Jawed Siddiqi states in, An Exposition of XP But No Position on XP, "For me, the best way to understand Beck’s explanation of XP is in terms of a project management strategy and a development strategy, each of which comprises a set of practices. XP assumes that the four project variables of cost, time, scope, and quality can be controlled.”
Siddiqi goes on to explain that XP assumes currently available tools and practices can be used to control the four project variables. This assumption is contrary to one of the universal software engineering assumptions; the cost of changing a software system over time grows exponentially. Barry Boehm in Software Engineering Economics states, a dollar to fix a problem in a system at requirements might cost thousands after production. The four management strategies are present in some fashion in most methodologies: Customer onsite, Short release, Metaphors and, the Planning game.
Eight of the 12 XP practices describe XP’s development strategy. Four of these depart from other methodologies’ practices: 40-hour workweek, Pair Programming, Collective ownership, and Open workspace. Largely in accord with established good practices are the remaining 4: simple design, coding standards, testing and refactoring.