小白的读书笔记（一）《人月神话》

1、并不是所有的努力都是成功的

2、成本和进度不可直接粗暴使用“人月”为单位，人数和时间在大多情况下是不可替换的。

         第一种情况，任务可分解，而且人员之间不需要相互交流，但这种情况几乎不可能

         第二种情况，无法分解的任务

         第三种情况，可以分解，子任务之间需要沟通。采用增加忍受来减少时间得到的最好情况，也比未调整前差一些。

         第四种情况，关系错综复杂的任务，工作量按照n(n-1)/2递增

3、

4、对于软件任务的进度安排，以下是我使用了很多年的经验法则：

1/3计划

1/6编码

1/4构件测试和早期系统测试

1/4系统测试，所有的构件已完成

5、向进度落后的项目中增加人手，只会使进度更加落后。

6、需要协作沟通的人员的数量影响着开发成本，因为成本的主要组成部分是相互的沟通和交流，以及更正沟通不当所引起的不良结果。这一点，也暗示系统应该由尽可能少的人员来开发。

6、一个经典精炼的编程队伍 10人

         外科医生。Mills称之为首席程序员。他亲自定义功能和性能技术说明书，设计程序，

编制源代码，测试以及书写技术文档。他使用例如PL/I的结构化编程语言，拥有对计算机

系统的访问能力；该计算机系统不仅仅能进行测试，还存储程序的各种版本，以允许简单的

文件更新，并对他的文档提供文本编辑能力。首席程序员需要极高的天分、十年的经验和应

用数学、业务数据处理或其他方面的大量系统和应用知识。

副手。他是外科医生的后备，能完成任何一部分工作，但是相对具有较少的经验。他

的主要作用是作为设计的思考者、讨论者和评估人员。外科医生试图和他沟通设计，但不受

到他建议的限制。副手经常在与其他团队的功能和接口讨论中代表自己的小组。他需要详细

了解所有的代码，研究设计策略的备选方案。显然，他充当外科医生的保险机制。他甚至可

能编制代码，但针对代码的任何部分，不承担具体的开发职责。

管理员。外科医生是老板，他必须在人员、加薪等方面具有决定权，但他决不能在这

些事务上浪费任何时间。因而，他需要一个控制财务、人员、工作地点安排和机器的专业管

理人员，该管理员充当与组织中其他管理机构的接口。Baker建议仅在项目具有法律、合同、

报表和财务方面的需求时，管理员才具有全职责任。否则，一个管理员可以为两个团队服务。

编辑。外科医生负责产生文档——出于最大清晰度的考虑，他必须书写文档。对内部

描述和外部描述都是如此。而编辑根据外科医生的草稿或者口述的手稿，进行分析和重新组

织，提供各种参考信息和书目，对多个版本进行维护以及监督文档生成的机制。

两个秘书。管理员和编辑每个人需要一个秘书。管理员的秘书负责项目的协作一致和

非产品文件。

程序职员。他负责维护编程产品库中所有团队的技术记录。该职员接受秘书性质的培

训，承担机器码文件和可读文件的相关管理责任。

工具维护人员。现在已经有很多文件编辑、文本编辑和交互式调试等工具，因此团队

很少再需要自己的机器和机器操作人员。但是这些工具使用起来必须毫无疑问地令人满意，

而且需要具备较高的可靠性。外科医生则是这些工具、服务可用性的唯一评判人员。他需要

一个工具维护人员，保证所有基本服务的可靠性，以及承担团队成员所需要的特殊工具（特

别是交互式计算机服务）的构建、维护和升级责任。即使已经拥有非常卓越的、可靠的集中

式服务，每个团队仍然要有自己的工具人员。因为他的工作是检查他的外科医生所需要的工

具。工具维护人员常常要开发一些实用程序、编制具有目录的过程库以及宏库。

测试人员。外科医生需要大量合适的测试用例，用来对他所编写的工作片段，以及对

整个工作进行测试。因此，测试人员既是为他的各个功能设计系统测试用例的对头，同时也

是为他的日常调试设计测试数据的助手。他还负责计划测试的步骤和为测试搭建测试平台。

语言专家。随着Algol语言的出现，人们开始认识到大多数计算机项目中，总有一两

个乐于掌握复杂编程语言的人。这些专家非常有帮助，很快大家会向他咨询。这些天才不同

于外科医生，外科医生主要是系统设计者以及考虑系统的整体表现。而语言专家则寻找一种

简洁、有效的使用语言的方法来解决复杂、晦涩或者棘手的问题。他通常需要对技术进行一

些研究（两到三天）。通常一个语言专家可以为两个到三个外科医生服务。

客观的一致性。所有的决定权集中于“外科医生”手中。

7、由于目标是易用性，功能与理解上复杂程度的比值才是系统设计的最终测试标准。单

是功能本身或者易于使用都无法成为一个好的设计评判标准。

8、项目经理如何避免画蛇添足（second-systemeffect）？他必须坚持至少拥有两个系

统以上开发经验结构师的决定。同时，保持对特殊诱惑的警觉，他可以不断提出正确的问题，

确保原则上的概念和目标在详细设计中得到完整的体现。

         第二个项目避免不了添加一些不必要但是看起来很炫酷的功能，但其实并没有什么卵用。

9、周例会的作用

1）   数月内，相同小组——结构师、用户和实现人员——每周交流一次。因此，大家对

项目相关的内容比较了解，不需要安排额外时间对人员进行培训。

2）   上述小组十分睿智和敏锐，深刻理解所面对的问题，并且与产品密切相关。没有人

是“顾问”的角色，每个人都要承担义务。

3）   当问题出现时，在界线的内部和外部同时寻求解决方案。

4）   正式的书面建议集中了注意力，强制了决策的制订，避免了会议草稿纪要方式的不

一致。

5）   清晰地授予首席结构师决策的权力，避免了妥协和拖延。

10、对于存有疑问的实现人员，应鼓励他们打电话询问相应的结构师，而不是一边

自行猜测一边工作，这是一项很基本的措施。他们还需要认识到的是，上述问题的答案必须

是可以告知每个人的权威性结论。

         一种有用的机制是由结构师保存电话日志。日志中，他记录了每一个问题和相应的回

答。每周，对若干结构师的日志进行合并，重新整理，并发布给用户和实现人员。这种机制

很不正式，但非常快捷和易于理解。

11、项目起初要考虑的先觉条件

1）   清晰的目标？

2）   充足的人力？

3）   充分的材料？

4）   足够的时间？

5）   足够的技术？

6）   有了上述条件，并不足够，还需要两个方面，交流，以及交流的结果，组织

12、树状编程队伍，以及要使它行之有效，每棵子树所必须具备的基本要素。它们是：

4000
1. 任务（a mission）

2. 产品负责人（a producer）

他组建团队，划分工作及制订进度表。他要求，并一直要求必要的资源。

这意味着他主要的工作是与团队外部，向上和水平地沟通。

他建立团队内部的沟通和报告方式。

最后，他确保进度目标的实现，根据环境的变化调整资源和团队的构架

3. 技术主管和结构师（a technical director or architect）

他对设计进行构思，识别系统的子部分，指明从外部看上去的样子，勾画它的内部结构。

他提供整个设计的一致性和概念完整性；

他控制系统的复杂程度。当某个技术问题出现时，他提供问题的解决方案，或者根据需要调整系统设计。

他是“攻坚小组中的独行侠”（inside-manat the skunk works.）。

他的沟通交流在团队中是首要的。他的工作几乎完全是技术性的。

4. 进度（a schedule）

5. 人力的划分（a division of labor）

6. 各部分之间的接口定义（interface definitions among the parts）

其中较为复杂的是产品负责人和技术主管之间的关系

产品负责人和技术主管是同一个人。这种方式非常容易应用在很小型的队伍中，可能是三个或六个开发人员。在大型的项目中则不容易得到应用。原因有两个：第一，同时具有管理技能和技术技能的人很难找到。

产品负责人作为总指挥，技术主管充当其左右手。这种方法有一些困难。很难在技术主管不参与任何管理工作的同时，建立在技术决策上的权威。产品责任人必须对技术主管的技术才能表现出尊重。

技术主管作为总指挥，产品负责人充当其左右手。对小型的团队是最好的选择。

13、实践是最好的老师，但是，如果不能从中学习，再多的实践也没有用。

14、看似有效的编程时间中，其实真正有效率的编程时间只占1/2，其余高优先级的工作，比如会议、写文档、写日志会占用1/2的时间。

15、规模控制

1）和制订驻留空间预算一样，应该制订总体规模的预算；和制订规

模预算一样，应该制订后台存储访问的预算。

2）在指明模块有多大的同时，确切定义模块的功能。

3）项目规模本身很大，缺乏管理和沟通。系统结构师必须保持持续的警觉，确保连贯的系统完整性。在这种监督机制之外，是实现人员自身的态度问题。培养开发人员从系统整体出发、面向用户的态度是软件编程管理人员最重要的职能。

16、空间技能

         1）用功能交换尺寸

2）空间－时间的折衷。

17、计算机产品的文档，任何管理任务的关注焦点都是时间、地点、人物、做什么、资金。

         目标：定义待满足的目标和需要，定义迫切需要的资源、约束和优先级。

技术说明：计算机手册和性能规格说明。它是在计划新产品时第一个产生，并且最后完成的文档

进度、时间表

预算：预算不仅仅是约束。对管理人员来说，它还是最有用的文档之一。预算的存在会迫使技术决策的制订，否则，技术决策很容易被忽略。更重要的是，它促使和澄清了策略上的一些决定。

组织机构图

工作空间的分配

报价、预测、价格：这三个因素互相牵制，决定了项目的成败。

18、项目经理的基本职责是使每个人都向着相同的方向前进，所以他的主要工作是沟通，而不是做出决定。这些文档能极大地减轻他的负担。

19、不变只是愿望，变化才是永恒。

20、普遍的做法是，选择一种方法，试试看；如果失败了，没关系，再试试别的。不管怎么样，重要的是先去尝试。

21、管理上的问题不再是“是否构建一个试验性的系统，然后抛弃它？”你必须这

样做。

22、为舍弃而计划，无论如何，你一定要这样做。

23、变化是与生俱来的，不是不合时宜和令人生厌的异常情况。目标上的一些变化无可避免，事先为它们做准备总比假设它们不会出现要好得多。不但目标上的变化不可避免，而且设计策略和技术上的变化也不可避免。抛弃原型概念本身就是对事实的接受——随着学习的过程更改设计。

24、变更的阶段化是一种必要的技术。每个产品都应该有数字版本号，每个版本都应该有

自己的日程表和冻结日期，在此之后的变更属于下一个版本的范畴。

25、管理人员需要参与技术课程，高级技术人才需要进行管理培训。项目目标、进展、管

理问题必须在高级人员整体中得到共享。

26、系统软件开发是减少混乱度（减少熵）的过程，所以它本身是处于亚稳态的。软件维

护是提高混乱度（增加熵）的过程，即使是最熟练的软件维护工作，也只是放缓了系统退化

到非稳态的进程。

27、一些糟糕的系统往往就是试图挽救一个基础很差的设计，而对它添加了很多表面装饰般的补丁。自顶向下的方法减少了这样的企图。

28、系统调试花费的时间会比预料的更长

29、不了解，就无法真正拥有

30、不同用户需要不同级别的文档。某些用户仅仅偶尔使用程序，有些用户必须依赖程序，

还有一些用户必须根据环境和目的的变动对程序进行修改。

使用程序

1）   目的。主要的功能是什么？开发程序的原因是什么？

2）   2. 环境。程序运行在什么样的机器、硬件配置和操作系统上？

3）   3. 范围。输入的有效范围是什么？允许显示的合法范围是什么？

4）   4. 实现功能和使用的算法。精确地阐述它做了什么。

5）   5. 输入－输出格式。必须是确切和完整的。

6）   6. 操作指令。包括控制台及输出内容中正常和异常结束的行为。

7）   7. 选项。用户的功能选项有哪些？如何在选项之间进行挑选？

8）   8. 运行时间。在指定的配置下，解决特定规模问题所需要的时间？

9）   精度和校验。期望结果的精确程度？如何进行精度的检测？

验证程序

1）   针对遇到的大多数常规数据和程序主要功能进行测试的用例。它们是测试用例的主

要组成部分。

2）   数量相对较少的合法数据测试用例，对输入数据范围边界进行检查，确保最大可能

值、最小可能值和其他有效特殊数据可以正常工作。

3）   数量相对较少的非法数据测试用例，在边界外检查数据范围边界，确保无效的输入

能有正确的数据诊断提示。

修改程序

1）   流程图或子系统的结构图，对此以下有更详细的论述。

2）   2. 对所用算法的完整描述，或者是对文档中类似描述的引用。

3）   3. 对所有文件规划的解释。

4）   4. 数据流的概要描述——从磁盘或者磁带中，获取数据或程序处理的序列——以及在

每个处理过程完成的操作。

5）   5. 初始设计中，对已预见修改的讨论；特性、功能回调的位置以及出口；原作者对可

能会扩充的地方以及可能处理方案的一些意见

31、流程图是被吹捧得最过分的一种程序文档。事实上，很多程序甚至不需要流程图，很

少有程序需要一页纸以上的流程图。

32、另一些情况下，软件的开发目标就是兼容性。

33、软件产品扎根于文化的母体中，如各种应用、用户、自然及社会规律、计算机硬件等等。后者持续不断地变化着，这些变化无情地强迫着软件随之变化

34、软件领域中取得的最富有成效的三次进步

         高级语言。勿庸置疑，软件生产率、可靠性和简洁性上最有力的突破是使用高级语言

编程。大多数观察者相信开发生产率至少提高了五倍，同时可靠性、简洁性和理解程度也大

为提高。

分时。

统一编程环境

35、搭建（building），而不是编写（writing）系统

36、增量的方式开发。即，首先系统应该能够运行，即使未完成任何有用功能，只能正确调

用一系列伪子系统。接着，系统一点一点被充实，子系统轮流被开发，或者是在更低的层次

调用程序、模块、子系统的占位符（伪程序）等。这种开发模式对士气的推动是令人震惊的

37、软件开发是一个创造性的过程。完备的方法学可以培养和释放创造性的思维，但它无法孕育或激发创造性的过程。

38、解决软件构建根本困难的最佳方法是不进行任何开发。软件包只是达到上述目标的方

法之一，另外的方法是程序重用。实际上，类的容易重用和通过继承方便地定制是面向对象

技术最吸引人的地方。

39、编程行业“满足我们内心深处的创造渴望和愉悦所有人的共有情感”，提供了五种乐趣：

‰ 创建事物的快乐

‰ 开发对其他人有用的东西的乐趣

‰ 将可以活动、相互啮合的零部件组装成类似迷宫的东西，这个过程所体现出令人

神魂颠倒的魅力

‰ 面对不重复的任务，不间断学习的乐趣

‰ 工作在如此易于驾驭的介质上的乐趣——纯粹的思维活动，其存在、移动和运转

方式完全不同于实际物体

40、实际情况看起来要比这一点好一些：真正的权威来自于每次任务的完成

41、鼓励其他人直接将某人的代码合并到自己的产品中来获得一致性，而不是试图根据某人的技术说明开发自己的软件。