Shane Hathaway <[EMAIL PROTECTED]> writes:
>
> 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.
I think you're exactly right here. The 'waterfall' method encompasses
all the things you need to do to have a successful product. Its
failing, however, is the strict ordering it places on them. Agile
methods generally provide a structure for doing multiple waterfall
phases at once, so that you can quickly discover the inevitable flaws
in your execution of those phases.
>
> 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.
I also think it's useful to think of software methods as project
management paradigms that are somewhat analogous to how we use
programming paradigms. Just as it's possible to write a program in
assembly language with no pre-planned or particularly evident
structural patterns and have it work properly, it's possible to run a
software development project without any particular management
pattern. However, you can get a lot of benefit both while you're
programming/managing and in later analysis of how you did if you
follow some sort of a design/management paradigm, such as OOP or an
Agile process.
--Levi
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
