XP and Agile Development

by Charlie Calvert

Agile is a Development Strategy or Methodology

Created in large part by Kent Beck
Authors include Beck, Ron Jefferies, Martin Fowler, and Scott Ambler.
Beck's short book Extreme Programming Explained is a good introduction to this subject.
There are many web sites dedicated to this subject. Here are a few of them:
Here is an article on the downside of XP: http://www.softwarereality.com/ExtremeProgramming.jsp
XP is not an academic exercise. It was developed by working consulants.

Agile is a blanket term, and XP is one of the groups that helped form it.
There were several groups with similar strategies, and they came together to form Agile much the way Booch and others joined to forum UML
Other related technologies include Scrum, Crystal, DSDM, and FDD.

The four variables: Cost, Time, Quality, Scope.
In XP, the management picks three of these items to control, the development teams takes the fourth.
If management picks cost, time and money, then the developers tell how much can be done at that quality, in that period of time, and at that cost.

This is probably the one thing for which XP is most famous
Many of the other features of XP could not stand on their own without unit tests
The XP position on unit tests is hard. All the functions of your program should be tested, and tests should be run several times a day.
Write tests first, then write the code.
Eliminate bug hunts.

Never write more code than the minimum you need to make it work.
Assume that there is always a simple solution. Don't start out thinking it will be hard.
Believe there is a simple way.
If you can get 90% of what you want with a solution that is easy, and 100% of what you want with something that is very hard, then consider giving up that last 10%.
When choosing between planning ahead to prepare for a contingency that might come along, and writing something simple that works now, take the simpler path.
Create the simplest possible design that works.

You don't really know what tomorrow will bring, so plan only for today.
Get working code into users hands and let them decide where you should go next.
Most of the time, they change their minds. So why bother planning ahead.
Instead, cover your code with unit tests, and be prepared to change your strategy.
The "learning to drive" analogy.

Working closely with the customer is one of the core values of Agile development
In XP, a customer joins the team, and helps design the product.
Frequent deliveries
The customer knows: Uniqueness from Social Security plus Date.
Oral communication, and results of builds, rather than written documents.
Change direction to meet needs rather than a well defined contract.

You can change your program easily
The unit tests make it possible to change.
What is the cost of change, Is the cost of change always rising as a product gets bigger and closer to release?
The goal of XP and unit tests is to keep the cost of change low, even late in the game.

Two programmers work at a single computer with a single keyboard and mouse
Work in a single open room
Private spaces around the edges of the room for storing gear and making phone calls
Anybody can change any piece of code. No one owns code.

You have to work hard all day, but not more than 40 hours
If you work two weeks in a row for longer than 40 hours, then you need to have a meeting and change plans.
This is not a technology for prima donnas
It is meant to help average development teams

XP frees you from onorous chores such as written documentation and contracts that are like straightjackets.
It puts an emphasis on warm fuzzies, like human communication.
Don't take the easy stuff, and then ignore the hard stuff.
It takes the nice stuff to an extreme, but it also takes the hard stuff to an extreme.
You have to write the tests.
You have to pair program.
You have to put the customer in charge of decisions you want to make yourself.
You have to follow the whole program, not just part of it.