外观
01.焦油坑、人月神话
第1篇 焦油坑
过去几十年的大型系统开发就犹如一个焦油坑，很多大型和强壮的动物在其中剧烈地挣扎。他们中大多数开发出了可运行的系统——不过只有极少数的项目满足了目标、进度和预算的要求。各种团队，大型的或小型的，庞杂的或精干的，一个接一个地淹没在了焦油坑中。表面上看起来好像没有任何一个单独的问题会导致困难，每个问题都能获得解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢。对于问题的麻烦程度，每个人似乎都会感到惊讶，并且很难看清问题的本质。不过，如果我想解决问题，就必须试图先去了解问题。
因此，首先让我们来认识一下系统开发这个职业，以及充满在这个职业中的乐趣和苦恼吧！
Part 1 编程系统产品
Part 2 职业的乐趣
首先，一种创建事物的纯粹快乐。
其次，来自于开发对他人有用的东西。劳动成果能够被他人使用，并能对他们有所帮助。
第三，将相互啮合的零部件组装在一起，让以精妙的方式运行着，并收到了预期的效果。
第四，持续学习的快乐。
最后，来自于在易于驾驭的介质上工作。
Part 3 职业的苦恼
首先，来自追去完美。
其次，由他人设定目标、供给资源和提供信息。
第三，寻找琐碎的bug。
最后，即将完成时，已经有些过时。
产品开发所基于的技术在不断的进步。
作者总结
1.1 编程系统产品（Programming Systems Product）开发的工作量是供个人使用的、独立开发的构件程序的九倍。我估计软件构件产品化引起了 3 倍工作量，将软件构件整合成完整系统所需要的设计、集成和测试又强加了 3 倍的工作量，这些高成本的构件在根本上是相互独立的。
1.2 编程行业“满足我们内心深处的创造渴望和愉悦所有人的共有情感”，提供了五种乐趣：
- 创建事物的快乐
- 开发对其他人有用的东西的乐趣
- 将可以活动、相互啮合的零部件组装成类似迷宫的东西，这个过程所体现出令人神魂颠倒的魅力
- 面对不重复的任务，不间断学习的乐趣
- 工作在如此易于驾驭的介质上的乐趣——纯粹的思维活动，其存在、移动和运转方式完全不同于实际物体
1.3 同样，这个行业具有一些内在固有的苦恼：
- 将做事方式调整到追求完美，是学习编程的最困难部分
- 由其他人来设定目标，并且必须依靠自己无法控制的事物（特别是程序）；权威不等同于责任
- 实际情况看起来要比这一点好一些：真正的权威来自于每次任务的完成
- 任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外
- 人们通常期望项目在接近结束时，(bug、工作时间)能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢
- 产品在即将完成时总面临着陈旧过时的威胁
第2章 人月神话
在众多软件项目中，缺乏合理的进度安排是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还要大。导致这种灾难如此普遍的原因是什么呢?
首先，对估算技术缺乏有效的研究，它反映了一种悄无声息但并不真实的假设 --- 都将运作良好。
第二，采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆。
第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地估算这项工作。
第四，对进度缺少跟踪和监督。在其他工程领域中，经过验证的跟踪技术和常规监督程序，在软件工程中常常被认为是大胆的革新。
第五，当意识到进度的偏移时，下意识(以及传统)的反应是增加人力。从而进入了一场注定会导致灾难的循环。
Part 1 乐观主义
系统编程的进度安排背后第一个错误的假设是：一切都运作良好，每一项任务仅花费他所“应该”花费的时间。
- 倾向于去责怪那些物理介质，而不反思自己设定的思路。
- 创造性活动分为三个阶段：构思、实现、交流。
① 构思或者模型的产生。
② 借助纸笔实现他们。
③ 与他人的思想相互沟通，创造过程从而得以结束。
- 编程人员的介质比较容易掌握，所以期待在实现过程中不会碰到困难。
- 在大型编程工作，会有很多任务，优先级高低，这些使得一切正常的概率变得非常小。
Part 2 人月
第二个谬误的思考方式是在估计和进度安排中使用的工作量单位：人月（暗示着：人员数量和时间是可以相互替换的）
- 成本的随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。
- 用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。
- 因为软件开发本质上是一项系统工作 --- 错综复杂关系下的一种实践，沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。从而，添加更多的人手，实际上是延长了而不是缩短了时间进度。
Part 3 系统测试
- 在进度安排中，由于顺序限制所造成的影响，单元调试和系统测试所受到的牵涉更彻底。
- 系统测试进度的安排常常是编程中最不合理的部分。
① 需要的时间依赖于所遇到的错误、缺陷的数量及其难以捕捉的程度。
② 由于乐观主义，实际出现的缺陷要比预料的要多的多。
- 对于任务进度的安排，以下是经验法则：
1/3 计划
1/6 编码
1/4 构件测试和早期系统测试
1/4 系统测试，所有的构件已完成
- 在许多重要的方面，它与传统的进度安排方法不同：
① 分配给计划的时间比平常的多。即便如此，其只是勉强产生详细和稳定的计划规格说明，并不足以容纳对全新技术的研究和探索；
② 对所完成代码的调试和测试投入近一半的时间，这比平常的安排多很多；
③ 容易估计的部分，如编码，仅仅分配了1/6的时间。
- 传统的进度安排不合理之处：
① 通过对传统项目进度安排的研究，发现很少有项目允许为测试分配一半的时间。
② 它们中的许多项目，在系统测试之前还能保持进度。或者说，除了系统测试，进度基本能够保证。
- 传统进度容易造成意外，补救措施代价高昂：
① 坏消息没有任何预兆，很晚才出现在客户和项目经理面前。此时此刻的延迟具有不寻常的、严重的财务和心理上的反应。
② 若在即将发布时出现延迟，所付出的二次商业代价是非常高昂的。
③ 在早期进度策划时，允许充分的系统测试时间是非常重要的。
Part 4 空泛的估算
- 情景带入
当和顾客约定好，两分钟内出一份煎蛋，当它在两分钟内无法完成后，顾客只能选择等待或吃生蛋，厨师还有别的选择，开大火，不过有可能会将鸡蛋一面是糊的，一面是生的。
- 现象总结
① 为了满足顾客期望的日期而造成的不合理进度安排，在软件领域中却比其他任何工程领域要普遍的多。
② 非阶段化方法的采用，少得可怜的数据支持，加上完全借助软件经理的直觉，这样的方式很难生产出有力的、看似可靠的和规避风险的估计。
- 推荐2种解决方案
① 开发并推行生产率图表、缺陷率图表、估算规则等，而整个组织最终会从这些数据的共享上获益。
② 在基于可靠基础的估算出现之前，项目经理需要挺直腰杆，坚持他们的估计，确信自己的经验和直觉总比从期望派生出的结果要强得多。
Part 5 重复产生的进度灾难
- 向进度落后的项目中添加人手，只会使进度更加落后。
- 项目的时间依赖于顺序上的限制，人员的最大数量依赖于独立子任务的数量。从这两个数值可以推算出进度表：
① 该表安排的人员较少，花费的时间较长（唯一的风险是产品可能会过时）。
② 分派较多的人手，计划较短的时间，将无法得到可行的进度安排。
- 在众多软件项目中，缺乏合理的进度安排是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还要大。
作者总结
2.1 缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来影响还大。
2.2 良好的烹饪需要时间，某些任务无法在不损害结果的情况下加快速度。
2.3 所有的编程人员都是乐观主义者： “一切都将运作良好”。
2.4 由于编程人员通过纯粹的思维活动来开发，所以我们期待在实现过程中不会碰到困难。
2.5 但是，我们的构思是有缺陷的，因此总会有 bug。
2.6 我们围绕成本核算的估计技术，混淆了工作量和项目进展。人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。
2.7 在若干人员中分解任务会引发额外的沟通工作量——培训和相互沟通。
2.8 关于进度安排，我的经验是为 1/3 计划、1/6 编码、1/4 构件测试以及1/4系统测试。
2.9 作为一个学科，我们缺乏数据估计。
2.10 因为我们对自己的估计技术不确定，所以在管理和客户的压力下，我们常常缺乏坚持的勇气。
2.11 Brook 法则：向进度落后的项目中增加人手，只会使进度更加落后。
2.12 向软件项目中增派人手从三个方面增加了项目必要的总体工作量：任务重新分配本身和所造成的工作中断；培训新人员；额外的相互沟通。