人月神话

1. 软件系统可能是人类创造中最错综复杂的事物。
2. 软件工程的焦油坑在将来很长一段时间内仍然会使人们举步维艰，无法自拔

人月起源

1964年 IBM的大型主机System/360诞生。
软件工程著作《人月神话》，就是作者关于 System/360操作系统的研发经验所做的提炼总结

人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的

1. 人月，一个软件开发的工作量单位
   1. 人月（季、年）是一种表示劳动时间的计量单位
   2. 指一个劳动者工作一个月（季、年）
2. 是项目所有参与者工作时长的累计，最为方便计算成本的数据。是项目管理中常用的概念。
   1. 一个人工作 10个月的工作量，就是 10人月
   2. 10人月的工作量，10人工作1个月可以完成吗？
   3. 项目时长是由项目中的关键路径决定的，做任务分解（WBS）中可以得出关键任务路径

书名《人月神话・40周年中文纪念版》，2015年清华大学出版社出版，
但这本书其实是 1995年《人月神话・20周年英文纪念版》的一个译本，
由上面的描述就可以推算出第一版《人月神话》，是在1975年出版的，
掌握这几个时间点，有利于理解该书的历史背景。

本书虽然一共有19章节，但是精华部分在第2~7章，后续章节则探讨了软件工程管理的其他方面。作者向我们表达了几个重要的观点：1. 程序员总是乐观的，总是假设船到桥头自然直。 2. 人月神话，人们错误地认为1个人工作10个月的工作量，10个人工作1个月就可以完成。3. 开发团队应该向外科手术团队一样，队伍小型且精干，由一位架构师领导。4. 概念完整性，由架构师统一系统概念，保证整体系统体现的是一套完整的设计理念。

本书第1~15章是第一版的原版内容。第16章是作者在1986年发表的一篇论文“没有银弹：软件工程的根本和次要问题”，第17章是在1995年出版纪念版时对外界关于第16章论文的一些批评进行回答，第18章是对前面第1~15章每个章节进行总结，最后第19章是与本书论点相关的短文。

第1章 焦油坑

1. 编程系统产品开发的工作量是供个人使用的、独立开发的构件程序的9倍。软件构件产品化引起了3倍工作量，将软件构件整合成完整系统所需要的设计、集成和测试又加强了3倍的工作量，这些高成本的构件在根本上是相互独立的。
2. 编程行业“满足我们内心深处的创造渴望和愉悦所有人的共有情感”，其提供了五种乐趣：
   • 创建事物的快乐；
   • 开发对其他人有用的东西的乐趣；
   • 将可以活动、相互啮合的零部件组装成类似迷宫的东西，这个过程所体现出令人神魂颠倒的魅力；
   • 面对不重复的任务，不断学习的乐趣；
   • 工作在如此易于驾驭的介质上的乐趣——纯粹的思维活动——其存在、移动和运转方式完全不同于实际物体。
3. 同样，这个行业具有一些内在固有的苦恼：
   • 将做事方式调整到追求完美是学习编程的最困难部分；
   • 由其他人来设定目标，并且必须依靠自己无法控制的事物（特别是程序）；权威不等同于责任；
   • 实际情况看起来要比这点好一些：真正的权威来自于每次任务的完成；
   • 任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外；
   • 人们通常期望项目在接近结束时，软件项目能收敛得快一些，然而，情况却是越接近完成，收敛得越慢；
   • 产品在完成前总面临着陈旧过时的威胁；只有实际需要时，才会用到最新的设想。

什么是焦油坑

焦油坑，更想说明的是即使你自身足够强大，也没有办法摆脱束缚从险境中逃身。
IT项目，也是如此

《帕金森定律》一书中有一个”金字塔上升现象”，和焦油坑很相像：
尽管每个人都很忙但组织效率却越来越低，
尽管每个人都在往上走，但导致在每个岗位角色上，都难得到技能过关高效率的人员。

项目是一个足够复杂的动态过程，以至于我们很难将其做到极致。
作为产品经理，项目四要素（工作范围、时间、质量、成本），人员，环境，组织方式，外部约束，风险管控，团队维系等外置因素都是要考虑的东西。
只有将所有的要素达到尽量的平衡，这个团队才有最强的战斗力，也就才有可能做到项目成功。否则一个要素出现小的差错可能都会导致巨大的损失。

如何避免焦油坑

1 项目初期 快速试错

开发初期不要一拥而上，要保持精干的团队（类似于外科手术团队），
从稳定的核心开始单点突破，逐层扩展。要用生长（grow）的方式来开发系统。在开发大型软件时候掉进焦油坑的几率远远大于小型软件，
小型软件就算掉进去也很容易跳出来，有一定的试错成本。

但是如果前期的团队选不好，产品策划选不好，开发架构选不好，这个坑依旧是在所难免。
特别是在一些创业公司，很多创业公司，创业初期，架构选的不对，在业务需要快速发展的时候，这时候自身产品架构就会拖后腿，
如果一开始产品设计或开发人员能力不足，会直接导致产品设计失败，漏洞层出不穷。
就算后期公司可以活下来，以后也要请好的架构师来进行重构。
所以在有条件的情况下，在项目初期把架构搭好，把大体规划确定好，会少很多的麻烦，方便以后拓展

2 项目中期 规范化

项目的中期，随着业务的生长（grow），团队中的成员也越来越多，新鲜血液的加入对团队来说是好事，但重要的难点在于，如何保证团队概念的一致性？
在书中提到了一个概念：”贵族专制式的开发“，我们要保证，团队整体的概念设计必须由一个人，或者非常少数有着极其默契的人来实现。

在以后系统越复杂，规模和工作量越来越大，
但是工作量和项目周期并不是一个简单的线性关系，这对于产品设计和开发人员的整体把控能力和相关业务经验要求也就越高。

这也不可避免的让更多的人参与项目，参与的人员越多，人员的沟通效率也就越低。
而这时候，最关键的关键就是要保证沟通和验证效率！建立好一条有效的沟通机制和测试流程，这是非常费精力的工作，需要全体人员努力，但是完成之后，非常值得，解决大问题。

3 项目收尾

项目后期是指项目上线运行一段时间后，因为项目周期长，几经易手的代码构造可能已经过时，
但是如果前期代码不规范，后期维护简直就是难上加难，特别在一些外包公司中容易出现这种问题。
项目的生命历程中，往往会出现一个”不可能三角”，我们只能尽其所能优化两项目标，绝无可能做到完美

避免进入”焦油坑”，产品经理的取舍很重要，如何选出放弃的一角，让老板们认清现状，对于放弃的一角达成一致这很关键。
最好是放弃挣扎，直接开始重构。
天下没有不散的宴席，一个项目最终的分化或是死亡都是好的归宿结局，
这时候产品经理要坚决果断，做好善后工作，总结经验，尽量减少时间成本和人力成本，摆正心态迎接新的挑战。

第2章 人月神话

1. 缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素的总和影响还大。
2. 良好的烹饪需要时间，某些任务无法在不损害结果的情况下加快速度。
3. 所有的编程人员都是乐观主义者：“一切都将运作良好”。
4. 由于编程人员通过纯粹的思维活动来开发，我们期待在实现过程中不会碰到困难。
5. 但是，我们的构思本身是有缺陷的，因此总会有bug。
6. 围绕着成本核算的估计技术，混淆了工作量和项目进展。人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。
7. 在若干人员中分解任务会引发额外的沟通工作量——培训和相互沟通。
8. 关于进度安排，我的经验是为1/3计划、1/6编码、1/4构件测试以及1/4系统测试。
9. 作为一门学科，我们缺乏数据估计。
10. 我们对自己的估计技术不确定，因此在管理和客户的压力下，我们常常缺乏坚持的勇气。
11. Brooks法则：为进度落后的项目增加人手，只会使进度更加落后。
12. 向软件项目中增派人手从三个方面增加了项目必要的总体工作量：任务重新分配本身和所造成的工作中断。培训新人员。额外的相互沟通。

第3章 外科手术队伍

1. 同样有两年工作经验而且在受到同样培训的情况下，优秀的专业程序员的生产率是较差的程序员的10倍。
2. 小型、精干队伍是最好的——思绪尽可能少。
3. 两个人的团队，其中一个人是领导者，常常是最佳的人员使用方法。
4. 对于真正意义上的大型系统，小型精干的队伍太慢了。
5. 实际上，绝大多数大型编程系统的经验显示，一拥而上的开发方法是高成本、速度缓慢、低效的，开发出的产品无法进行概念上的集成。
6. 一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法——既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产效率，还彻底地减少了沟通的工作量。

第4章 贵族专制、民主政治和系统设计

1. “概念完整性是系统设计中最重要的考虑因素。”
2. “功能与理解上的复杂程度的比值才是系统设计的最终测试目标。而不仅仅是丰富的功能。（该比值是对易用性的一种测量，由简单和复杂应用共同验证。）
3. 为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。
4. “对于非常大型的项目。将体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。”（其同样适用于小型项目。）
5. “如果要得到系统概念上的完整性。就必须有人控制这些概念。这实际上是一种无需任何歉意的贵族专制统治。”
6. 纪律、规则对行业是有益的。外部的体系结构规定实际上是增强，而不是限制实现小组的创造性。
7. 概念上统一的系统能更快的开发和测试。
8. 体系结构、设计实现、物理实现的许多工作可以并行。

第5章 画蛇添足

1. 尽早交流和持续沟通能使结构师有较好的成本意识，使开发人员获得对设计的信心，并且不会混淆各自的责任分工。
2. 结构师如何成功的影响实现：
   • 牢记是开发人员承担创造性地实现责任。结构师只能提出建议。
   • 时刻准备着为所指定的说明建议一种实现的方法。准备接受任何其他可行的方法。
   • 对上述建议保持低调和平静。
   • 准备对所建议的改进放弃坚持。
   • 听取开发人员在体系结构上改进的建议。
3. 第二个系统是人们所设计的最危险的系统。通常的倾向是过分地进行设计。
4. OS/360是典型的画蛇添足的例子。(Windows NT似乎是20世纪90年代的例子。)
5. 为功能分配一个字节和微秒的优先权值是一个很有价值的规范化方法。

第6章 贯彻执行

1. 即使是大型的设计团队。设计结果也必须由一个或两个人来完成，以确保这些决定是一致的。
2. 必须明确定义体系结构中与先前定义不同的地方，重新定义的详细程度应该与原先的说明一致。
3. 出于精确性的考虑，我们需要形式化地设计定义；同样，我们需要记叙性定义来加深理解。
4. 必须采用形式化定义和记叙性定义中的一种作为标准。另一种作为辅助措施；他们都可以作为表达的标准。
5. 设计实现，包括模拟仿真，可以充当一种体系结构的定义；这种方法有一些严重的缺点。
6. 直接整合是一种强制推行软件的结构性标准的方法。
7. “如果起初至少有两种以上的实现，体系结构定义会更加整洁和规范。”
8. 允许体系结构师对实现人员的询问做出应答解释是非常重要的，并且必须进行日志记录和整理发布。
9. “项目经理最好的朋友就是他每天要面对的对手。独立的产品测试机构/小组。”

第7章 为什么巴比伦塔会失败

巴比伦塔项目的失败是因为缺乏交流以及交流的结果——组织。

交流

1. “因为左手不知道右手在做什么。从而进度灾难、功能的不合理和系统缺陷纷纷出现。”由于存在对其他人的各种假设，团队成员之间的理解开始出现偏差。
2. 团队应该以尽可能多的方式进行相互之间的交流。非正式的进行简要技术陈述的常规项目会议，共享的正式项目工作手册。

项目工作手册

1. 项目工作手册“不是独立的一篇文档，它是对项目必须产生的一系列文档进行组织的一种结构”。
2. “项目所有的文档都必须是该工作手册结构的一部分。”
3. 需要尽早和仔细地设计工作手册结构。
4. 事先制定良好结构的工作手册，可以将后来书写的文字放置在合适的章节中，并且可以提高产品手册的质量。
5. 每个团队成员应该能够看到所有材料。
6. 实时更新是至关重要的。
7. 工作手册的使用者应该将注意力集中在上次阅读后的变更以及关于这些变更重要性的评述上。
8. Parnas强烈的认为使每个人看到每件事的目标是完全错误的；各个部分应该被封装，从而没有人需要或者被允许看到其他部分的内部结构，只需要了解接口。

组织架构

1. 团队组织的目标是为了减少必要的交流和协作量。
2. 为了减少交流，组织结构包括了人力划分和限定职责范围。
3. 传统的树状组织结构反映了权力的结构原理——不允许双重领导。
4. 组织中的交流是网状而不是树状结构，因此所有的特殊组织机制（往往体现为组织结构图中的虚线部分）都是为了进行调整，以克服树状组织结构中交流缺乏的困难。
5. 每个子项目具有两个领导角色——产品负责人，技术主管或结构师。这两个角色的职能有很大的区别，需要不同的技能。
6. 两种角色的任意组合都可以是非常有效的：
   • 产品负责人和技术主管是同一个人；
   • 产品负责人作为总指挥，技术主管充当其左右手；
   • 技术主管作为总指挥，产品负责人充当其左右手。