Core practices of Extreme Programming
Filed Under Model, Process, Development, Software | Posted on December 12, 2007
The development methodology known as ‘Extreme Programming’ has 12 ‘Core Practices’. These can be grouped together into some groups:
Fine scale feedback
* Test driven development: Top XP teams practice “test-driven development”, working in very short cycles of adding a test, then making it work. Almost effortlessly, teams produce code with nearly 100 percent test coverage, which is a great step forward in most shops.
* Planning game: The main planning process within Extreme Programming is called the planning game. The game is a meeting that occurs once per iteration, typically once a week. The planning process is divided into two parts:
- Release Planning: This is focused on determining what requirements are included in which near-term releases, and when they should be delivered. The customers and developers are both part of this.
- Iteration Planning: This plans the activities and tasks of the developers. In this process the customer is not involved.
* Whole team: Within XP, the “customer” is not the one who pays the bill, but the one who really uses the system. XP says that the customer should be on hand at all times and available for questions. So a software developed for manufacturing should have the manufacturing expert handy.
* Pair programming: An Extreme Programming practice in which two engineers participate in one development effort at one workstation. Each member performs the action the other is not currently doing: While one types in Unit Tests the other thinks about the class that will satisfy the test.
Continuous process rather than batch
* Continuous Integration: Frequent code integration helps you to avoid integration nightmares. XP teams integrate their code several times a day, after they get all the unit tests for the system to run. Traditional approaches tend to work like this: code a lot, do a big-bang integration, then spend a significant amount of time fixing the problems. This yo-yo style really slows a project down. Big-bang integrations dump a load of problems on the team all at once, and those problems often have hundreds of possible causes.
* Design Improvement (a.k.a refactor): Refactoring is the technique of improving code without changing functionality. An XP team refactors mercilessly. Developers try to determine if changing existing code would make implementing the new feature easier. They look at the code they just wrote to see if there is any way to simplify it. For example, if they see an opportunity for abstraction, they refactor to remove duplicate code from concrete implementations.
* Small Releases: Start with the smallest useful feature set. Release early and often, adding a few features each time. This helps in being able to generate feedback in a much more efficient way.
Shared understanding
* Simple design: XP teams build software to a simple design. They start simple, and through programmer testing and design improvement, they keep it that way. An XP team keeps the design exactly suited for the current functionality of the system. There is no wasted motion, and the software is always ready for what’s next.
* System metaphor: Extreme Programming teams develop a common vision of how the program works, which we call the “metaphor”. At its best, the metaphor is a simple evocative description of how the program works, such as “this program works like a hive of bees, going out for pollen and bringing it back to the hive” as a description for an agent-based information retrieval system.
* Collective code ownership: Collective code ownership means that everybody is responsible for all the code; this, in turn, means that everybody is allowed to change any part of the code. Pair programming contributes to this practice: by working in different pairs, all the programmers get to see all the parts of the code. A major advantage claimed for collective ownership is that it speeds up the development process, because if an error occurs in the code any programmer may fix it.
* Coding standards or coding conventions: Everyone codes to the same standards. Ideally, you shouldn’t be able to tell by looking at it who on the team has touched a specific piece of code.
Programmer welfare
* Sustainable pace (i.e. forty hour week): Very essential. Programmers go home on time. In crunch mode, up to one week of overtime is allowed. But multiple consecutive weeks of overtime are treated as a sign that something is very wrong with the process.
Leave a Reply
