《人月神话》读书笔记
Class
这是一篇来自《人月神话》的读书笔记，源自研一“软件工程管理”一课的作业。
笔记的格式将先按章节的阅读顺序做一些摘记，最后用一部分文字进行通读的总结。阅读版本为清华大学出版社的40周年中文纪念版，布鲁克斯作，汪颖翻译
CP1 焦油坑
焦油坑源自洛杉矶博物馆中C.R.奈特的一幅油画作品。焦油坑是史前一种陷入后难以挣脱的，越挣扎越纠缠的坑，作者用来比喻过去的大型系统开发。对于一个大型系统而言，各种不同的团队、分组存在大小的问题，纠缠在一起直至整个系统的大麻烦。其实，也就是说千里之堤溃于蚁穴的隐含意思。
从编程的例子介绍了，编程之所以能让人体会乐趣是源自创建事物的活动。但是诸如在自我创造（编程）中体会的快感是受到了许多限制的，如编程规范与模式，业务的需求、资源的供给来源于他人，需要与不同的个体进行合作协商。也就是说，这种过程没有本身的绝对权威。但是这些过程是都是客观需要的。另一方面，可能还存在一些调试与劳动付出的矛盾与苦恼等。
于是，本书将编程比作焦油坑
CP2 人月神话
引入谈到：在众多软件项目中，缺乏合理的进度安排是造成项目滞后的最主要原因，比其他所有因素加起来的影响还要大。列举了如“错误将进度与工作量混淆”、“对自己的估算缺乏信心”、“缺乏对估计技术有效的研究”、“缺少进度跟踪和监督”等理由。如下几点，后附我的某些理解：
-
更年轻的计算机技术、更年轻的程序员，通常都是乐观主义者。带来第一个错误假设——一切都会运作良好，每项分工仅仅花费理想的时间。
我们在进行编程等创造性活动时，其实往往会遇到一些实际问题，这些不曾预料或突发的情况是无法避免的，过于主观的估计和判断造成的乐观思维是存在缺陷的。
-
人月——一个错误的思考方式，在估计和进度安排中使用的工作量单位。成本随开发的人数和时间是动态的，但是制定的进度却不是如此。就是说人月——人员数量和时间相互替换。
也就是说，通过增加人手的方式来换取时间上的效率，不一定可行。有一些不可分解的任务可能根本无法起作用，另一些可能需要增加额外的时间、精力等成本去了解新的工作内容。
-
系统测试的进度安排往往不太合理，这个阶段其实牵扯到所有子单元，遭遇的bug、错误往往难以估计，与乐观主义所做的假设是有区别的。
这里作者给出了一个可能的经验开发进度安排，1/3的时间给了计划、1/6用于编码，剩余的1/2分成构件测试和系统测试的两部分。其实，这个标准确实在理论上是合理的，但是许多的项目都不可能将项目的一般时间push到测试上，最后往往进度就在测试这里delay了。我在实习期间经常遇上这种事。文章还说到，一旦进度delay，造成的损失和面临的问题将会更多
-
项目经理或管理人员，在进行项目的紧急与重要程度的估计中没有标准化的说明，一般都是经验导向的。
-
重复产生的进度灾难——在项目进度delay后，过于自然地加派人手，导致了代价分析的错误度量。将会导致进度进一步delay？
CP3 外科手术队伍
- 如何在有意义的进度安排内创建大型系统？
作者的观点：需要协作沟通的人员数量影响着开发成本，因为成本的主要组成部分是相互沟通和交流，以及更正沟通不当所引起的不良结果。系统尽可能由少数人参与开发。另一方面，效率高的小而精团队与一拥而上的大团队在开发上是存在一个选择的。书中谈到了一个开发团队的建设的建议。
- 首席程序员：定义功能、性能技术说明，设计程序，编制源代码、测试及文档
- 副手：后备作用，各种备选建议与辅助开发
- 管理员：
- 编辑：文档与组织
- 两个文秘：管理员和编辑的助手
- 程序职员
- 工具维护人员
- 测试人员
- 语言专家
这种团队是与传统队伍建设不太一样，不同人员之前角色不平等而是有差异的。个体间不存在利益间的建设。可能可以达到客观的一致性。同时它也是一种专业化的分工。
这个结构在系统的构建上保留了完整性——有一个系统结构师自顶向下的进行了所有的设计。系统结构师必须清楚地划分体系结构和现实之间的界线，必须一丝不苟地专注于体系结构的建设。
小结： 这一章中主要是讲到了一个开发团队的结构设计，从一个系统结构师的角度去考虑，如何能够给出一种可靠的队伍建设的建议，并且给出了不通过角色的解释。其实，这种队伍的建设是我之前所没有了解到的，可能我们之前大部分了解到的都是具体到项目的实现中，每个人负责一个模块，各个模块是相互耦合和关联的，在项目进行的过程中不会有人全程参与所有的系统设计。但是，在实际的项目开发中，许多人脱离了系统的本身，而专注于自身的任务，没有了其他职责或背景的支持，可能在沟通和联调中产生问题。
（续）但是，若对于一个大型系统的开发而言，这样的模式是否真的实用。队伍扩充后，对不同的任务或职责所司专业人员的把控也不见得就有这么契合吧？ 比如各类技术人员开发效率的差异与分化后的职责分配问题，会不会在系统级联调的时候出现一些其他的问题？这是我的一个小的疑问。
CP4 贵族专制、民主政治和系统设计
作者主张概念完整性是系统设计中最重要的考虑因素，从教堂建造的例子引入，提到了在系列连贯的设计思路中，可以省略一些不规则的特性与改进，哪怕对于一些很好的设计概念。
简洁和直白来自概念的完整性。概念的完整性须由一个人或非常少数的人来实现。这一点与进度压力需要很多人员参与相矛盾，解决矛盾的方法可能是有限的。概念结构的完整性可能反映的是唯一的设计理念，但是经验却表示该开发模式下系统需要的开发会变得更加高效。
CP5 画蛇添足
面对体系结构上的设计，结构师在第一次系统搞设计的时候，应该是尽早与需求商商议的、并且需要其持续的沟通，来保证系统的开发任务。在这个过程中如果出现未能预见的问题，一般的建议不是寻求体系结构的更变，因为这会导致和开发人员的矛盾和导致不必要的开发成本。
谈到二次系统建设时，因为系统技术和功能的特殊性变化，系统结构师们应当有意识地关注，避免对于开发中功能上的过于装饰和技术细化，还是依赖原始的系统设计理念，在确保原则的基础上尽可能地保持完整性的开发过程。
CP6 贯彻执行
从上两章提出的概念完整性的保障：给出了一些可行的实施方案。包括了如何从文档化及手册管理、形式化规则与定义、举行会议和大会为保障、提供多重实现，并且在电话日志和产品测试方面进行记录与监督。以上几个方面，分别从不同的角度对系统设计开发中面临的不同问题进行了可行性的建议，并分析了其效果与效率，一种可能的解释是，在这些方向能够贯彻实际落实的话，某一个系统的概念的完整性是能够实现的。这样使得为系统更好地实现带来了更多的概念支持。
CP7 为什么巴比伦会失败
巴比伦这个工程无论是在人力、物力和财力上都是具有足够支持的，其失败的原因在于缺乏了团队的交流与合作，各子单位在争吵中逐渐走向破裂，导致了最终的失败。类比到软件项目的管理中来，这些经验教训能够发挥很大的启发作用。在大型项目地开发中，使用非正式途径、会议或者工作手册，加强同项目中各个人员的交流和合作，能够有效的保障系统的顺利开发。
其中，项目工作手册是项目的一系列的组织结构与规范，涵盖了所有的文档、说明、用户手册等内容。使用项目手册不仅能够保障项目文档本身的结构，还可以控制信息发布的准则。项目手册还提供了一种处理问题机制的方式方法。另一方面，项目的组织结构，需要从人员、任务、责任几个方面出发，在进行人力划分与职责分配时，要考虑相互沟通交流的因素。组织和交流，是需要管理者同软件技术一样重要的考虑点。
CP8 胸有成竹
系统的编程进程及工作量的估计是需要有一个合理且动态的调整郭晨的，项目的进展或工作量不仅仅是包含了编码，还应该将开发人员的协调、沟通和交流都考虑进来，进行合理、实际的综合评估，从而完成对项目的整体把握和控制。
书中另外在此章篇幅中给出了一些关于编程人员生产率研究的数据分析，来充分说明生产效率的矛盾性。
CP9 削足适履
谈到程序空间本身，也是作为成本的一部分，包含在程序开发的过程中。我们在开发过程中不仅仅要考虑编码本身，还要考虑编码之外甚至硬件的成本。所以，需要对项目规模进行一个可细化的设置与分配，避免浪费了不必要的规模空间。
对项目经理而言，需要通过研究用户及其需求，进行开发系统的规模控制，这是管理工作层面的。规模设置需要同其他工作进行动态的控制，需要对项目本身进行深入了解后进行一些技巧性的配置。作者通过OS/360的实例，讲到了规模的设置应该是从所有方面进行预算编入的而不仅是核心编程。另一方面，在设立单元核心模块的同时，应该对其设置访问预算，项目分解成子模块本身也需要耗费一定的规模设计成本。
CP10 提纲挈领
项目工作中，会存在许多文案，也就是技术之外的许多管理性的工作。在进行项目文档的管理开展中，需要注意一些关键点：
- 什么是软件产品中的关键文档：内容、目标、产品技术说明、进度、预算、工作空间分配、人员结构
- 正式的文档能够提供有必要的决策和记录，一来可以作为项目开发的各种规范与约束，另一方面也是不同人员之间沟通的标准和参考，也有助于数据基础和检查列表，在后续的辅助工作和调整中进行记录。
- 项目经理是生产各类文档的出发点，这些内容也是基础软件开发成果的一部分。