第2章-人月神话
2.1为什么项目会滞后
缺乏合理的时间进度是造成项目滞后的最主要原因
实际上这是一句矛盾又合理的话：
矛盾的点在于，我们总是已经估算了项目的时间，对于项目需要的功能和模块都进行了划分。每一个部分我们都给了必要的时间安排。按道理来说，其实不应该出现时间上的问题而导致项目滞后
但是这句话却又很合理：既然延后了，一定是我们的安排有问题
2.2安排的不合理
那么安排为什么不合理？我认为比较核心的几点是：
- 所有的编程人员都是乐观主义者:“一切都将运作良好”。
- 我们的构思本身是有缺陷的，因此总会有bug
- 人月神话
- 沟通与培训的工作量
对于第一点，软件开发的从业者应该都有很深的体会。每当我们的程序出现BUG的时候，我相信大部分人的第一反应都是：“不会吧，我写的代码应该没什么问题啊”。实际上这就是一种盲目的自信。
第二点也是人类为什么要应用计算机的其中一个原因：人会犯错。即便是其他已经工程化的领域，有着非常成熟的流程和技术的领域，实际上人们还是有可能犯错。我们偶尔会看到一些航天器的坠毁，一些化学仓库的爆炸。
更重要的一点是人月神话。软件的开发也是有自己的规律的。母亲十月怀胎能孕育一个生命，那么10个母亲能一个月内孕育出一个生命吗？显然是不行的。但是实际上，对于没有足够经验的软件开发管理者而言，这一点非常容易混淆
对于第四点，实际上开发的工作量比较容易估算，但是沟通与培训的工作量是很难以估算的——我个人认为这还是依赖于管理者丰富的经验。就像Brooks在本书中提到的一些数据，集成测试需要的时间远比人们想的要多。但是在实际的项目开发过程中，留给集成测试的时间实际上非常的少，大多数人估算的只是开发出单个模块的时间——甚至于对这个问题的估算也会偏少
2.3Brooks法则
Brooks法则：为进度落后的项目增加人手,只会使进度更加落后。
没什么经验的项目经理总是会犯这样的错误：当项目进度落后的时候，着急忙慌地招揽更多的人，试图用人数的“优势”来让项目及时完成。而实际上，这样的实践并不可能成功。
仅以我们平日里编写程序的经验而言，我们在看别人的程序的时候，往往比我们从头写这个程序所需要花费的时间更多——因为代码某种意义上来说也属于一种“艺术品”，我们拿着同样的工具，但却有着完全不一样的思维。那么用于统一思想和沟通交流的代价就会明显地显得特别高。对于一个已有的项目来说，显然加入更多对于这个项目不熟悉的人显得没有一点帮助
标签：估算,项目,Brooks,实际上,我们,神话 From： https://www.cnblogs.com/fuchuchu/p/17277563.html