是采用瀑布模型还是敏捷方法？网站 Scrumology 的站长 David J Blant 认为答案应该取决于对所要解决的问题和方案的了解程度。
David 在他的文章中提出了以下几个观点：
1. 当几乎完全了解所需解决的问题和方案的时候，用敏捷方法还是瀑布模型只是个人口味不同而已。
2. 当几乎完全了解所需解决的问题但对相应的方案知之甚少的时候，敏捷方法行得通，而瀑布模型则不适用。
3. 当对要解决的问题和方案都几乎知之甚少时，敏捷方法行得通，而瀑布模型则不适用。
在文章结尾处，David 总结了他的观点：
敏捷方法与瀑布模型之间的争论旷日持久。短期内没有一方打算退出，但这争吵俨然成了白色噪声 (white noise)。它让我们偏离了真正的问题，即我们是否都清楚要解决的问题或方案。 所以让我们停止把所有的灾难都归咎于瀑布模型，相反大家扪心自问，我们是不是为手头上的工作选择了正确的工具。
此文在 LinkedIn 的敏捷群组中备受关注。起初很多跟帖都赞成 David 的观点，但随着大家的进一步讨论，很多人逐渐清晰地认识到，在软件开发过程中，需要解决的问题和相应的方案都很清晰的情况已经几乎不存在了。比如来自 Chris Shield 的一条评论就谈到：
我认为在软件开发中永远不可能 100% 了解解决方案——永远不会。从第一天开始，就一直有变更，新的假设层出不穷，随后假设再被证明是不成立的，业务部门的新需求姗姗来迟，等等。
Greg Robinson 认为：
软件开发本质上是一个探索和开发的过程，在此过程中，你历经无数潜在方案蜿蜒前行，最终得到一个合适的最佳选择。顺着这个思路，你可以考虑从制造业流程中引入更多实践，比如规划蓝图、与每个人达成共识，但第一次构建就正确无误地完成 (OTOBOS) 是最乐观的情况，也是所有瀑布模型的根本性缺陷。应该说，即使是为一个两周的 sprint 制订计划都很难，更何况是为项目做一年的详细计划了（你现在还打算不折不扣照着所谓的需求文档做一年的计划吗，即使当时它们是正确的？）
其他的评论则讨论了在软件开发过程之初就已经非常了解所要解决的问题和/ 或方案的可能性。然而，似乎能够一致确定的是，瀑布模型和敏捷方法在管理这类的项目时都能占有一席之地。
另外，我们也听到了网上一些不同的声音，包括 Pawel Bradzinski 撰写的博文。他的观点是：人，而不是流程或方法决定了软件开发过程的成功。
另外有些人针对影响软件开发的各种相关因素做了许多深入透彻的分析。 Tom Peplow 就在 2008 年给出过很棒的建议。
查看英文原文： Known vs Unknown
