XP is a lightweight methodology for small to medium-sized teams developing software in the face of vague or rapidly changing requirements.
To some people, XP seems like just good common sense. So why the “extreme” in the name?
XP takes commonsense principles and practices to extreme levels.
- If code reviews are good, we’ll review code all the time (pair programming).
- If testing is good, everybody will test all the time (unit testing), even the customers (functional testing).
- If design is good, we’ll make it part of everybody’s daily business (refactoring).
- If simplicity is good, we’ll always leave the system with the simplest design that supports its current functionality (the simplest thing that could possibly work).
- If architecture is important, everybody will work defining and refining the architecture all the time (metaphor).
- If integration testing is important, then we’ll integrate and test several times a day (continuous integration).
- If short iterations are good, we’ll make the iterations really, really short—seconds and minutes and hours, not weeks and months and years (the Planning Game).
XP makes two sets of promises
- To programmers, XP promises that they will be able to work on things that really matter, every day. They won’t have to face scary situations alone. They will be able to do everything in their power to make their system successful. They will make decisions that they can make best, and they won’t make decisions they they aren’t best qualified to make.
- To customers and managers, XP promises that they will get the most possible value out of every programming week. Every few weeks they will be able to see concrete progress on goals they care about. They will be able to change the direction of the project in the middle of development without incurring exorbitant costs.
In short, XP promises to reduce project risk, improve responsiveness to business changes, improve productivity throughout the life of a system, and add fun to building software in teams—all at the same time.
What differs XP from other methodologies
- Its early, concrete, and continuing feedback from short cycles.
- Its incremental planning approach, which quickly comes up with an overall plan that is expected to evolve through the life of the project.
- Its ability to flexibly schedule the implementation of functionality, responding to changing business needs.
- Its reliance on automated tests written by programmers and customers to monitor the progress of development, to allow the system to evolve, and to catch defects early.
- Its reliance on oral communication, tests, and source code to communicate system structure and intent.
- Its reliance on an evolutionary design process that lasts as long as the system lasts.
- Its reliance on the close collaboration of programmers with ordinary skills.
- Its reliance on practices that work with both the short-term instincts of programmers and the long-term interests of the project.
How XP handles the risks
Software development fails to deliver, and fails to deliver value. This failure has huge economic and human impact. We need to find a new way to develop software.
The basic problem of software development is risk. Here are some examples of risk:
- Schedule slips—the day for delivery comes, and you have to tell the customer that the software won’t be ready for another six months.
- Project canceled—after numerous slips, the project is canceled without ever going into production.
- System goes sour—the software is successfully put into production, but after a couple of years the cost of making changes or the defect rate rises so much that the system must be
- Defect rate—the software is put into production, but the defect rate is so high that it isn’t used.
- Business misunderstood—the software is put into production, but it doesn’t solve the business problem that was originally posed.
- Business changes—the software is put into production, but the business problem it was designed to solve was replaced six months ago by another, more pressing, business problem.
- False feature rich—the software has a host of potentially interesting features, all of which were fun to program, but none of which makes the customer much money.
- Staff turnover—after two years, all the good programmers on the project begin to hate the program and leave.
How does XP address the risks listed above?
- Schedule slips—XP calls for short release cycles, a few months at most, so the scope of any slip is limited. Within a release, XP uses one- to four-week iterations of customer requested
features for fine-grained feedback about progress. Within an iteration, XP plans with one- to three-day tasks, so the team can solve problems even during an iteration. Finally, XP calls for implementing the highest priority features first, so any features that slip past the release will be of lower value.
- Project canceled—XP asks the customer to choose the smallest release that makes the most business sense, so there is less to go wrong before going into production and the value of the software is greatest.
- System goes sour—XP creates and maintains a comprehensive suite of tests, which are run and re-run after every change (several times a day), to ensure a quality baseline. XP always keeps the system in prime condition. Cruft is not allowed to accumulate.
- Defect rate—XP tests from the perspective of both programmers writing tests function-byfunction and customers writing tests program-feature-by-program-feature.
- Business misunderstood—XP calls for the customer to be an integral part of the team. The specification of the project is continuously refined during development, so learning by the
customer and the team can be reflected in the software.
- Business changes—XP shortens the release cycle, so there is less change during the development of a single release. During a release, the customer is welcome to substitute new functionality for functionality not yet completed. The team doesn’t even notice if it is working on newly discovered functionality or features defined years ago.
- False feature rich—XP insists that only the highest priority tasks are addressed.
- Staff turnover—XP asks programmers to accept responsibility for estimating and completing their own work, gives them feedback about the actual time taken so their estimates can improve, and respects those estimates. The rules for who can make and change estimates are clear. Thus, there is less chance for a programmer to get frustrated by being asked to do the obviously impossible. XP also encourages human contact among the team, reducing the loneliness that is often at the heart of job dissatisfaction. Finally, XP incorporates an explicit model of staff turnover. New team members are encouraged to gradually accept more and more responsibility, and are assisted along the way by each other and by existing programmers.