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

 

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

人是程序员，月是时间，若是一我的干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.）