Development Methods in the real world.
shane at hathawaymix.org
Tue Sep 25 22:37:40 MDT 2007
> I have seen companies that are using Agile, Scrum, XP, Waterfall,
> Feature Driven Development etc.
> In preparation for interviews I have been doing research on every
> development methodology I can find, trying to figure out what these
> are really all about.
Historically, the majority of software development projects have been
late, over-budget, and incomplete. All of these methodologies aim to
reverse this trend.
The waterfall methodology was developed at IBM. IBM used it for all
their projects, but in the end it proved costly and not adaptable.
Today IBM generally encourages everyone to avoid it. Most of the new
methodologies are a reaction to the flaws in the waterfall methodology.
OTOH, many elements of waterfall methodology are as important and true
as ever, so there is a lot to learn from waterfall.
The most important thing the methodologies address is how to build a
strong relationship between customers and the software development
organization. They emphasize communication. For example, an iteration
is not complete without a meeting with the customer discussing that
> It seems to me that most if not all of these "methods", are really
> just buzzword filled metaphors management is using, and most can be
> summed up in two words. "Micro Management".
No. Micro management is being hounded. By contrast, a good software
development methodology helps the creative juices flow while reassuring
the customer that their money is well spent.
> It appears that there are really only 2 distinct development methods,
> really differing only in the order in which things are done.
> Large Scale Development (LSD), Here you layout in detail everything
> that a project should be/do in advance in as much detail as possible,
> and work towards a single large monolithic goal. I can see this as
> useful for large projects where the design requirements are unlikely
> to change, and requirements can easily be set forth in advance. I may
> be wrong here, but I think they generally call this the "Waterfall"
Yes, although it is problematic even for large projects.
> Iterative Development (ID), In ID you have a generalized end goal, and
> you break it down into a series of milestones or iterations, then set
> a time table for release of each milestone. This is what I've been
> the most involved in, and it seems to fit my programming style much
> better. The advantage here is that design requirements can change
> easily and you are able to quickly adapt between iterations. I'm
> thinking this is the closest thing to Agile development that I have
> actually done.
That's the way it looks to a coder, but you're leaving out the customer
communication details. To understand the differences between different
methodologies, you must consider the patterns of communication with the
customer. When communication with a customer breaks down, you can often
fix the communication patterns by modifying the development methods.
More information about the PLUG