Extreme Programming (XP)
A late 90's development based on the RAD ideas
- Keep it simple, build it quick, make it work
- Analogies between software engineering and other engineering are false
- our customer's requirements change more frequently
- our products can be changed and altered more easily
- the ratio of design cost to build cost is already much higher
- history shows that software design diagrams are often not helpful
in producing a reliable design
- if we consider coding as "design" and compile and link as "build"
- the "build" task is so quick and cheap it should be considered
instant and free
- almost all software development is design
- the coding work becomes analagous to the up-front design effort
we expect of an engineering discipline
- Software developers must be allowed to do their job with the minimum
of bureaucratic interference (as with RAD)
- traditional methodologies are too bureaucratic
- some rules are good
- but more rules don't mean "better"
What is special about XP?
Communication, Feedback, Simplicity, and Courage
We design by coding
- programmers meet and communicate with customers regularly
- testing is the start point, not the end point
- for each unit the programmer designs the test first
- when the unit is ready, the test is run automatically
- the design is kept simple
- the design meets known existing requirements, not all possible future functionality
- Beck (1999): "If you believe that the future is uncertain,
and you believe that you can cheaply change your mind,
then putting in functionality on speculation is crazy.
Put in what you need when you need it."
- programmers always work in pairs (considered more productive)
- the system gets released regularly in small increments
- customers are allowed to suggest improvements
- redesigns are common - what they call refactoring - and handled easily
eAD (2000): "If changes are continuous, then we'll never get an up-front design completed.
Furthermore, as changes become more unpredictable -- a great likelihood today --
then much anticipatory design likely will be wasted."
XP and project management
Each element of functionality is called a story, and each one is written
on a card. The project scope and plan is simply and efficiently created by
manipulating the cards by hand. Progress monitoring is achieved by tracking
the unit test for each story.
Quality is assured by two main themes. Paired programmers ensure learning,
adherence to standards, and avoidance of errors. Unit tests are core to coding
and are designed before writing the code. The programmers are responsible for
proving to the customer that each unit works correctly, rather than the customer
having to prove that it doesn't work. See Hutcheson (2004) for a discussion
of software testing in XP projects.
Efficiency is gained through
- minimal bureaucracy;
- focus on delivering quickly;
- focus on getting it right first time;
- only documentation: cards and source code;
- not trying to predict all possible future changes;
- handling current changes easily;
- testing automated;
- metric collection automated;
- progress monitored by following story cards and test results.
Wells, J. D. (2002)
Extreme Programming: A gentle introduction,
Jim, eAD (2000) Extreme Programming. Article in "eAD - e-business Application
Delivery" by the Cutter Consortium
Beck, K. (1999) Extreme Programming Explained: Embrace Change. Addison-Wesley
E. (2002) Extreme Programming vs. Interaction Design: When two development design
visionaries meet, there's room for consensusóbut not much. Fawcette Technical
Hutcheson, M. L. (2004) Testing
in the eXtreme Programming (XP) Paradigm: A Case Study". Article in
TickIT International, ISSN 1354-5884
Agile methods in general
The New Methodology, Martin Fowler, Chief Scientist, ThoughtWorks
Manifesto for Agile Software Development,
The Agile Alliance.
At the Edge:,
Information Architects, Inc.