SoftwareGR

Shawn Crowley, Atomic Object

The advantages of an agile approach: Traditional development methods (many requirements up front) often miss the deadline because they don’t give a good indication of development velocity.

The customer has no idea of what the real development velocity of the project is going to be until development starts.

Because of the lengthy requirements phase in traditional project schedules, the customer may not realize they are going to blow a deadline until they have already invested a significant amount of money.

Agile processes give the customer more decision making power . A project’s development velocity can be seen right away, giving the customer a better indicator if they are going to hit their date. This timely information call allow the customer to take controlled actions like:

• Reduce scope
• Extend schedule

Usually hitting the date is the most important because being on time is what most people will remember.

Importance of tests:

One of the most important things to the customer is for the development effort to be predictable. The best way to be predictable is to have running tested features. It is import to look at a burn down chart as running, tested, features. Without tests you may be putting defects (negative features) into the software. Your curve may not be where you think it is if there are defects lurking in the software. A possible remedy for a lack of tests is putting a block of time for testing into the schedule after development. The trouble with adding a testing phase is that no one has a real indicator of how long the testing phase will take.

It is important to have to layers of testing. Unit tests provide a way for the developer to know that their code is doing what they think it is doing. Units tests are not enough though because they do not assert what the customer wants as features (that is the job of system tests).

System tests (automated customer tests) need to be part of the feedback loop between the customer and the developer. These tests will tell that a feature is done. When a feature is too large, try to reduce the scope of the story to a minimal thing that the customer can recognize as progress. Bugs are easier to identify when the scope of a feature is smaller.

Refactoring:

The software’s design should follow the growth of the features. No frameworks up front. If a design is good enough for today, is good enough to add one more feature. After a feature is put into the software, see if it adds an ugly blob to the software and refactor it if it does.

A design that is inadequate for tomorrow is inadequate for today. Don’t sit with bad design when adding features (refactor as necessary).

Most important development skills:

• Small features
• Short iterations
• Testing
  • Test driven development
  • Customer acceptance testing
• Refactoring

A video of Ron Jeffries’ presentation is available on Google Video.