Extreme Programming emphasizes teamwork. Managers, customers, and developers are all equal partners in a collaborative team. Extreme Programming implements a simple, yet effective environment enabling teams to become highly productive. The team self-organized around the problem to solve it as efficiently as possible.
They are different from traditional requirements specification primarily in details user stories do not contain detailed requirements which are to be uncovered only when the story is to be implemented, therefore allowing the details to be decided as late as possible. Each story is written on a separate card, 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 successfully executed when new code is integrated into the system. There is a short time gap between releases of the system. Figure xp.01 illustrates the XP process to produce an increment of the system that is being developed.
Figure xp.01 The Extreme Programming release cycle
Extreme programming involves a number of practices, summarised in Table xp.02, that fit into the principles of Agile Methods:
- Incremental development is supported through small, frequent releases of the system and by an approach to requirements description based on customer stories or scenarios that can be the basis for process planning.
- Customer involvement is supported through the full-time 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.
- People, not process, are supported through pair programming, collective ownership of the system code, and a sustainable development process that does not involve excessively long working hours.
- Change is supported through regular system releases, test-first development and continuous integration.
- Maintaining simplicity is supported through constant refactoring to improve code quality and using simple designs that do not anticipate future changes to the system.
Principle or practice
|
Description
|
Incremental Planning
|
Requirements are recorded on
Story Cards and the Stories to be included in a release are determined by the
time available and their relative priority. The developers break these
Stories into development "Tasks".
|
Small Releases
|
The minimal useful set of
functionality that provides business value is developed first. Releases of
the system are frequent and incrementally add functionality to the first
release.
|
Simple Design
|
Enough design is carried out to
meet the current requirements and no more.
|
Test-first Development
|
An automated unit test
framework is used to write tests for a new piece of functionality before that
functionality itself is implemented.
|
Refactoring
|
All developers are expected to
refactor the code continuously as soon as possible code improvements are found.
This keeps the code simple and maintainable.
|
Pair Programming
|
Developers work in pairs,
checking each other’s work and providing the support to always do a good job.
|
Collective Ownership
|
The pairs of developers work on
all areas of the system, so that no islands of expertise develop and all the developers
own all the code. Anyone can change anything.
|
Continuous Integration
|
As soon as work on a task is
complete it is integrated into the whole system. After any such integration,
all the unit tests in the system must pass.
|
Sustainable Pace
|
Large amounts of overtime are
not considered acceptable as the net effect is often to reduce code quality
and medium-term productivity.
|
On-site Customer
|
A representative of the
end-user of the system (the Customer) should be available full time for the
use of the XP team. In an extreme programming process, the customer is a
member of the development team and is responsible for bringing system
requirements to the team for implementation.
|
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 encapsulates the customer needs. The development team then aims to implement that scenario in a future release of the software.
Related Posts :
Software Development Life Cycle
Software Development Process
Waterfall Model
Agile Model
Prototyping Model
Iterative Model
Spiral Model
Software Development Life Cycle
Software Development Process
Waterfall Model
Agile Model
Prototyping Model
Iterative Model
Spiral Model