"人月神话"的字面意思就是
人是程序员，月是时间，如果一个人干10个月等同10个人干一个月，那就成神话。
Chapter_1 The Tar Pit（焦油坑）
对焦油坑的解释
“过去几十年的大型系统开发就如同一个焦油坑，很多大型和强壮的动物在其中剧烈地挣扎。他们中大多数开发出了可运行的系统--不过只有极少数的项目满足了目标、进度和预算的要求。各种团队，大型的或小型的，庞杂的或精干的，一个接一个地淹没在了焦油坑中，表面上看起来好像没有任何一个单独的问题会导致困难，每个问题都能获得解决，但是当它们互相纠缠和累积在一起的时候，团队的行动就会变得越来越慢。对于问题的麻烦程度，每个人似乎都会感到惊讶，并且很难看清问题的本质。不过如果我们想解决问题，就必须试图先去了解问题。”
编程系统产品的演进
编程系统产品开发的工作量是供个人使用的、独立开发的构件程序的九倍(横竖x3)。
编程的乐趣
- 创造的纯粹快乐
- 源于开发出有价值的东西，这种价值体现于对别人有用。
- 将相互啮合的零部件组装在一起，以精妙的方式运行着，并收到了预期效果。
- 持续学习的快乐，源于这项工作的非重复特性。
- 源于在易于驾驭的介质上工作。
编程行业的一些内在固有苦恼：
- 将做事方式调整到追求完美的方向，是学习编程的最困难的部分。
- 由其他人来设定目标、供给资源和提供信息。，编程人员很少能控制环境和工作目标。(个人权威和他所承担的责任是不相配的)实际权威来自于每次任务的完成.
- 对其他人的依赖，依靠其他人的程序(往往设计不合理or实现拙劣or发布不完整[无源码或测试用例]or文档记录很糟糕)，在理想状况下这些程序本应是可靠完整的。
- 寻找琐碎bug是一项重复性的活动。调试和差错往往是线性收敛的。测试一拖再拖，寻找最后一个错误比第一个将花费更多的时间。
- 当产品即将或已经完成的时候，却已经过时，同事和竞争对手已经在追逐新的、更好的构思了，甚至已经在安排了。
编程挑战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）在基于可靠基础的估算之前，专业人士的经验和直觉比期望派生出的结果有时更可靠。
如何有效地应对重复产生的进度灾难
除了加派人手,更为靠谱的两个方案:
- 重新安排进度,避免小的偏差“Take no small slips.”
- 当项目延期所导致的二次成本非常高时，削减任务成了唯一可行的方法。
加派人手而不调整任务的结果(培训,任务的重新分配以及系统测试工作量)将是灾难性的重复,这种情况比不加派人手只调整任务进度所产生的产品更差.
Brooks法则
向进度落后的项目中增加人手，只会使进度更加落后。（Adding manpower to a late software project makes it later.）