Agile Development vs Traditional Development
2009-01-16 10:23:45
Traditionally, software development has always progressed through 4 steps. These steps, the so called 4 Ds process, consist of:
- Discovery
- Design
- Development
- Delivery
Many development companies try to shortcut the areas they don't have as much expertise with, which generally means that the first two steps are abridged or even completely missing. They attempt to make up for this, but going back over and over again thorough many versions at the development stage to try to nail down what the customer actually meant in the first place. They label this 'technique' as agile development.
While this is a perfectly valid method for some small projects, especially where the programmer and tester are one and the same, it seldom copes with anything with any complexity. If your requirements are complex, such as having legal or contractual requirements, then its rare that agile development can work effectively without taking on some of the traditional processes aspects.
Requirements are important. Without requirements how do you know when the system does what you need? How will the programmer know when to stop? When do you stop adding 'just one last feature'? The answer is you can't know any of these things for sure without setting goals, goals are produced from requirements and without discovery, even in an abridged form, you wont have any requirements suitible for setting proper goals.
I am sure many people reading this are either agreeing or disagreeing with me. To the people disagreeing with what I have wrote: if you are managing to make agile development work without any real requirements analysis, then I will be very suprised. Even if you aren't putting it down on paper, you are probably taking much more of the traditional approach into your cycle than you are letting on.
To the people that do agree... congratulations :)
[EDIT: Some people have taken this to mean I am completely against iterative development. I am for any development style that doesn't skimp on trying to understand what the customer means. Internally, TractionThroughAction uses an iterative model, its just our cycles (for our own products) are a lot longer than the generally accepted norms for 'agile' development.]