《人月神话》读书笔记.md

《人月神话》读书笔记

Class

这是一篇来自《人月神话》的读书笔记，源自研一“软件工程管理”一课的作业。

笔记的格式将先按章节的阅读顺序做一些摘记，最后用一部分文字进行通读的总结。阅读版本为清华大学出版 的40周年中文纪念版，布鲁克斯作，汪颖翻译

CP1 焦油坑

于是，本书将编程比作焦油坑

CP2 人月神话

引入谈到：在众多软件项目中，缺乏合理的进度安排是造成项目滞后的最主要原因，比其他所有因素加起来的影响还要大。列举了如“错误将进度与工作量混淆”、“对自己的估算缺乏信心”、“缺乏对估计技术有效的研究”、“缺少进度跟踪和监督”等理由。如下几点，后附我的某些理解：

1. 更年轻的计算机技术、更年轻的程序员，通常都是乐观主义者。带来第一个错误假设——一切都会运作良好，每项分工仅仅花费理想的时间。

   我们在进行编程等创造性活动时，其实往往会遇到一些实际问题，这些不曾预料或突发的情况是无法避免的，过于主观的估计和判断造成的乐观思维是存在缺陷的。

2. 人月——一个错误的思考方式，在估计和进度安排中使用的工作量单位。成本随开发的人数和时间是动态的，但是制定的进度却不是如此。就是说人月——人员数量和时间相互替换。

   也就是说，通过增加人手的方式来换取时间上的效率，不一定可行。有一些不可分解的任务可能根本无法起作用，另一些可能需要增加额外的时间、精力等成本去了解新的工作内容。

3. 系统测试的进度安排往往不太合理，这个阶段其实牵扯到所有子单元，遭遇的bug、错误往往难以估计，与乐观主义所做的假设是有区别的。

4. 项目经理或管理人员，在进行项目的紧急与重要程度的估计中没有标准化的说明，一般都是经验导向的。

5. 重复产生的进度灾难——在项目进度delay后，过于自然地加派人手，导致了代价分析的错误度量。将会导致进度进一步delay/p>

CP3 外科手术队伍

• 如何在有意义的进度安排内创建大型系统/li>

• 首席程序员：定义功能、性能技术说明，设计程序，编制源代码、测试及文档
• 副手：后备作用，各种备选建议与辅助开发
• 管理员：
• 程序职员
• 工具维护人员
• 测试人员
• 语言专家

这种团队是与传统队伍建设不太一样，不同人员之前角色不平等而是有差异的。个体间不存在利益间的建设。可能可以达到客观的一致性。同时它也是一种专业化的分工。

这个结构在系统的构建上保留了完整性——有一个系统结构师自顶向下的进行了所有的设计。系统结构师必须清楚地划分体系结构和现实之间的界线，必须一丝不苟地专注于体系结构的建设。

小结： 这一章中主要是讲到了一个开发团队的结构设计，从一个系统结构师的角度去考虑，如何能够给出一种可靠的队伍建设的建议，并且给出了不通过角色的解释。其实，这种队伍的建设是我之前所没有了解到的，可能我们之前大部分了解到的都是具体到项目的实现中，每个人负责一个模块，各个模块是相互耦合和关联的，在项目进行的过程中不会有人全程参与所有的系统设计。但是，在实际的项目开发中，许多人脱离了系统的本身，而专注于自身的任务，没有了其他职责或背景的支持，可能在沟通和联调中产生问题。

（续）但是，若对于一个大型系统的开发而言，这样的模式是否真的实用。队伍扩充后，对不同的任务或职责所司专业人员的把控也不见得就有这么契合吧比如各类技术人员开发效率的差异与分化后的职责分配问题，会不会在系统级联调的时候出现一些其他的问题是我的一个小的疑问。

CP4 贵族专制、民主政治和系统设计

简洁和直白来自概念的完整性。概念的完整性须由一个人或非常少数的人来实现。这一点与进度压力需要很多人员参与相矛盾，解决矛盾的方法可能是有限的。概念结构的完整性可能反映的是唯一的设计理念，但是经验却表示该开发模式下系统需要的开发会变得更加高效。

CP5 画蛇添足

面对体系结构上的设计，结构师在第一次系统搞设计的时候，应该是尽早与需求商商议的、并且需要其持续的沟通，来保证系统的开发任务。在这个过程中如果出现未能预见的问题，一般的建议不是寻求体系结构的更变，因为这会导致和开发人员的矛盾和导致不必要的开发成本。

谈到二次系统建设时，因为系统技术和功能的特殊性变化，系统结构师们应当有意识地关注，避免对于开发中功能上的过于装饰和技术细化，还是依赖原始的系统设计理念，在确保原则的基础上尽可能地保持完整性的开发过程。

CP6 贯彻执行

从上两章提出的概念完整性的保障：给出了一些可行的实施方案。包括了如何从文档化及手册管理、形式化规则与定义、举行会议和大会为保障、提供多重实现，并且在电话日志和产品测试方面进行记录与监督。以上几个方面，分别从不同的角度对系统设计开发中面临的不同问题进行了可行性的建议，并分析了其效果与效率，一种可能的解释是，在这些方向能够贯彻实际落实的话，某一个系统的概念的完整性是能够实现的。这样使得为系统更好地实现带来了更多的概念支持。

CP7 为什么巴比伦会失败

巴比伦这个工程无论是在人力、物力和财力上都是具有足够支持的，其失败的原因在于缺乏了团队的交流与合作，各子单位在争吵中逐渐走向破裂，导致了最终的失败。类比到软件项目的管理中来，这些经验教训能够发挥很大的启发作用。在大型项目地开发中，使用非正式途径、会议或者工作手册，加强同项目中各个人员的交流和合作，能够有效的保障系统的顺利开发。

其中，项目工作手册是项目的一系列的组织结构与规范，涵盖了所有的文档、说明、用户手册等内容。使用项目手册不仅能够保障项目文档本身的结构，还可以控制信息发布的准则。项目手册还提供了一种处理问题机制的方式方法。另一方面，项目的组织结构，需要从人员、任务、责任几个方面出发，在进行人力划分与职责分配时，要考虑相互沟通交流的因素。组织和交流，是需要管理者同软件技术一样重要的考虑点。

CP8 胸有成竹

系统的编程进程及工作量的估计是需要有一个合理且动态的调整郭晨的，项目的进展或工作量不仅仅是包含了编码，还应该将开发人员的协调、沟通和交流都考虑进来，进行合理、实际的综合评估，从而完成对项目的整体把握和控制。

书中另外在此章篇幅中给出了一些关于编程人员生产率研究的数据分析，来充分说明生产效率的矛盾性。

CP9 削足适履

谈到程序空间本身，也是作为成本的一部分，包含在程序开发的过程中。我们在开发过程中不仅仅要考虑编码本身，还要考虑编码之外甚至硬件的成本。所以，需要对项目规模进行一个可细化的设置与分配，避免浪费了不必要的规模空间。

CP10 提纲挈领

项目工作中，会存在许多文案，也就是技术之外的许多管理性的工作。在进行项目文档的管理开展中，需要注意一些关键点：

• 什么是软件产品中的关键文档：内容、目标、产品技术说明、进度、预算、工作空间分配、人员结构
• 正式的文档能够提供有必要的决策和记录，一来可以作为项目开发的各种规范与约束，另一方面也是不同人员之间沟通的标准和参考，也有助于数据基础和检查列表，在后续的辅助工作和调整中进行记录。
• 项目经理是生产各类文档的出发点，这些内容也是基础软件开发成果的一部分。

CP···