Extreme Programming (XP) is a new method for developing software. XP is based on a value system the understanding of which is essential for understanding XP. Other agile methodologies, e.g. Crystal or Scrum, are using the same or a similar value system.
In order to explain what XP is, I will describe a typical release cycle.
At the beginning the customer requirements are being collected using user stories. The customer is an integral part of this process.
For every user story one or more acceptance tests will be created by the customer. Theses test server as a validation mean for both the XP-team and the customer.
In the next step the XP-team estimates the effort for every user story. Sometimes this will not be possible due to lack of semantic/business information. In this case the customer will be asked. Sometimes the estimation is not possible because solving a new software problem is required. In this case a prototype (or spike-solution) will be implemented. In some cases several variants of the prototype will be implemented in order to choose from.
Now that the effort for every user story is know, a planning game takes place. The customer contributes his knowledge about the business value of every single user story. Furthermore the time frame, the available resources (e.g. programmers) and the quality are given. The remaining parameter is the scope.
The time frame of a release cycle is typically 3 to 4 months. The customer selects the user stories that will be implemented in the release. He can pick only as many user stories as there is programming capacity available for the release. Under normal circumstances the customer will select the user stories with the highest business value for implementation first.
The release will now be implemented in several iterations of 2 to 3 weeks each. At the beginning of each iteration the XP-team selects one or more user stories. For each of the user stories the team determines which task have to be completed in order to make the user story work. Each task typically takes between as few as 2 hours up to 2 days. A simple user story may consist of only one task. In general each user story consists of several tasks.
After determining the required tasks, the XP-team estimates the required effort for each of the tasks. This may lead to the situation, that the sum of the efforts for all tasks is higher than the effort that can be handled in the iteration. In this case the task may be split, or the user story may be split, or the user story may deferred to the next iteration altogether.
If the team detects that too many user stories have been assigned to the current release cycle, the customer will be informed. Then the customer will be able to decide which user story will be deferred into the next release cycle.
After the iteration planning has been finished, the tasks will be worked on by pairs of programmers. For implementation of source code this means pair programming. The latter consists of a) writing a test case, b) modifying the system and c) make all test cases work. If this is the case the resulting code will be refactored. Refactoring means modifying source code so that the code will be improved to some respect, e.g. readability, redundancy, design, number of classes, number of lines of code, number of methods, number of attributes and so on. Whether a refactoring worked or not can be shown using the existing set of test cases. If and only if all test cases work properly the refactoring was successful.
In some cases some up front design will be necessary. This can be done using CRC cards. But keep in mind, that all flexibility that you might need "tomorrow" will be not considered in the design, because "tomorrow" may never come.
After a task has been completed - which can be proven by successfully executing all test cases, the modification will be integrated into the system. A separate machine will be used, so that at any given time no more than one modification of the system can be integrated. Only if all test cases are successful, the modified system will be submitted to the source code control system. As all the modifications will be integrated as soon as they are implemented, this practice is called continuous integration.
Part of the integration is also to execute associated acceptance tests. After all tasks of a user story have been implemented, associated acceptance tests must run 100%. If else, a new task has to be created, that has to be implemented in the current iteration or it must be scheduled for a future iteration. The latter is equivalent to splitting a user story. The decision for one of the two solutions will be made in collaboration with the customer.
At the end of the release cycle the user will have a system with a guaranteed functionality. It is guaranteed, because there are acceptance tests, which prove that the functionality works as expected.
A side effect of this approach is, that the customer has a fairly working system (prototype) even after each iteration, which (s)he can use to monitor the progress of the project.
Credits: Thanks go to Amy Scrivner of Gemplus for her feedback regarding this page!
© Copyright 2001-2002 by Manfred Lange, All rights reserved. Terms of use.
Last change: