Agile programming¶

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.