瀑布模型已被实践证明不适用于大多数软件开发项目。如果有项目可以使用瀑布模型，它也可以使用更先进的开发模型来获得更好的效果。事实上，仍有许多项目使用瀑布模型开发，相应的事实是，一半的软件开发项目可以被称为失败。 最近读了一本叫做的书Manage Project with Growth,理论上解释了为什么瀑布模型不适合软件开发，为什么它仍然被广泛使用。 瀑布模型，即计划然后收集需求，然后分析，然后设计，然后编码，然后测试开发模式，起源于其他类别的工程，如建筑和机械生产，软件工程比这些硬件工程晚得多，没有办法，只学习其他工程，但在21世纪，或对这种生产模式，太不合适了。 二十世纪初一个Taylor美国人对生产过程进行了详细的研究。这个兄弟出生在贵族身上。他认为最初生产方法的主要缺点是manager不是管理，只是监督，工人完全按照自己的方式生产，Taylor认为manager有责任了解工作性质，指定出严格的process，工人不能做他们想做的事，需要统一process简而言之，即使你来工作，manager动脑，工人出力。Taylor这个观点叫Talyorism，通过实践证明，这点在生产性行业是正确的，软件工程的前辈自然会Talyorism应用于软件开发。Talyorsim适用于可预测结果的生产。不幸的是，软件生产不同于其他行业。软件生产不简单。如果硬件能达到软件的复杂性，软件还需要做什么；软件生产不可重复。汉堡可以以同样的方式生产无数次，但每个软件开发几乎都有不同的问题需要解决... 基于这样的假设，传统工程的生产过程是线性的，即 1) 结果是输入之和； 2) 小变化只产生小影响； 3) 结果是可以预测的。 但软件开发不是简单的系统，也不是线性的。根据混沌理论，非线性过程的结果是不可预测的，因为一点点的输入变化可能会产生巨大的结果变化（作者必须是工程师，引用的基础是工程师的经验和语气，提到1986年MIT气象学研究人员首先发现了混乱现象）。 由于软件开发是一个混乱的过程，所谓的详细计划，到详细的需求分析和详细的设计文档都没有什么价值，因为一个小的变化使大量的人力投资变得徒劳。幸运的是，混乱的过程并没有完全失去控制。在某些情况下，开始的工作仍然有点有效，但有时（不幸的是，很多时候）会造成严重的损失。 但许多软件项目都是manager为什么要用旧的工程方法来管理项目？本书通过心理分析和引文manager需要心理安慰，通过制定不切实际的计划，获得项目可控的心理暗示，如果实际项目不按计划，延误现象，可以说计划不好，所以陷入寻找指定的好计划陷阱，大多数情况下，更不可能指定好计划，随机适应是最好的计划。 项目失败时，manager可以说，我已经指定了计划，但计划还没有实施；如果项目成功了，哦，你还是勉强成功了，mananger这个计划又有效了。这种生产模式似乎总是可以生存的，这种方式可以生存，因为在一定范围内或使用这种方式，敌人和我都有伤亡，如果有一个力量可以打破这种情况，使用先进的方式，获得更高的生产力，整个行业的生产模式可能会改变。 至于什么是先进的方法，我不同意。我个人认为，绝大多数的软件开发，迭代(iterative)发展是正确的方式。不要完全放弃计划，但不要在一开始就指定死板和不切实际的计划，制定计划just enough随着项目的推进，计划不断完善。迭代开发不是银弹，而是陷阱。