《人月神话》一句话总结各章核心观点

★【一句话总结各章核心观点】

第1章 焦油坑：提出软件产品现在处于进度和质量焦油坑当中，难以摆脱。

第2章 人月神话：人月估算法是错误的，这会暗示人月可互换，这种方式严重的忽视了一个重要的成本，沟通成本。
第3章 外科手术队伍：一个架构师，尽可能少的结构师和好的工作分工，结构师领导实施人员。这样可以保证概念一致性和尽可能少的沟通成本。这个团队要在架构师的专制下运作。
第4章 贵族专制、民主政治和系统设计：一个架构师也许还有少量的结构师，代表客户，对团队(实施人员)实行专制统治，从而才能产生概念一致，功能完备且系统的，能够得到客户满意度的产品。
第5章 画蛇添足：结构师要与实施人员充分的交流；避免过度设计。
第6章 贯彻执行：以用户手册（也就是需求分析）为中心，设计人员与实施人员要通过非常正式交流、会议、电话记录、电子邮件进行充分的沟通，避免理解错误，最终测试结构以用户手册为准则进行测试。注意，不同系统的用户手册是不同的GUI的可能就是界面说明，程序库可能是接口说明。
第7章 为什么巴比伦塔会失败？大型软件项目的组织是交流的结果，组织的目的是利于交流，组织分为两部分：一部分是文档的组织项目工作手册，另一部分是人员的组织。人员组织采用树形结构，每颗子树具有的要素：1。任务。2。产品负责人。3。技术负责人。4。进度。5。人力划分。6。各部门的接口。
第8章 胸有成竹：实践是最好的老师，但如果不能从中学习，再多的实践也没有用。估算有3个要素。1。实践。2。量化指标。3。根据量化的指标建立模型。而名言的意思是，实现->量化指标->估算模型->实现->量化指标->重新建立模型。是一个不断实践和学习的循环。
第9章 削足适履：整章都在讲解程序占用资源的控制。对于目前已经没有了太大的意义。
第10章 提纲挈领：为什么要有正式文档？：1。书面记录决策。明朗分析，突出矛盾。2。文档作为沟通渠道。3。数据基础和检查列表。通过周期性回顾，可以清楚项目状态，并进行调整。
第11章 未雨绸缪：1。使用原型开发。2。唯一不变的就是变化。所以我们的组织结构要适应变化能让每个人没有心理负担的做开发和实际，我们的产品也要尽早交付原型适应客户的变化。3。软件维护占总项目的40%工作量。4。交付给客户的不是产品，而是满意度。5。修复bug会以20-50%的几率引入新bug。
第12章 干将莫邪：在75年那个计算机世界茹毛饮血的年代，软件工具非常匮乏，那么需要一个人来做这件事。现在，软件工具异常丰富，单独开发一般没有必要了。但工具管理也是必不可少的一项工作。一定安排专人来做。但对开发工具的统一，对版本的统一，对使用说明的编写，还是非常有必要的。
第13章 整体部分：1。防范bug要从产品定义开始。2。先让各个部分都能够单独工作，再进行整体联调。
第14章 祸起萧墙：PERT图+清晰可测量的里程碑，配合进度信息真实反馈和审查，可以避免项目进度一点点的不被察觉的落后。
第15章 另外一面文档是必须的，但文档的工作量应该最小化。因为客户要的是程序而不是文档。
没有银弹与再论没有银弹：软件开发的根本困难是搭建什么样的系统既需求，次要问题是搭建系统的技术和编码过程。根本困难的复杂性、一致性、可变性和不可见性，决定了10年内开发效率不会有量级的提升。但可用的改进方法是：购买软件产品包、需求精炼与快速原型、增量开发——增长而非搭建系统、面向对象、重用（重用会带来词汇量增加的问题）