Extreme Programming

From Amachu
Jump to: navigation, search

Extreme Programming (XP) has evolved from the problems caused by the long development cycles of traditional development models. It first started as 'simply an opportunity to get the job done' with practices that had been found effective in software development processes during the preceding decades. After a number of successful trials in practice , the XP methodology was "theorized" on the key principles and practices used. Even though the individual practices of XP are not new as such, in XP they have been collected and lined up to function with each other in a novel way thus forming a new methodology for software development. The term 'extreme' comes from taking these commonsense principles and practices to extreme levels.



The life cycle of XP consists of five phases: Exploration, Planning, Iterations to Release, Productionizing, Maintenance and Death. In the following, these phases are introduced according to Beck's description:

Life Cycle of a XP Process

In the Exploration phase, the customers write out the story cards that they wish to be included in the first release. Each story card describes a feature to be added into the program. At the same time the project team familiarize themselves with the tools, technology and practices they will be using in the project. The technology to be used will be tested and the architecture possibilities for the system are explored by building a prototype of the system. The exploration phase takes between a few weeks to a few months, depending largely on how familiar the technology is to the programmers.

The Planning phase sets the priority order for the stories and an agreement of the contents of the first small release is made. The programmers first estimate how much effort each story requires and the schedule is then agreed upon. The time span of the schedule of the first release does not normally exceed two months. The planning phase itself takes a couple of days.

The Iterations to release phase includes several iterations of the systems before the first release. The schedule set in the planning stage is broken down to a number of iterations that will each take one to four weeks to implement. The first iteration creates a system with the architecture of the whole system. This is achieved by selecting the stories that will enforce building the structure for the whole system. The customer decides the stories to be selected for each iteration. The functional tests created by the customer are run at the end of every iteration. At the end of the last iteration the system is ready for production.

The Productionizing phase requires extra testing and checking of the performance of the system before the system can be released to the customer. At this phase, new changes may still be found and the decision has to be made if they are included in the current release. During this phase, the iterations may need to be quickened from three weeks to one week. The postponed ideas and suggestions are documented for later implementation during, e.g., the maintenance phase.

After the first release is productionized for customer use, the XP project must both keep the system in the production running while also producing new iterations. In order to do this, the Maintenance phase requires an effort also for customer support tasks. Thus, the development velocity may decelerate after the system is in production. The maintenance phase may require incorporating new people into the team and changing the team structure.

The Death phase is near when the customer does no longer have any stories to be implemented. This requires that the system satisfies customer needs also in other respects (e.g., concerning performance and reliability). This is the time in the XP process when the necessary documentation of the system is finally written as no more changes to the architecture, design or code are made. Death may also occur if the system is not delivering the desired outcomes, or if it becomes too expensive for further development.

Roles and responsibilities

There are different roles in XP for different tasks and purposes during the process and its practices. In the following, these roles are presented according to Beck.


Programmers write tests and keep the program code as simple and definite as possible. The first issue making XP successful is to communicate and coordinate with other programmers and team members.


The customer writes the stories and functional tests, and decides when each requirement is satisfied. The customer sets the implementation priority for the requirements.


Testers help the customer write functional tests. They run functional tests regularly, broadcast test results and maintain testing tools.


Tracker gives feedback in XP. He traces the estimates made by the team (e.g. effort estimates) and gives feedback on how accurate they are in order to improve future estimations. He also traces the progress of each iteration and evaluates whether the goal is reachable within the given resource and time constraints or if any changes are needed in the process.


Coach is the person responsible for the process as a whole. A sound understanding of XP is important in this role enabling the coach to guide the other team members in following the process.


Consultant is an external member possessing the specific technical knowledge needed. The consultant guides the team in solving their specific problems.

Manager (Big Boss)

Manager makes the decisions. In order to be able to do this, he communicates with the project team to determine the current situation, and to distinguish any difficulties or deficiencies in the process.


XP is a collection of ideas and practices drawn from already existing methodologies. The decision making structure, as presented in Figure, in which the customer makes business decisions while programmers decide on technical issues is derived from the ideas of Alexander. The rapid type of evolution in XP has its roots in the ideas behind Scrum and the pattern language of Cunningham. The XP idea of scheduling projects based on customer stories is drawn from use cases and the evolutional delivery is adopted from Gilb. Also the spiral model, the initial response to the waterfall model, has had an influence on the XP method. The metaphors of XP originate from the works of Lakoff and Johnson and Coyne. Finally, the physical working environment for programmers is adopted from Coplien and DeMarco and Lister.

Roots of Extreme programming.png

XP aims at enabling successful software development despite vague or constantly changing requirements in small to medium sized teams. Short iterations with small releases and rapid feedback, customer participation, communication and coordination, continuous integration and testing, collective ownership of the code, limited documentation and pair programming are among the main characteristics of XP. The practices of XP are presented in the following according to Beck.

Planning game

Close interaction between the customer and the programmers. The programmers estimate the effort needed for the implementation of customer stories and the customer then decides about the scope and timing of releases.

Small/short releases

A simple system is "productionized" rapidly – at least once in every 2 to 3 months. New versions are then released even daily, but at least monthly.


The system is defined by a metaphor/set of metaphors between the customer and the programmers. This "shared story" guides all development by describing how the system works.

Simple design

The emphasis is on designing the simplest possible solution that is implementable at the moment. Unnecessary complexity and extra code are removed immediately.


Software development is test driven. Unit tests are implemented before the code and are run continuously. Customers write the functional tests.


Restructuring the system by removing duplication, improving communication, simplifying and adding flexibility.

Pair programming

Two people write the code at one computer.

Collective ownership

Anyone can change any part of the code at any time.

Continuous integration

A new piece of code is integrated into the code-base as soon as it is ready. Thus, the system is integrated and built many times a day. All tests are run and they have to be passed for the changes in the code to be accepted.

40-hour week

A maximum of 40-hour working week. No two overtime weeks in a row are allowed. If this happens, it is treated as a problem to be solved.

On-site customer

Customer has to be present and available full-time for the team.

Coding standards

Coding rules exist and are followed by the programmers. Communication through the code should be emphasized.

Open workspace

A large room with small cubicles is preferred. Pair programmers should be placed in the center of the space.

Just rules

Team has its own rules that are followed, but can also be changed at any time. The changes have to be agreed upon and their impact has to be assessed.

Personal tools