如果你是一位渴望让自己技艺出类拔萃的程序员。这本书就是为你准备的
正确的瀑布式开发方法
看到这本书的开始，终于明白了。为什么现在看来完全是没有道理的瀑布式开发流程，在软件工程的早期，会有人用，而那个时候其实从事软件工程的反而都是那些最优秀的工程师和科学家。
这是一个绝对完全合理的过程。如果需要等到漫长而且昂贵的作为项目核心的专用硬件完成之后，才有可能开始开发有用的软件，而人力物力有限，不可能等着，那么只有做出巨细无遗的分析和设计，只等待硬件完成解答最后的不确定性，才是正确的过程。设计过程占用20%，其实只是充分利用了缓冲时间，而一旦由顶尖工程师和科学家完成高质量、精确到细节的详细设计，到编码阶段就不再需要更多创造力和变更了，这个时候CACE工具是最佳选择，是因为最优秀的人完成了精确的设计，只要确保设计被准确实现就可以达成项目目标。而实现的人其聪明程度又可能不如设计阶段，设计是在非瓶颈的缓冲时间完成，而实现的时候，整个项目都在等待这个过程，压力可想而知。
软件工程的乌托邦
有那么一段时间的软件工程，忽略了工程规模和现实项目进行的个性化特点，将大型项目和科学项目，机械的适用于所有场景，忽略了人的因素，虽然有各种原因，其实人的因素很难把握，而归于机械方法就能解决问题，其实也是所有人期望的，只是可惜现实不是如此。
世界首先不是确定性的，商业就更是这样，如果有一个确定的方法，在某个领域可以确定性的所有人都喜欢，而且用了就一定解决问题，那不是所有人用了就成功，那么世界岂不是一个人人平等的乌托邦；所以对软件工程，任何时代，不管前人如何提醒，奈何乌托邦太美好，所以总还是有很多人期待自己知道什么别人根本想不到的银弹，可以轻松完成项目。但现实是，如大前研一所说，其实任何一个想法，在自己想到的时候，就要有那种觉悟，至少这个世界上已经有几十人也有同样想法了，各方面的人与人的差别，人决定了如何实现。这个本身也是世界有趣的地方。
在现在的软件实践中，为什么还会有人会认可人多力量大这种人月神话，软件工艺中直接认为这是疯狂的想法。想到的是孙子兵法，想到长平之战，廉颇和赵括，现在的人厚今薄古，从结果看是赵国很傻，那么容易就上当，自毁长城；但是在当时，基于经验，恐怕也并非胜负已定，只是基于各种原因的结局，恐怕秦人就算用间，也只是顺水推舟。人月神话肯定听还是听过的，只是这样简单粗暴一点，神话多美好啊。
只是需要回归到项目管理，瓶颈约束理论的思考，其实在航天项目那个时代场景，瀑布就是正确的项目管理；并不妨碍在商业和小型应用上完全是错的。而人多力量大，就和项目周期、缺陷一样问题。
回归人本的思考
软件工艺里，作者用挖洞的例子，我自己经常也思考在一些经历过的商业过程中，这样的思考。首先是商业模式当前瓶颈到底在哪里；只有一个系统，那么多人水平参差不齐怎么沟通协作；特定水平的开发人员，是否项目可以等到招聘培训流程完成一个周期；提前完工就意味着业务马上可以开展吗，系统是否为了提前只是带病完成，如果所有资源还不能同步协同，肯定会造成资源浪费。
所以最终还是需要回归人本，而不是忽略细节之后简单的数学计算。对于项目和开发过程，能够针对具体情境，从常识的角度，全面分析，找出合理流程，用合适的人完成。最终还是各种资源和能力、时间的权衡取舍。
