人月神话(一二章)摘要笔记

 

"人月神话"的字面意思就是

人是程序员，月是时间，如果一个人干10个月等同10个人干一个月，那就成神话。

 

Chapter_1 The Tar Pit（焦油坑）

对焦油坑的解释

“过去几十年的大型系统开发就如同一个焦油坑，很多大型和强壮的动物在其中剧烈地挣扎。他们中大多数开发出了可运行的系统--不过只有极少数的项目满足了目标、进度和预算的要求。各种团队，大型的或小型的，庞杂的或精干的，一个接一个地淹没在了焦油坑中，表面上看起来好像没有任何一个单独的问题会导致困难，每个问题都能获得解决，但是当它们互相纠缠和累积在一起的时候，团队的行动就会变得越来越慢。对于问题的麻烦程度，每个人似乎都会感到惊讶，并且很难看清问题的本质。不过如果我们想解决问题，就必须试图先去了解问题。”

 

编程系统产品的演进

编程系统产品开发的工作量是供个人使用的、独立开发的构件程序的九倍(横竖x3)。

 

编程的乐趣

1. 创造的纯粹快乐
2. 源于开发出有价值的东西，这种价值体现于对别人有用。
3. 将相互啮合的零部件组装在一起，以精妙的方式运行着，并收到了预期效果。
4. 持续学习的快乐，源于这项工作的非重复特性。
5. 源于在易于驾驭的介质上工作。

编程行业的一些内在固有苦恼：

1. 将做事方式调整到追求完美的方向，是学习编程的最困难的部分。
2. 由其他人来设定目标、供给资源和提供信息。，编程人员很少能控制环境和工作目标。(个人权威和他所承担的责任是不相配的)实际权威来自于每次任务的完成.
3. 对其他人的依赖，依靠其他人的程序(往往设计不合理or实现拙劣or发布不完整[无源码或测试用例]or文档记录很糟糕)，在理想状况下这些程序本应是可靠完整的。
4. 寻找琐碎bug是一项重复性的活动。调试和差错往往是线性收敛的。测试一拖再拖，寻找最后一个错误比第一个将花费更多的时间。
5. 当产品即将或已经完成的时候，却已经过时，同事和竞争对手已经在追逐新的、更好的构思了，甚至已经在安排了。

编程挑战or任务：

在实际的进度和有效的资源范围内，寻找解决实际问题的切实可行方案。

总结：

编程是一个许多人痛苦挣扎的焦油坑，乐趣远大于困扰的创造性活动。

 

---

 

Chapter_2人月神话（The Mythical Man-Month）

缺乏合理的进度安排是造成项目滞后的最主要原因。

人月问题的产生

>>>对估算技术缺乏有效的研究，反映出一种悄无声息但并不真实的假设——一切都将运作良好。

>>>我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆。

>>>由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地估算这项工作。

>>>对进度缺少跟踪和监督。

>>>当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。(这种行为就像使用汽油灭火)

 

编程中的乐观主义（Optimism）

系统编程的进度安排背后的第一个错误的假设是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。

Dorothy Sayers在她的《创造性的思想（The Mind of the Maker）》一生中，将创造性活动分为三个阶段：构思、实现和交流。

计算机编程基于十分容易掌握的介质，编程人员通过非常纯粹的思维活动——概念以及灵活的表现形式来开发程序。

第二个谬误的思考方式是: 在估计和进度安排中使用的工作量单位：人月。

用人月作为衡量一项工作的规模是一种危险和带有欺骗性的神话,主要是因为以下两个原因: 耗费时间的不确定性和人员数量与时间的不可互换.

 

人月概念适用的范围

人月仅适用于：

（1）某个任务可以分解给参与人员。

（2）并且人员之间不需要相互交流。

而任务由于在次序上的限制不能分解时,人手的添加对进度没有帮助,这种情况就像生小孩这个任务,多参与几个人也不能让母亲提前把孩子生下来.

沟通所增加的负担由两个部分组成：培训和相互交流。

 

人员和时间之间的关系(从四种情况考虑)：

(1)完全可以分解的任务

(2)无法分解的任务

(3)需要沟通的可分解任务

(4)关系错综复杂的任务

软件开发本质上是一项系统工作——错综复杂关系下的实践，沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。

系统测试

系统测试需要的时间以来于所遇到的错误、缺陷的数量以及其难以捕捉的程度。

系统测试进度的安排常常是编程中最不合理的部分。

经验法则

对于软件任务的进度安排，作者的经验法则是：

• 1/3计划、
• 1/6编码、
• 1/4构件测试和早期系统测试、
• 1/4系统测试，所有的构件已经完成

这种安排方法：

（1）分配给计划的时间比平常的多。

（2）对所完成代码的调试和测试投入近一半的时间，这比平常的安排多很多。

（3）容易估计的部分：1/6编码

大多数项目的测试实际上花费了进度中一半的时间，或者来说，除了系统测试，进度基本能够保证。

如果不为系统测试安排足够的时间将是一场灾难。

系统测试的延迟具有不寻常的、严重的财务和心理上的反应，每天的人力成本也已经达到最大限度。更为严重的是在用软件支持其他的商业活动（计算机硬件运送、新设备操作等）的情况下，若在即将发布时出现延误，所付出的二次商业代价是非常高昂的。

空乏估算的两种解决方案(如何让估算更具说服力)：

（1）开发并推行生产率图表、缺陷率图表、估算规则等，而整个组织最终会从这些数据的共享上获益。

（2）在基于可靠基础的估算之前，专业人士的经验和直觉比期望派生出的结果有时更可靠。

 

如何有效地应对重复产生的进度灾难

除了加派人手,更为靠谱的两个方案:

1. 重新安排进度,避免小的偏差“Take no small slips.”
2. 当项目延期所导致的二次成本非常高时，削减任务成了唯一可行的方法。

加派人手而不调整任务的结果(培训,任务的重新分配以及系统测试工作量)将是灾难性的重复,这种情况比不加派人手只调整任务进度所产生的产品更差.

Brooks法则

向进度落后的项目中增加人手，只会使进度更加落后。（Adding manpower to a late software project makes it later.）