第一章 焦油坑
表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被
解决，但是当它们相互纠缠和积累在一起的时候，团队的行动就会变
得越来越慢。对问题的麻烦程度，每个人似乎都会感到惊讶，并且很
难看清问题的本质。不过，如果我们想解决问题，就必须试图先去理
解它。 -- 清楚地解释系统开发的困难所在。
这，就是编程。一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共
存的创造性活动。对于许多人而言，其中的乐趣远大于苦恼。而本书
的剩余部分将试图搭建一些桥梁，为通过这样的焦油坑提供一些指导。
-- 本书的目的
第二章 人月神话
1. 在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还大。导致灾难的原因是：
首先，我们对估算技术缺乏有效的研究。
第二，我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆
第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工作。
第四，对进度缺少跟踪和监督。
第五，当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。
2. 系统开发过程中，乐观主义并不应该是理所应当的。
在单个任务中，“一切都将运转正常”的假设在时间进度上具有可实现性。因为所遇的延迟是一个概率分布曲线，“不会延迟”仅具有有限的概率，所以现实情况可能会像计划安排的那样顺利。然而大型的编程工作，或多或少包含了很多任务，某些任务间还具有前后的次序，从而一切正常的概率变得非常小，甚至接近于无。
3. 成本的确随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。
因为软件开发本质上是一项系统的工作--错综复杂关系下的一种实践--沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。
4. 在时间进度中，顺序限制所造成的影响，没有哪个部分比单元测试和系统测试所受到的牵涉更彻底。
对于任务的进度安排，以下是作者使用了很多年的经验法则：
1/3 计划
1/6 编码
1/4 构件测试和早期系统测试（单元测试）
1/4 系统测试
5. 如果发现项目的实际进度滞后于预计的进度，项目经理最好的办法是重新安排进度，而不是增加项目人手。
6. 项目的时间依赖于顺序上的限制，人员的数量依赖于单个子任务的数量。从这两个数值可以推算出进度时间表，该表安排的人员较少，花费的时间较长（唯一的风险是产品可能过时）。相反，分派较多的人手，计划较短的时间，将无法得到可行的进度表。总之，在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还要大。
