Waterfall vs Agile: Development and Business
FYI:
The second part of the post Waterfall Vs Agile, has just been published in DZone, follow the link to read it…
Waterfall vs. Agile: Development and Business
Related posts:
FYI:
The second part of the post Waterfall Vs Agile, has just been published in DZone, follow the link to read it…
Waterfall vs. Agile: Development and Business
Related posts:
I think that’s a good summary. However I have to disagree with at least one point. Let me preface by saying that I’m not advocating waterfall nor agile. I personally think they both have their places.
“It[agile] is also very strong on engineering practices (TDD, pair-programming, refactoring, etc)”
Now maybe this disagreement has more to do with what is software engineering, but from a broader engineering perspective, you see very little of this.
I’ve got a degree in electrical engineering, have worked my entire professional career and a few internships with engineers (electrical and mechanical mostly.) Most engineers would be classified as a waterfall method, as opposed to agile.
In fact, this is often mentioned in the agile works. Civil engineers (for example) start knowing a big chunk of the requirements to the buildings they are making. Because if they think they’re making a 5 story building, that causes a different foundation than a 50 story building.
Obviously with software, it’s easier to adapt to changes. But I think waterfall is truly more of an engineering process than agile. Unless, of course, we are to say that software engineering is so fundamentally different than every other engineering discipline that it needs to take an almost polar-opposite approach.
Nate
15 Jun 10 at 2:37 pm