Page 25 - DCAP304_DCAP515_SOFTWARE_PROJECT_MANAGEMENT

Unit 1: Introduction to Software Project Management

eXtreme Programming (XP) Notes

XP is a software engineering technique that has been formulated in 1996 by Kent Beck. XP has
received fair media attention, and is most renowned for its practices that are sometimes regarded
as contentious, such as pair programming and test-driven development. In this document, we
will not concern ourselves with these aspects of eXtreme Programming, but instead we will
focus on the management part.

Principles of XP

XP aims to decrease the risk involved in software development. In particular, it aims to reduce
the cost of delaying design decisions. In XP, Beck gives a treatment of the cost and revenues of
design decisions and aspect implements (which he calls ‘options’), and he concludes that it is
more beneficial to delay options of which it is uncertain whether they will generate revenue (i.e.
there is a certain amount of risk involved in implementing the option).
Usually, the cost of making decisions about (and therefore changes to) a software project would
rise exponentially during the course of development. It would therefore be costly to defer
options, because implementing them later on might be too costly, and perhaps even cost more
than the value of the option would be.

XP decrease the cost of making modifications later on during development, and thereby allows
decisions that entail high risk to be deferred until a sound judgment can be made on them.

Planning

An XP project is made up of releases. The first release aspires to produce an initial, working
version of the product. The succeeding releases add functionality to the project, change behavior
and fix bugs. An XP project typically lasts the entire lifetime of the application: the software is
constantly tweaked and updated to be as useful as probable. Of course, this approach is not
required: the project can be ended when the customer decides the product is ‘finished’. There is
typically one to three months time between releases. Each release is divided up iterations.
Generally, they are one to three weeks in length. In an XP project, requirements are not fixed in
advance. At the start of the project, or whenever he can think of one, the customer writes down a
desired aspect in a so{called user story, which clarifies the feature by means of a typical ‘use case’.
At the start of the project, a release arrangement is drawn up. First, all stories are written by the
customer. The growth team then assigns a cost to each story. This cost should be one, two or
three ‘ideal programming weeks’ for a single developer. If the cost is better, the story should be
split up. If the cost is less, multiple stories should be merged together. The stories are then
divided over a number of releases. Release dates can then be calculated from the stories assigned
to each release, or the stories can be divided such that fixed release dates will be met. For this,
you will need to estimate how to convert ideal programming weeks to calendar weeks. The first
time, this will be hard (and estimates might be off), but as the project progresses the estimates
will become better.

At the start of each iteration, the customer chooses the stories from that release that are of the
greatest value to him, which will be implemented during the iteration. The stories are then
broken up into smaller units called tasks. Each developer has the opportunity to assume
accountability for a number of tasks. The tasks are then estimated, in ideal programming days,
by the developer that chose them (making sure no-one has too much or too little to do), and
implemented during the course of the iteration. Experience from an iteration or a release, such
as the perfect programming time realized, can be taken into account to estimate better next
release or iteration planning.

LOVELY PROFESSIONAL UNIVERSITY 19