最近看了本书叫Manage Project with Growth,从理论上解释了为什么瀑布式模型不适用于软件开发，以及为什么这样的模式还在大量被采用。

　　瀑布模型，也就是先计划然后收集需求、然后分析、然后设计、然后编码、然后测试的开发模式，这起源于其他类别的工程学，如建筑和机械生产，软件工程出现的比这些硬件工程晚的多，没有办法，一开始只有学习其他工程的份，但是到了二十一世纪，还是对这种生产方式执迷不悟，就太不应该了。

　　二十世纪初一个Taylor的美国人对生产过程做了细致的研究，这哥们出生贵族，他认为原有的生产方式很大的弊端是manager不是管理，只是在监督，工人完全按照自己的方式生产，Taylor认为manager有责任了解工作性质，指定出严格的process，工人不能自己想怎么干就怎么干，需要按照统一的process来工作，简而言之，即使manager动脑，工人出力。Taylor的观点被称为Talyorism，通过实践证明这种观点在生产性的工业中是正确的，软件工程的前辈们自然而然的就将Talyorism应用到软件开发中了。

　　Talyorsim对可以预见结果的生产是适用的，之可惜软件生产有其不同于其他工业的特点。软件生产不是简单的，如果硬件能够达到软件的复杂性的话，还需要软件干什么;软件生产不是可重复的，汉堡包可以被用同样的方式生产无数次，但是每一次软件开发几乎有不同的问题需要解决......

　　传统的工程学基于这样的假设，生产过程是线性的，即有这样的特点

　　1) 结果是输入之和;

　　2) 小的改变只产生小的影响;

　　3) 结果是可以预测的。

　　但是软件开发不是简单系统，不是线性的。根据混沌理论，非线性的过程结果是无法预料的，因为一点点的输入改变可能产生巨大的结果改变(此书作者一定是一个工程师出生，引经据点都是工程师的经历和口吻，提到1986年MIT一个气象研究者最早发现混沌现象)。

　　既然软件开发是一个混沌过程，那么一开始所谓周详的计划，再到周详的需求分析，还有周详的设计文档，都价值不大，因为一个小小的改变就让大量的人力投入变成白费劲。还好混沌的过程不是完全失去控制的，有的情况下开始的工作多少还是有点作用，但是某些时候(不幸的是这样的时候很多)会产生重创。

　　但是很多软件项目的manager为什么还是用老式的工程方法来管理项目呢?此书通过心理学分析，引文manager需要心理上的安慰，通过制定不切实际的计划，获得“项目在可控制之中”的心理暗示，如果实际项目没有按照计划进行，出现延误现象，可以说“没有做好计划“，于是陷入寻找一种指定”好计划“的陷阱，殊不知，绝大多数情况下，更本不可能一开始就指定出”好计划“，随机应变才是最好的计划。

　　项目失败的时候，manager可以说，我已经指定了计划，只不过计划没有切实得到执行;如果项目成功哦你了或者勉强成功了，mananger又会说，计划发生功效了。似乎这样的生产方式永远能够存活下去，这种方式能够存活是因为在一定范围内普遍还是采用这种方式，敌我都有伤亡，如果有一支力量能够打破这种局面，采用先进的方式，获得更高的生产力，整个行业的生产方式就有可能得到改变。

　　至于什么是先进的方式，莫衷一是。个人认为对绝大多数软件开发，迭代式(iterative)开发是正途。不完全抛弃计划，但是不要一开始指定死板不切实际的计划，制定just enough的计划，然后随着项目的推进不断的完善计划。迭代式开发也不是银弹，也有陷阱，再说了。