Slashdot Mirror
Mixing Agile With Waterfall For Code Quality
jones_supa writes: The 2014 CAST Research on Application Software Health (CRASH) report states that enterprise software built using a mixture of agile and waterfall methods will result in more robust and secure applications than those built using either agile or waterfall methods alone. Data from CAST's Appmarq benchmarking repository was analyzed to discover global trends in the structural quality of business application software. The report explores the impact of factors such as development method, CMMI maturity level, outsourcing, and other practices on software quality characteristics that are based upon good architectural and coding practices. InfoQ interviewed Bill Curtis, Senior Vice President and Chief Scientist at CAST, about the research done by CAST, structural quality factors, and mixing agile and waterfall methods.
Having done pretty much what this article is calling for. Dont do it.
Both methodologies work. They are however like oil and water. It allows for sloppy planing with the idea you can change it later. It does not work. Even with agile you want some sort of end goal plan. But not all the details worked out. With waterfall you try to figure out all the details and usually get them wrong or forget what you were doing 2 years ago.
You will end up with the worst of both methodologies all in one nice neat package.
If you are outsourcing you want a waterfall as you need nice neat checkpoints of saying if your external vendor did the work at all and should be paid. If you are doing internal work agile can work very nicely *IF* your organization is ready for it. If the rest of your organization does waterfall you will end up with a blend that does not work.
The two do not mix. If you do it you will suffer.
Aerospace is one of the most conservative coding industries out there. We've found a combination of waterfall and agile that works. We use agile for UI development within each waterfall. It turns out that, in spite of decades of human factor research, getting UIs right is very, very hard. So, we've been using a mixture of agile for the UI itself, and waterfall for everything else, and only pushing the UI to certification when a build is going forward. This allows us to (forgive me, engineers) unfuck what the engineers dreamed up, get to a useful interface, and then still have some time to fix (really reverse engineer) the design documents to get them to match the UI. This has worked very well.