Page 82 -

3.3 Extreme programming 65

Select User
Break Down
Stories for this Stories to Tasks Plan Release
Release

Figure 3.3 The extreme Evaluate Release Develop/
programming release System Software Integrate/
cycle Test Software

In extreme programming, requirements are expressed as scenarios (called user
stories), which are implemented directly as a series of tasks. Programmers work in
pairs and develop tests for each task before writing the code. All tests must be suc-
cessfully executed when new code is integrated into the system. There is a short time
gap between releases of the system. Figure 3.3 illustrates the XP process to produce
an increment of the system that is being developed.
Extreme programming involves a number of practices, summarized in Figure 3.4,
which reflect the principles of agile methods:

1. Incremental development is supported through small, frequent releases of the
system. Requirements are based on simple customer stories or scenarios that are
used as a basis for deciding what functionality should be included in a system
increment.
2. Customer involvement is supported through the continuous engagement of the
customer in the development team. The customer representative takes part in the
development and is responsible for defining acceptance tests for the system.

3. People, not process, are supported through pair programming, collective owner-
ship of the system code, and a sustainable development process that does not
involve excessively long working hours.
4. Change is embraced through regular system releases to customers, test-first
development, refactoring to avoid code degeneration, and continuous integra-
tion of new functionality.
5. Maintaining simplicity is supported by constant refactoring that improves code
quality and by using simple designs that do not unnecessarily anticipate future
changes to the system.

In an XP process, customers are intimately involved in specifying and prioritizing
system requirements. The requirements are not specified as lists of required system
functions. Rather, the system customer is part of the development team and discusses
scenarios with other team members. Together, they develop a ‘story card’ that encap-
sulates the customer needs. The development team then aims to implement that sce-
nario in a future release of the software. An example of a story card for the mental