人月神话笔记.doc

人月神话笔记.doc

《人月神话笔记.doc》由会员分享，可在线阅读，更多相关《人月神话笔记.doc（6页珍藏版）》请在冰豆网上搜索。

人月神话读书笔记

（一）

第一章焦油坑

表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被

解决，但是当它们相互纠缠和积累在一起的时候，团队的行动就会变

得越来越慢。

对问题的麻烦程度，每个人似乎都会感到惊讶，并且很

难看清问题的本质。

不过，如果我们想解决问题，就必须试图先去理

解它。

--清楚地解释系统开发的困难所在。

这，就是编程。

一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共

存的创造性活动。

对于许多人而言，其中的乐趣远大于苦恼。

而本书

的剩余部分将试图搭建一些桥梁，为通过这样的焦油坑提供一些指导。

--本书的目的

第二章人月神话

1.在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还大。

导致灾难的原因是：

首先，我们对估算技术缺乏有效的研究。

第二，我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆

第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工作。

第四，对进度缺少跟踪和监督。

第五，当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。

2.系统开发过程中，乐观主义并不应该是理所应当的。

在单个任务中，“一切都将运转正常”的假设在时间进度上具有可实现性。

因为所遇的延迟是一个概率分布曲线，“不会延迟”仅具有有限的概率，所以现实情况可能会像计划安排的那样顺利。

然而大型的编程工作，或多或少包含了很多任务，某些任务间还具有前后的次序，从而一切正常的概率变得非常小，甚至接近于无。

3.成本的确随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。

因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。

它暗示着人员数量和时间是可以相互替换的。

因为软件开发本质上是一项系统的工作--错综复杂关系下的一种实践--沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。

从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。

4.在时间进度中，顺序限制所造成的影响，没有哪个部分比单元测试和系统测试所受到的牵涉更彻底。

对于任务的进度安排，以下是作者使用了很多年的经验法则：

1/3计划

1/6编码

1/4构件测试和早期系统测试（单元测试）

1/4系统测试

5.如果发现项目的实际进度滞后于预计的进度，项目经理最好的办法是重新安排进度，而不是增加项目人手。

6.项目的时间依赖于顺序上的限制，人员的数量依赖于单个子任务的数量。

从这两个数值可以推算出进度时间表，该表安排的人员较少，花费的时间较长（唯一的风险是产品可能过时）。

相反，分派较多的人手，计划较短的时间，将无法得到可行的进度表。

总之，在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还要大。

第三章外科手术队伍

1. 对于效率和概念的完整性来说，最好由少数干练的人员来设计和开发，而对于大型

系统，则需要大量的人手，以使产品能在时间上满足要求。

如何调和这两方面的矛盾呢？

 -- 本章要解决的问题

2. Mills的建议：

外科医生（首席程序员）：

定义功能和性能技术说明书，设计程序，编制源代码，测试

以及书写技术文档。

副手：

主要作用是作为设计的思考者、讨论者和评估人员。

管理员：

控制财务、人员、工作地点安排和机器，充当组织中其他管理机构的接口。

编辑：

根据外科医生的草稿或者口述的手稿，进行分析和重新组织，提供各种参考信息

和书目，对多个版本进行维护以及监督文档生成的机制。

两个秘书

程序职员：

维护编程产品库中所有团队的技术记录。

工具维护人员：

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

别是交互式计算机服务）的构建、维护和升级责任。

测试人员：

各个功能设计系统测试用例的对头，同时也是日常调试设计测试数据的助手。

负责计划测试的步骤和为测试搭建测试平台。

语言专家：

寻找一种简洁、有效的使用语言的方法来解决复杂、晦涩或者棘手的问题。

3. 当进行大系统开发时：

要有一个系统结构师从上至下地进行所有的设计。

要使工作易于管理，必须清晰地划分体

系结构设计和实现之间的界线，系统结构师必须一丝不苟地专注于体系结构。

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

1. 概念一致性

在系统设计中，概念完整性应该是最重要的考虑因素。

也就是说为了反映一系列

连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合

的系统，哪怕它们其实包含着许多很好的设计。

2. 功能与理解上复杂程度的比值才是系统设计的最终测试标准。

但是功能本身

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

3. 简洁和直白来自概念的完整性。

每个部分必须反映相同的原理、原则和一致

的折衷机制。

在语法上，每个部分应使用相同的技巧；在语义上，应具有同样的

相似性。

因此，易用性实际上需要设计的一致性和概念上的完整性。

4. 概念的完整性要求设计必须由一个人，或者非常少数互有默契的人员来实现。

5. 系统的体系结构（architecture）指的是完整和详细的用户接口说明。

体系结

构必须同实现仔细地区分开来。

6. 作者不认为只有结构师才有好的创意。

新的概念经常来自实现者或者用户。

然而系统的概念完整性决定了使用的容易程度。

不能与系统基本概念进行整合的

良好想法和特色，最好放到一边，不予考虑。

如果出现了很多非常重要但不兼容

的构想，就应该抛弃原来的设计，对不同基本概念进行合并，在合并后的系统上

重新开始。

7. 概念的完整性的确要求系统只反映唯一的设计理念，用户所见的技术说明来

自少数人的思想。

实际工作被划分成体系结构、设计实现和物理实现，但这并不

意味着该开发模式下的系统需要更长的时间来创建。

经验显示恰恰相反，整个系

统将会开发得更快，所需要的测试时间将更少。

同工作的水平分割相比，垂直划

分从根本上大大减少了劳动量，结果是使交流彻底地简化，概念完整性得到大幅

提高。

第五章画蛇添足

1.本章的目标：

结构设计师要避免向系统中添加很多不实际的功能（避免

画蛇添足）。

2.尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获

得对设计的信心，并且不会混淆各自的责任分工。

3.面对估算过高的难题，结构师有两个选择：

削减设计或者建议成本更低

的实现方法--挑战估算的结果。

后者是固有的主观感性反应。

此时，结构师

是在向开发人员的做事方式提出挑战。

想要成功，结构师必须

牢记是开发人员承担创造性和发明性的实现责任，所以结构师只能建议，而

不能支配；

时刻准备着为所指定的说明建议一种实现的方法，同样准备接受其他任何能

达到目标的方法；

对上述的建议保持低调和平静；

准备放弃坚持所作的改进建议。

4.一个可以开阔结构师眼界的准则是为每个小功能分配一个值：

每次改进，

功能x不超过m字节的内存和n微秒。

这些值会在一开始作为决策的向导

，在物理实现期间指南和对所有人的警示。

5.项目经理必须坚持至少拥有两个系统以上开发经验的结构师的决定。

同时

，保持对特殊诱惑的警觉，他可以不断提出正确的问题，确保原则上的概念和

目标在详细设计中得到完整的体现。

第六章贯彻执行

1.问题：

项目经理如何确保每个人听从、理解并实现结构师的决策？

对于有多个结构师

的小组如何保持系统概念上的完整性。

2.手册、或者书面规格说明，是一个非常必要的工具。

手册是产品的外部规格说明，它

描述和规定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。

手册不但要描述包括所有界面在内的用户可见的一切，它同时还要描述用户看不见的事物。

后者是编程实现人员的工作范畴，而实现人员的设计和创造是不应该被限制的。

体系结构

设计人员必须为自己描述的任何特性准备一种实现方法，但是他不应该试图支配具体的实

现过程。

规格说明的风格必须清晰、完整和准确。

用户常常会单独提到某个定义，所以每条说明都

必须重复所有的基本要素，所以所有文字都要相互一致。

3.规格说明中，形式化定义是精确的，它们倾向于更加完整；差异得更加明显，可以更

快地完成。

但是形式化定义的缺点是不易理解。

记叙性文字则可以显示结构性的原则，描

述阶段上或层次上的结构，以及提供例子。

应同时包括形式化和记叙性定义两种方式。

4.通过会议的方式，开发人员进行沟通和讨论问题。

5.不同实现之间严格要求相互兼容。

如果起初至少有两种以上的实现，那么定义会更加

整洁和规范。

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

测一边工作。

一种有用的机制是由结构师保存电话日志。

日志中，他记录了每一个问题和相应的回答。

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

这种机制很

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

7.在最后的分析中，用户是独立的监督人员。

在残酷的现实使用环境中，每个细微缺陷

都将无从遁形。

产品测试小组则是顾客的代理人，专门寻找缺陷。

不时地，细心的产品测

试人员总会发现一些没有贯彻执行、设计决策没有正确理解或准确实现的地方。

出于这方

面的原因，设立测试小组是使设计决策得以贯彻执行的必要手段，同样也是需要尽早着手

，与设计同时实现的重要环节。

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

　　1.项目人员之间的交流和沟通是项目能否顺利和成功的一个重要因素。

　　2.缺乏交流引起进度灾难、功能的不合理和系统缺陷纷纷出现。

随着工作的

　　进行，许多小组慢慢地修改自己程序的功能、规模和速度，他们明确或者隐含

　　地更改了一些有效输入和输出结果用法上的约定。

　　团队如何进行相互之间的交流沟通：

　　清晰定义小组内部的相互关系和充分利用电话，能鼓励大量的电话沟通，从而

　　达到对所书写文档的共同理解。

　　常规项目会议。

会议中，团队一个接一个地进行简要的技术陈述。

这种方式非

　　常有用，能澄清成百上千的细小误解。

　　在项目的开始阶段，应该准备正式的项目工作手册。

　　3.项目工作手册不是独立的一篇文档，它是对项目必须产出的一系列文档进

　　行组织的一种结构。

　　项目所有的文档都必须是该结构的一部分。

这包括目的、外部规格说明、接口

　　说明、技术标准、内部说明和管理备忘录。

　　4.使用项目工作手册的原因：

　　技术说明几乎是必不可少的。

如果某人就硬件和软件的某部分，去查看一系列

　　相关的用户手册。

他发现的不仅仅是思路，而且还有能追溯到最早备忘录的许

　　多文字和章节，这些备忘录对产品提出建议或者解释设计。

　　正确的文档结构非常重要。

事先将项目工作手册设计好，能保证文档的结构本

　　身是规范的。

另外，有了文档结构，后来书写的文字就可以放置在合适的章节

　　中。

　　控制信息发布，确保信息能到达所有需要它的人的手中。

　　5.团队组织的目的是减少不必要的交流和合作的数量。

减少交流的方法是人

　　力划分和限定职责范围。

当使用人力划分和职责限定时，树状管理结构所映出

　　对详细交流的需要会相应减少。

　　第八章胸有成竹

　　1.问题：

系统编程需要花费多长时间？

需要多少工作量？

如何进行估计？

　　2.工作量是规模的幂函数。

　　Portman的数据：

工作花费的时间大约是估计的两倍。

　　Aron、Harr、OS/360的数据：

生产率会根据任务本身的复杂度和困难程度表现出

　　显著差异。

　　Carbato的数据：

对常用的编程语句而言。

生产率似乎是固定的。

这个固定的生产

　　率包括了编程中需要注释，并可能存在错误的情况。

使用适当的高级语言，编程的

生产率可以提高5倍。

第