Extreme Programming

If you are thinking about implementing extreme programming, read the references mentioned in this document in order to fully understand the implementation. This document simply gives a summary overview of extreme programming so the reader can decide it they are interested pursuing extreme programming further.

Extreme programming (XP) is about project management and programming methodologies that are designed to enhance production. Extreme programming has some similarities with the Rational Unified Process (RUP) and some ways could be considered a very abbreviated version of the RUP with modifications. Also some extreme programming methodologies can be applied without applying all extreme programming methods. One such example is pair programming.

RUP/UML and XP Differences

However, although XP has some similarities with the Rational Unified Process (RUP), and XP methods can be applied elsewhere, don't be fooled. Although some XP methods will work well by themselves, XP has many differences and many of the methods behind it are interdependent. This means that if some methods of XP are left out, the system may not work.

Another important difference between XP and RUP/UML is that XP does not use drawings to enhance the analysis and design process. It does not plan for change as does RUP/UML. Based on the methods used in XP, the code is expected to be of a higher quality. Also it relies heavily on refactoring the code to make changes as additional features or changes are required. Refactoring code is the process of changing code to improve its structure as it evolves. Generally XP is introducing constant course corrections to the project, but RUP/UML is planned ahead to more easily accomodate changes.

XP Project Application

Some experts say that extreme programming works best with small to medium size projects and it is best to use Unified Modeling Language (UML) and the Rational Unified Process for running larger software projects. It is said that extreme programming works best for high risk projects.

Brief XP Planning Description

Basically, when an extreme programming project is started, user stories (similar to use cases which are called "metaphors") are written on an index card as a short story. The customer writes the stories and they should be focused on user needs. The business and technical staff are placed in the same room. The business people must rate each story card as follows:

1. Absolutely must have it.
2. I need it but I could barely live without it.
3. If you twist my arm, I don't really need it.

The technical people rate each story card as requiring one, two, or three man weeks in uninterrupted time for one programmer, ignoring pair programming. If a story requires more than three man weeks, it is broken down further. The technical people rate the risk of each story as low, medium, and high. Once done, the stories may placed in order and are worked on in that order. This is known as "the Planning Game".

On a practical level, the order of the stories should be from most essential and highest risk to least required and lowest risk. However this may not always be the case. The customer should determine the order of the stories in conjunction with the interdependence of the stories (functionality) required to make a working and testable system. Therefore the technical staff would have some input here but the customer has more priority.

Planning may be done several times over the life of the project as requirements change or new issues are discovered. An overall schedule and budget may be estimated by figuring the estimated time for the work factored with the project velocity. As feedback is gained during the project, the estimates may need to be revised or remove some project scope (Of course you could finish ahead of schedule).

Control Variables

XP utilizes four project control variables:

• Scope - If scope is reduced, you can get better quality or less time for the project.
• Cost - Need enough money to solve the problem.
• Time - More time can allow the scope or quality to be increased.
• Quality - Sacrificing quality can cost productivity and is not usually a good idea.

XP Values

• Simplicity - It is better to implement the simplest solution.
• Communication - Increases cooperation, group productiveness, and decreases mistakes.
• Feedback - Keeps the project on track. Feedback should be almost continuous.
• Courage - Required to be able to throw code away when it is appropriate, or to refactor late in the design to increase system performance.

XP Principles

• Pair programming - Ensures quality code. One programmer is thinking whether the approach will work, about testing, or ways to simplify the code while the other programmer writes the code. The roles of the two programmers may change often, and programmer pairs may change often.
• Simple design - Keep the design as simple as possible for the moment and don't add features that ar not needed for current functionality. The reasoning behind this is that if a feature is not valuable now, it is not worth the investment until it is valuable.
• Small releases - There is a short time between versions.
• Refactoring - The code is restructured as necessary to improve structure and performance. Refactoring is done before additional capabilities are added, not while they are being added to be sure the system is not broken during refactoring.
• Testing - Tests are written first and must run for design to continue. Testing is done often. Customers may determine tests required to determine what features work.
• Integration - Code is continuously integrated together.
• Correct working hours - Generally limited to 40 hours per week with no overtime for more than one week at a time. This is to keep programmers alert so they do not make mistakes.
• Customer availability - The customer is on site to answer questions or at least is readily accessible.
• Standards of coding - There are group rules for code so all members can understand the code readily.
• Group ownership of code - All members of the group can change any code at any time.

XP Principle Interdependencies

1. Group ownership depends on frequent testing, continuous integration, coding standards, and pair programming.
2. Refactoring depends on coding standards, group ownership, continuous integration, pair programming, and simple design.
3. Simple design depends on communication, refactoring, and pair programming.
4. Testing depends on simple design, and pair programming.
5. Pair programming depends on correct working hours, coding standards, simple design, and testing.

There are other dependencies, but these illustrate the point.

Other XP strategies/values

• Incremental change - Small changes are made since big changes are more risky and may fail.
• Teach strategies to help staff learn how much testing should be done.
• Keep initial project investment small - Start with a small team and build up in size allowing members to learn from each other.
• Do experiments to eliminate the risk of technology or incorrect decisions.
• Few artifacts (documents) are maintained.
• Stand up meetings - Meetings held at the same time each day where all members stand to keep the meeting brief. Each member reports any problems, but solutions are not proposed. This way members can be thinking about how to solve the problems as they work.

Tracking Progress

One team member is designated as the project tracker. Twice per week, the tracker asks each member for their task:

• How many ideal days worked?
• How many ideal days left?

Based on this, you can tell how the team is progressing or if there are any trouble areas.

As iterations are completed project velocity can be measured. Project velocity is the ratio between estimated time and real calender time. A chart of the project velocity is posted by the manager showing the medium velocity (Metric). Too many metrics become meaningless.

Iterations

Iterations are generally two to three weeks long with releases being every one to three months.

Management and Staff Relationships

• Trust between staff and the manager is essential.
• The manager provides direction for change incrementally.
• The manager does not assign work, but sets priorities and shows what should be done. The manager may not assign the work to individuals if the trust relationship between the group and manager is healthy enough.
• Communication is essential.
• The manager must get the team to make good decisions.
• The manager measures project velocity while the team reports progress. Project velocity is the ratio between estimated time and real calender time. A chart of the project velocity is posted by the manager showing the medium velocity (Metric). Too many metrics become meaningless.
• The business and development sides must be understanding and work closely together. When development discovers the unexpected, it should inform business that it learned something and respond together as a team to provide a solution.
  Extreme Programming Contents Page