Steve wrote: > 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 iteration. > 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" > method. 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. Shane /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
