Extreme programming
Extreme programming is a so-called light-weight methodology. It basically
takes some good programming practices (testing your code, listening to the
customer, refactoring) and takes them to the extreme:
- All code should be tested (not the trivial 1+1=2 things
though). Automatically. The tests should always run at 100%. These are
called “unit tests” because you test small programming units. The unit tests
ensure that there’s always a running system, however embryonically in the
beginning.
- Customer requirements are translated (as much as feasible) to automated
“functional tests”. A simple graph showing “number of functional tests” and
“number of passed tests” against the time provides the best view on the
project’s progress.
- The customer writes so-called “stories” that describe pieces of
functionality desired of the system.
- The customer organises these stories according to importance, the most
important ones implemented first. This assures you get good business value
fast.
- Development is done in iterations. Every 2 or 3 weeks (longer or shorter if
needed) the customer picks the new stories to be implemented. The developers
estimate the time needed to implement the story and the customer isn’t
allowed to pick more than there’s time for.
- Releases are longer-term milestones. The dates can be picked randomly or can
be prescribed by external deadlines. The unit tests ensure a working product
all the time, so a release is more a milestone to encourage polishing
activities as packaging, install docs, etc. Releases (according to XP)
should never be postponed.
