第2章 人月神话
人月神话
标签：人月神话
美食的烹调需要时间；片刻等待，更多美味，更多享受
在众多软件项目中，缺乏合理的进度安排是造成项目滞后最主要的原因，它比其他所有因素加起来的影响都大。
- 首先，我们对估算技术缺乏有效的研究，更加严肃地说，它反映了一种悄无声息但并不真实的假设————一切都将运作良好
- 我们采用的估算技术隐含地假设人和月可以互换，错误地将进度和工作量互相混淆
- 由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地估算这项工作
- 对进度缺少跟踪和监督
- 当意识到进度的偏移时，下意识（以及传统）的反应是增加人力（火上浇油）
乐观主义
- 系统编程的进度安排背后的第一个错误的假设是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间
- 对于创造者，只有实现的过程中，才能发现我们构思的不完整性和不一致性；因此，对于理论家，书写、试验和“工作实现”是非常基本和必要的
- 由于物理介质和思路中隐含的不完善性，实现起来需要花费大量的时间和汗水。对遇到的大部分实现上的困难，我们总是倾向于去责怪那些物理介质，因为它们不顺应“我们”设定的思路。
- 我们的骄傲是判断带上了主观主义色彩
人月
- 第二个谬误的思考方式是在估计和进度安排中使用的工作量单位：人月
- 人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话，它暗示着人员数量和时间是可以相互转换的
- 人数和时间的互换仅仅适用于一下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流。（譬如割小麦）
人员和时间之间的关系————完全可以分解的任务
- 当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助。（譬如一位母亲孕育一个声明不管怎样都需要10个月）
人月关系————无法分解的任务
- 对于可以分解，但子任务之间需要相互沟通和交流的任务，必须在计划工作中考虑沟通的工作量
人月关系————需要沟通可分解的任务
- 沟通所增加的负担由两部分组成：培训和相互的交流
- 培训是不可分解的，这部分增加的工作量随人员的数量呈线性变化
- 相互的交流产生的工作量更多，可能会完全抵消对原有任务分解所产生的作用
人月关系————关系错综复杂的任务
因为软件开发本质上是一项系统工作————错综复杂关系下的一种实践，沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。从而，添加更多的人手，实际上是延长了而不是缩短了时间进度
系统测试
- 系统测试进度的安排常常是编程中最不合理的部分
-
对于软件任务的进度安排，作者的经验法则：
1/3 计划
1/6 编码
1/4 构件测试和早期系统测试
1/4 系统测试，所有的构件已完成 特别需要指出，不为系统测试安排足够的时间简直就是一场灾难
- 坏消息没有任何预兆，很晚才出现在客户和项目经理面前
- 若在即将发布时出现延误，所付出的二次商业代价是非常高昂的。二次成本远远高于其他开销
- 在早期进度策划时，允许充分的系统测试时间是非常重要的
空泛的估算
- 某项任务的计划进度，可能受限于顾客要求的紧迫程度，但紧迫程度无法控制实际的完成情况
- 非阶段化方法的采用，少得可怜的数据支持，加上完全借助软件经理的直觉，这样的方式很难生产出有力的、看似可靠的和规避风险的估计
- 两种解决方案：
- 开发并推行生产率图表、缺陷率图标、估算规则等，而整个组织最终会从这些数据的共享上获益
- 在基于可靠基础的估算出现之前，项目经理需要挺直腰杆，坚持他们的估计，确信自己的经验和直觉总比从期望派生出的结果要强得多。
重复产生的进度灾难
当一个软件项目落后于进度时，通常的做法是什么呢？自然是加派人手。如图2.1至2.4所示，这可能有所帮助，也可能无法解决问题。
我们来考虑一个例子3。设想一个估计需要12个人月的任务，分派给3个成员4个月时间，在每个月的末尾安排了可测量的里程碑A、B、C、D（图2.5）。
现在假定两个月之后，第一个里程碑没有达到（图2.6）。项目经理面对的选择方案有哪些呢？
两个月后，第一个里程碑没有达到
1. 假设任务必须按时完成。假设仅仅是任务的第一个部分估计不得当，即如图2.6所示，则剩余了9个人月的工作量，时间还有两个月，即需要4.5个开发人员，所以需要在原来3个人的基础上增加2个人。
2. 假设任务必须按时完成。假设整个任务的估计偏低，即如图2.7所示，那么还有18个人月的工作量以及2个月的时间，需要将原来的3个人增至9个人。
估计偏少的情况（即假设当前的进度是正常的进度，那么总的进度需要3人 * 2月 / (1/4) = 24 人月 ， 剩余 24 - 6 = 18人月）
3. 重新安排进度。我喜欢P.Fagg，一个具有丰富经验的硬件工程师的忠告：“避免小的偏差（Take no small slips）”。也就是说，在新的进度安排中分配充分的时间，以确保工作能仔细、彻底地完成，从而无需重新确定时间进度表。
4. 削减任务。在现实情况中，一旦开发团队观察到进度的偏差，总是倾向于对任务进行削减。当项目延期所导致的后续成本非常高时，这常常是唯一可行的方法。项目经理的相应措施是仔细、正式地调整项目，重新安排进度；或者是默默地注视着任务项由于轻率的设计和不完整的测试而被剪除。
前两种情况中，坚持把不经调整的任务在四个月内完成将是灾难性的。考虑到重复生成的工作量，以第一种为例（图2.8）——不论在多短的时间内，聘请到多么能干的两位新员工，他们都需要接受一位有经验的职员的培训。如果培训需要一个月的时间，那么三个人月将会投入到原有进度安排以外的工作中。另外，原先划分为三个部分的工作，会重新分解成五个部分；某些已经完成的工作必定会丢失，系统测试必须被延长。因此，在第三个月的月末，仍然残留着7个人月的工作，但此时只有5个有效的人月。如同图2.8所示，产品还是会延期，如同没有增加任何人手（图2.6）。
（即相当于前面两个月的工作量白费，再花一个月培训，剩余一个月工作，总的5个人，那么四个月过后剩余 12 - 5 = 7人月）
期望四个月内完成项目，仅仅考虑培训的时间，不考虑任务的重新划分和额外的系统测试，在第二个月末需要增添4个，而不是2个人员。如果考虑任务划分和系统测试的工作量，则还需要继续增加人手。到那时所拥有的就不是3人的队伍，而是7人以上的团队；并且小组的组织和任务的划分在类型上都不尽相同，这已经不是程度上的差异问题。
注意在第三个月的结尾时，情况看上去还是很糟。除去管理的工作不谈，3月1日的里程碑仍未达到。此时，对项目经理而言，仍然存在着很强的诱惑——添加更多人力，结果往往会是上述循环的重复。这简直就是一种疯狂、愚蠢的做法。
前面的讨论仅仅是第一个里程碑估计不当的情况。如果在3月1日，项目经理做出了比较保守的假设，即整个估计过于乐观了，如图2.7所示。6个人手需要添加到原先的任务中。培训、任务的重新分配、系统测试工作量的计算作为练习留给读者。但是毫无疑问，重现“灾难”所开发出的产品，比没有增加人手，而是重新安排开发进度所产生的产品更差。
简单、武断地重复一下Brooks法则：
向进度落后的项目中增加人手，只会使进度更加落后。（Adding manpower to a late software project makes it later）
这就是除去了神话色彩的人月。项目的时间依赖于顺序上的限制，人员的数量依赖于单个子任务的数量。从这两个数值可以推算出进度时间表，该表安排的人员较少，花费的时间较长（唯一的风险是产品可能会过时）。相反，分派较多的人手，计划较短的时间，将无法得到可行的进度表。总之，在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还要大。