人月神话的几份读书笔记

winston

《人月神话》读书笔记《人月神话》作者：Frederick P. Brooks，Jr.曾荣获美国计算机领域最具声望的图灵奖（A.M.Turing Award）桂冠。美国计算机协会（ACM）称赞他"对计算机体系结构和软件工程做出了里程碑式的贡献。
一：焦油坑
   编程是什么？许多人痛苦挣扎的焦油坑。它是乐趣与苦恼共存的创造性活动。
二：人月神话
    2.1：人月不能简单的用来衡量工作的规模。
    2.2：1/3计划，1/6编码，1/4构件及早期测试   1/4系统测试。

2.3：向进度落后的项目中增加人手，只会使进度更落后。
    三：外科手术队伍
    3.1：大型项目划分为若干部分，每一部分一个团队，团队按外科手术队伍的方式组建。外科医生难求噢。
    3.2：由系统结构师来协调若干个外科医生。
四：贵族专制，民主政冶和系统设计
    4.1：为了得到概念上的一致性，需要无任何歉意的贵族专制。
    4.2：在稳定体系统结构下的实现的设计，同样需要创造性，不要低估或悲观。
    4.3：体系结构未完成，编程人员做啥？作者说：很简单，体系统结构完成后，再雇佣他们。
    4.4：有时，体系结构、开发实现、物理实现可以同时开始和并发进行。
五：画蛇添足
    5.1：结构师与承包商与开发人员应该有良好的交流准则和机制。
    5.2：设计师的第二系统往往会有毛病：一是过分设计，二是对已落后的技术进行细化和精练。
六：贯彻执行
    6.1：文档化的规格说明很有意义，另外，可再进行形式化定义，一种为主，一种为辅。
    6.2：周例会，年度大会的作用。
    6.3：多重实现可保证定义更简洁，更规范。是这样的吗？
    6.4：总结FAQ是好的工作方式。
    6.5：产品测试小组是顾客的代言人。
七：为什么巴比伦塔会失败
    7.1：失败的原因，缺乏交流以及相应的组织。
    7.2：大型项目中的交流方式：电话，会议，手册。
    7.3：项目工作手册的制作方式。
    7.4：大型项目中的正确组织架构。其中，最关键的角色，产品负责人和技术主管的多种协作方式。
八：胸有成竹
    8.1：对编程人员生产率的若干调查，得出结论：
    8.1.1：我们总是对人员的工作时间做了不现实的估计，某些其余时间被忽略了，这差不多占一半时间。
    8.1.2：交互越多，生产率越低，大致有1-3倍的差距。
    8.1.3：使用适当的高级语言，可以将生产率提高5倍。
九：削足适履
    9.1：程序空间也是成本，开发人员必须为此设计目标和实现
    9.2：规模控制的方法：制定总体规模预算，个体间多交流勾通。
    9.3：空间相关技能：功能与空间，空间与时间，技术积累。
    9.4：数据的表现形式是编程的根本。仔细思考程序的数据会得到好的效果。
十：提纲挈领
    10.1：文档的作用(在管理方面)：项目监督，预警，查查列表，状态控制，汇报的数据基础。
    10.2：软件项目的关键文档：目标，技术说明，进度，预算，工作空间分配，组织图。
    10.3：只有书面文档才是精确，可勾通，可检查的。
十一：未雨绸缪
    11.1：构建一个试验性的系统，然后抛弃它。
    11.2：为变更做准备，为变更设计系统。
    11.3：为主更建立更强大的团队，组织结构要更灵活。管理与技术人员可互换，最小化人员间的接口。
    11.4：程序维护通常是开发成本的40%,缺陷恢复通常以20%-50%的几率引入新Bug。
    11.5：软件维护是提高混乱度的过程。
十二：干将莫邪
    12.1：配备专门的工具管理人员的必要性。
    12.2：我们需要的工具：目标(辅助机器)以及合理的进度安排(这点可能已经不是什么工具了)。编程工具，文档系统，性能仿真器。
    12.3：解释高级语言与交互式编程。
十三：整体部分
    13.1：整体考虑一个系统，我们需要：
使Bug更不易产生的方式来设计。
编写测试规格说明，采用精化方式，自上由下设计.
          采用结构化编程。
    13.2：早期测试的四步：本机调试，内存转储，快照，交互式调试。
    13.3：系统集成调试的方法：使用经过调试的构件单元搭建系统。
十四；祸起萧墙
    14.1：使用里程碑来控制进度。
    14.2：采用关键路径技术来判断偏离的关键。
    14.3：老板应该尽量减少角色冲突来得到更真实的报告。
    14.4：需要拥有能了解状态真相的机制或者是通过计划和控制小组。
十五：另外一面
    15.1：用“如何做”来代替说教之词。
    15.2：程序文档的需求：使用程序，验证程序，修改程序的不同需求。
    15.3：弱化流程图的作用，并简化之。
    15.4：用程序来自动生成文档。
十六：没有银弹
    16.1：软件的根本任务——打造构成抽象软件实体的复杂概念结构，它始终未得到改进，所以，生产率不能得到数量级的提升。
    16.2：软件开发的根本困难是：规格说明、设计和测试这些概念上的结构(我没太明白噢)。
软件系统的内部特性：复杂性、一致性、可变性、不可预见性。
    16.3：解决次要问题的一些方案：高级语言、分时、统一编程。
    16.4：银弹的希望：
      
高级编程语言、面向对象编程、人工智能、专家系统、自动编程、图形化编程、程序验证、环境和工具、工作站。
    16.5：针对概念上根本问题的有前途的方法：
购买构件、需求精练、快速原型、增量开发、培养卓越的设计人员。
十七：再论“没有银弹”
    17.1：作者回应某些反驳“没有银弹”的评论。
    17.2：面向对象技术的现实情况。
    17.3：重用的情况。
十八：《人月神话》的观点：是与非？
复习人月神化中的重要的十五个观点。
十九：20年后的《人月神话》
    19.1：概念完整性需要结构师来保证。
    19.2：开发第二个系统的问题，再强调：盲目的功能，无确定的用户群，瞎猜。
    19.3：图开界面的成功。
    19.4：用增量开发模型取代不正确的瀑布式开发。
    19.5：信息隐藏的重要，不应该对开发人员公布所有技术文档，大多数，接口足以。
    19.6：人月配备与进度的平衡，再次进行证明。
    19.7：人的作用决定一切，推荐《人件》一书。
    19.8：构件开发。
    19.9：软件工程的状态和未来。

winston

第1章 焦油坑
1.1 编程系统产品（Programming Systems Product）开发的工作量是供个人

使用的、独立开发的构件程序的九倍。我估计软件构件产品化引起了3倍

工作量，将软件构件整合成完整系统所需要的设计、集成和测试又强加了

    3倍的工作量，这些高成本的构件在根本上是相互独立的。

《编程系统产品与供个人使用的、独立开发的构件程序(小型程序)之间的

工作量的差距与差距的产生的原因》
1.2 编程行业“满足我们内心深处的创造渴望和愉悦所有人的共有情感”，

    提供了五种乐趣：《职业的乐趣》

□创建事物的快乐
    □开发对其他人有用的东西的乐趣
    □将可以活动、相互啮合的零部件组装成类似迷宫的东西，这个过程

所体现出令人神魂颠倒的魅力

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

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

移动和运转方式完全不同于实际物体

1.3 同样，这个行业具有一些内在固有的苦恼：《职业的苦恼》

□将做事方式调整到追求完美，是学习编程的最困难部分

    □由其他人来设定目标，并且必须依靠自己无法控制的事物（特别是程序）

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

    □任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外

    □人们通常期望项目在接近结束时，（bug、工作时间）能收敛得快一些，

然而软件项目的情况却是越接近完成，收敛得越慢

    □产品在即将完成时总面临着陈旧过时的威胁

《焦油坑我理解是，人数少的项目，灵活而容易控制，但人数众多的大型项目

像史前巨兽在焦油坑里挣扎一样，很难控制进程，很难推进，而且很难看清

无法推进的本质原因。并且我们无法用小型团队来开发大型系统。我觉得

可能中国还没有(或非常非常少)真正意义上的参加人数众多的大型项目，

焦油坑对于末端程序员的表现是，很多没有解决的或自己没掌握的问题，

天天加班熬夜来解决，但自己始终解决不了，上头天天催促，压力倍增，

看不到尽头，觉得提交物(或大家做的东西)是一堆垃圾。》

---------------------------------------------------------------------

第2章 人月神话

   2.1 缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素

加起来影响还大。

       《合理的时间进度我觉得是最难把握的，可能人数较少的项目某个个人

能控制进度，但人数众多时，应该是推测的性质很大，好像只能展开

项目并推动项目，好像无法(或很难）控制项目》
   2.2 良好的烹饪需要时间，某些任务无法在不损害结果的情况下加快速度。

       《质量是需要相应时间的，某些时候不牺牲质量是无法加快速度

这里的质量观应该和中国程序员的质量观有本质的区别，不仅仅是

软件正确运行》

   2.3 所有的编程人员都是乐观主义者：“一切都将运作良好”。

       《我们进行项目时尽管有很多问题，但都会倾向于乐观》
   2.4 由于编程人员通过纯粹的思维活动来开发，所以我们期待在实现过程中

       不会碰到困难。
   2.5 但是，我们的构思是有缺陷的，因此总会有bug。
   2.6 我们围绕成本核算的估计技术，混淆了工作量和项目进展。人月是危险和

带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。

       《大型项目的预算是按照人月（一个人一个月的工作量）来计算的，

这里是说比如1个人10月的工作总量，与10个人一个月的总量，不能

等同，也就是人员数量和时间是不可以相互替换的》
   2.7 在若干人员中分解任务会引发额外的沟通工作量——培训和相互沟通。

       《人多了以后会引发额外的沟通工作量，培训和相互沟通(也就是

我们长说的边学习边干活)》
   2.8 关于进度安排，我的经验是为1/3计划、1/6编码、1/4构件测试以及

       1/4系统测试。

       《需求分析,基本设计,详细设计是需要整个开发期间的1/3的时间，

编写代码是需要整个开发期间的1/6的时间，然后单元测试、集成测试、

需要1/4的时间，确认测试和系统测试（及发版测试）需要1/4.时间。

在国内应该很少有这样的标准开发了》
   2.9 作为一个学科，我们缺乏数据估计。

       《人多了以后会我觉得很多都是未定，很难或不可能估计得到》

   2.10 因为我们对自己的估计技术不确定，所以在管理和客户的压力下，

我们常常缺乏坚持的勇气。

       《我理解是无法争取充分的时间》
   2.11 Brook法则：向进度落后的项目中增加人手，只会使进度更加落后。

       《我觉得100%正确，无论多厉害的人也不可能马上知道项目独有的

业务，（除非是他设计的），这就意味着想让新加的人干活，就需

要额外的很多时间和工作量，人数越多，工作量就越大》

   2.12 向软件项目中增派人手从三个方面增加了项目必要的总体工作量：

任务重新分配本身和所造成的工作中断；培训新人员；额外的相互沟通。

       《我觉得100%正确，所以加的人越多就意味着得让更多的人通过沟通

理解你的东西，这谈何容易，人与人的沟通在任何行业都是非常

困难的呀》

《我的理解：这一章的主要表示，软件开发中的工作量的预测问题（也可以

是预算的问题），解释工作量的产生原因。这里非常想强调的是在一个

项目中人与人的沟通的必要性和重要性和不易控制性》

----------------------------------------------

第3章外科手术队伍

3.1 同样有两年经验而且在受到同样的培训的情况下，优秀的专业程序员的

工作效率是较差程序员的十倍。（Sackman、Erikson和Grand）

    《这句话100%赞同，每个程序员的效率都是不一样的，会干活的

效率高，不会干活的效率低，这与技术的高低无关，取决于个人》

3.2 Sackman、Erikson和Grand的数据显示经验和实际表现之间没有相互联系。

我怀疑这种现象是否普遍成立。

    《回想以前的各种团队，我也怀疑普遍存在。》

3.3 小型、精干队伍是最好的——尽可能的少。

    《人员少沟通的工作量，培训的工作量就少，容易控制推进项目》

3.4 两个人的团队，其中一个项目经理，常常是最佳的人员使用方法。

    [留意一下上帝对婚姻的设计。]

    《2个人的团队是沟通量最少，所以最容易相互配合》

3.5 对于真正意义上的大型系统，小型精干的队伍太慢了。

    《确实。。比如像windows这样的系统，几个人开发出来是绝不可能》

3.6 实际上，绝大多数大型编程系统的经验显示出，一拥而上的开发方法是

高成本、速度缓慢、不充分的，开发出的产品无法进行概念上的集成。

    《确实。。一拥而上的后果，出现大量的培训工作，也无法统一概念

也就是无法正确传达要做成什么样子，我觉得应该是少数人开始，

每过一段时间慢慢增加人手，在这个一段时间内传播概念，然后再

让他们传播下一批增加的人，慢慢增加人手，达到顶峰以后，又慢慢

撤出人员》

3.7 一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法——

既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体

生产率，还彻底地减少了沟通的工作量。

    《确实，一个小项目以小型团队以外科手术队伍的模式进行可能是

最好的，因为所有的问题集中到这个人身上，并由这个人来解决问题，

分派任务，监督控制并推进项目，但一旦这个首席程序员出错时，也

意味着项目的失败，这个觉得和外科手术失败和主治医生有很大关系，

但一个大项目呢？也能这样吗？高级手术队伍中有个主治医生和几个

助手，这几个助手又是中级手术队伍中的主治医生，并又有几个助手，

并且这几个助手又是，末端手术队伍中的主治医生，并也有几个最

末端的助手。这有点像是中国自古的中央集权制？》

--------------------------------------------------------

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

4.1 “概念完整性是系统设计中最重要的考虑因素”。

《可能每个人都有自己的逻辑，参加设计（外部设计）的人越多，

也就设计越乱，也就是人脑中的概念（思想）很难统一》
4.2 “功能与理解上的复杂程度的比值才是系统设计的最终测试标准”，

而不仅仅是丰富的功能。[该比值是对易用性的一种测量，由简单和

复杂应用共同验证。]

  
4.3 为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。

   《非常赞同：人多了，思想很难统一，所以设计人要少》

4.4 “对于非常大型的项目，将设计方法、体系结构方面的工作与具体

实现相分离是获得概念完整性的强有力方法。”

    [同样适用于小型项目。]

   《我理解是，为了统一概念，先做一些设计方法、体系结构等的

统一，然后根据这些来实现。》

  
4.5 “如果要得到系统概念上的完整性，那么必须控制这些概念。

这实际上是一种无需任何歉意的贵族专制统治。”

   《概念没有绝对的对错，也有好多种，可能因人而异，但具体要用什么

概念是强制决定的，并所有人强制执行，我理解这是人数较多项目

必须要做到的事情。》

   
4.6 纪律、规则对行业是有益的。外部的体系结构规定实际上是增强，

而不是限制实现小组的创造性。

    《外部的体系结构规定我理解是基本设计也就是外部设计，

有规定，所有设计人员按照规定走，是增强了创造性，

而不是限制，要是无规则，每个人（每个小组）做出来的东西

全都不一样，10个人10个样子，最后出来一堆垃圾》

4.7 概念上统一的系统能更快地开发和测试。

    《概念上不统一的系统，开发人员，测试人员，谁知道这个模块

是这么做的，但别的模块又怎么做》

4.8 体系结构（architecture）、设计实现（implementation）、

物理实现（realization）的许多工作可以并发进行。[软件和

硬件设计同样可以并行。]

    《一起并发做，也就是相互考虑的意思吧，体系结构时，考虑

到实现等》

----------------------------------------------------------

第5章画蛇添足

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

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

    《尽早交流和持续沟通，一针见血，就是说尽量不要把问题

留给以后，要不然这些问题，是谁的责任？》
5.2 结构师如何成功地影响实现：

  《结构师应该是基本设计者，也就是外部设计者（Input output设计）》
?□牢记是开发人员承担创造性的实现责任；

  《开发人员是实现的人，不是自己，也就是说得为他们考虑某些事情》
   □结构师只能提出建议。

  《建议的形式提出意见（毕竟人家做东西）》
   □时刻准备着为所指定的说明建议一种实现的方法，准备接受

任何其他可行的方法。

   《毕竟你自己也是人，会犯错误，有没想到的地方，所以必须倾听

另一种实现方法，并接受任何其他可行的方法》

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

   《没必要高调自己的建议，假如是正确的建议，开发人员会认同

。假如高调开发人员很难提出更好的建议》

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

   《我理解是，即便建议是对的，但假如不被采纳时应该放弃》

   □听取开发人员在体系结构上改进的建议。

   《很有必要，因为可否实现的主要责任，应该由结构设计师来负责，

次要责任是开发人员负责，也就是说实现不了不仅仅是开发人员的

责任。所以应该倾听开发人员的建议》

   
5.3 第二个系统是人们所设计的最危险的系统，通常的倾向是过分地进行设计。

   《正确，第一个一般做的小心，但成功以后信心倍增，第二个系统想要做一个

更好的东西，很多时候信息无限膨胀，导致设计脱离实际。会有过分设计

（要求过分多），危险》

5.4 OS/360是典型的画蛇添足（second-system effect）的例子。[Windows

    NT似乎是90年代的例子。]

   《这两个东西我都没见过，但作者的意思我猜是，做这两个东西的人们

当初可能设想做个[完美？]的东西，但效果远远不如设想？》

5.5 为功能分配一个字节和微秒的优先权值是一个很有价值的规范化方法。

   《才疏学浅无法理解，抱歉》

-----------------------------------------------------

第六章 贯彻执行

1.  问题：项目经理如何确保每个人听从、理解并实现结构师的决策？对于有多个结构师
的小组如何保持系统概念上的完整性。

2.  手册、或者书面规格说明，是一个非常必要的工具。手册是产品的外部规格说明，它
描述和规定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。

手册不但要描述包括所有界面在内的用户可见的一切，它同时还要描述用户看不见的事物。
后者是编程实现人员的工作范畴，而实现人员的设计和创造是不应该被限制的。体系结构
设计人员必须为自己描述的任何特性准备一种实现方法，但是他不应该试图支配具体的实
现过程。

规格说明的风格必须清晰、完整和准确。用户常常会单独提到某个定义，所以每条说明都
必须重复所有的基本要素，所以所有文字都要相互一致。

3.  规格说明中，形式化定义是精确的，它们倾向于更加完整；差异得更加明显，可以更
快地完成。但是形式化定义的缺点是不易理解。记叙性文字则可以显示结构性的原则，描
述阶段上或层次上的结构，以及提供例子。应同时包括形式化和记叙性定义两种方式。

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

5.  不同实现之间严格要求相互兼容。如果起初至少有两种以上的实现，那么定义会更加
整洁和规范。

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

一种有用的机制是由结构师保存电话日志。日志中，他记录了每一个问题和相应的回答。
每周，对若干结构师的日志进行合并，重新整理，并发布给用户和实现人员。这种机制很
不正式，但非常快捷和易于理解。

7.  在最后的分析中，用户是独立的监督人员。在残酷的现实使用环境中，每个细微缺陷
都将无从遁形。产品测试小组则是顾客的代理人，专门寻找缺陷。不时地，细心的产品测
试人员总会发现一些没有贯彻执行、设计决策没有正确理解或准确实现的地方。出于这方
面的原因，设立测试小组是使设计决策得以贯彻执行的必要手段，同样也是需要尽早着手
，与设计同时实现的重要环节。

--------------------------------------------------------

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

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

2.  缺乏交流引起进度灾难、功能的不合理和系统缺陷纷纷出现。随着工作的
进行，许多小组慢慢地修改自己程序的功能、规模和速度，他们明确或者隐含
地更改了一些有效输入和输出结果用法上的约定。

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

清晰定义小组内部的相互关系和充分利用电话，能鼓励大量的电话沟通，从而
达到对所书写文档的共同理解。

常规项目会议。会议中，团队一个接一个地进行简要的技术陈述。这种方式非
常有用，能澄清成百上千的细小误解。

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

3.  项目工作手册不是独立的一篇文档，它是对项目必须产出的一系列文档进
行组织的一种结构。

项目所有的文档都必须是该结构的一部分。这包括目的、外部规格说明、接口
说明、技术标准、内部说明和管理备忘录。

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

技术说明几乎是必不可少的。如果某人就硬件和软件的某部分，去查看一系列
相关的用户手册。他发现的不仅仅是思路，而且还有能追溯到最早备忘录的许
多文字和章节，这些备忘录对产品提出建议或者解释设计。

正确的文档结构非常重要。事先将项目工作手册设计好，能保证文档的结构本
身是规范的。另外，有了文档结构，后来书写的文字就可以放置在合适的章节
中。

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

5.  团队组织的目的是减少不必要的交流和合作的数量。减少交流的方法是人
力划分和限定职责范围。当使用人力划分和职责限定时，树状管理结构所映出
对详细交流的需要会相应减少。

-----------------------------------------------------------

第八章 胸有成竹

1.  问题：系统编程需要花费多长时间？需要多少工作量？如何进行估计？

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

Portman的数据：工作花费的时间大约是估计的两倍。

Aron、Harr、OS/360的数据：生产率会根据任务本身的复杂度和困难程度表现出
显著差异。

Carbato的数据：对常用的编程语句而言。生产率似乎是固定的。这个固定的生产
率包括了编程中需要注释，并可能存在错误的情况。使用适当的高级语言，编程的
生产率可以提高5倍。

-----------------------------------------------------------

第九章 削足适履

1.  系统的空间规模：规模是软件系统产品用户成本中如此大的一个组成部分，开发
人员必须设置规模的目标，控制规模，考虑减小规模的方法。同任何开销一样，规模
本身不是坏事，但不必要的规模是不可取的。

2.  对项目经理而言，规模控制既是技术工作的一部分，也是管理工作的一部分。必
须研究用户和他们的应用，以设置将开发系统的规模。接着，把这些系统划分成若干
部分，并设定每个部分的规模目标。由于规模--速度权衡方案的结果在很大的范围内
变化，规模目标的设置是一件颇具技巧的事情，需要对每个可用方案有深刻的了解。
聪明的项目经理还会给自己预留一些空间，在工作推行时分配。

仅对核心程序设定规模目标是不够的，必须把所有的方面都编入预算。

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

培养开发人员从系统整体出发，面对用户的态度。

3.  在速度不变的情况下，更多的功能意味着需要更多的空间。其中一个技巧是用功
能交换尺寸。设计人员必须决定用户可选项目的精细程度。

4.  考虑空间--时间的折衷。对于给定的功能，空间越多，速度越快。

项目经理可以做两件事来帮助他的团队取得良好的空间--时间折衷。一是确保他们在
编程技能上得到培训，而不仅仅是依赖他们自己掌握的知识和先前的经验。特别是使
用新语言或者新机器时，培训显得尤其重要。另一种方法是认识到编程需要技术积累，
需要开发很多公共单元构件。

5.  战略上的突破常来自数据或表的重新表达--这是程序的核心所在。数据的表现形
式时编程的根本。

------------------------------------------------------------

第十章 提纲挈领

1.  文档的跟踪维护是项目监督和预警的机制。文档本身可以作为检查
列表、状态控制，也可以作为汇报的数据基础。

2.  软件项目文档的内容：

目标。待完成的目标、迫切需要的资源、约束和优先级。

产品技术说明。

进度表。

资金预算。

工作空间分配。

人员组织。

3.  为什么要有正式的文档

首先，书面记录决策是必要的。人们能从令人迷惑的现象中得到清晰、确
定的决策。

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

最后，文档可以作为数据基础和检查列表。通过周期性的回顾，他能清楚
项目所处的状态，以及哪些需要重点进行更改和调整。

项目经理的任务是制订计划，并根据计划实现。只有书面计划是精确和可
以沟通的。通过遵循文档开展工作，项目经理能更清晰和快速地设定自己
的方向。

----------------------------------------------------------

第十一章 未雨绸缪

1.  对于大多数项目，第一个开发的系统并不合用。可能太慢、太大，而且难以
使用，或者三者兼而有之。要解决所有的问题，除了重新开始以外，没有其他的
办法--即开发一个更灵巧或者更好的系统。系统的丢弃和重新设计可以一步完成
，也可以一块块地实现。所有大型系统的经验都显示，这是必须完成的步骤。
-- 构建一个试验性的系统，然后抛弃它。

2.  一旦认识到实验性的系统必须被构建和丢弃，具有变更思想的重新设计不可
避免。

3.  为变化设计系统，包括细致的模块化、可扩展的函数、精确完整的模块间接
口设计、完备的文档。另外，还可能会采用包括调用队列和表驱动技术。

最重要的措施是使用高级语言和自文档技术，以减少变更引起的错误。采用编译
时的操作来整合标准说明，在很大程度上帮助了变化的调整。

变更的阶段化是一种必要的技术。每个产品都应该有数字版本号，每个版本都应
该有自己的日程表和冻结日期。在此之后的变更属于下一个版本的范畴。

4.  为变更计划组织架构和团队。

5.  程序维护中的一个基本问题是 -- 缺陷修复总会以(20%--50%)的机率引入新
的bug。整个过程是前进两步，后退一步。作为引入新bug的一个后果，程序每条
语句的维护需要的系统测试比其他编程要多，成本非常高。

缺陷不能被彻底修复的原因：

首先，看上去很轻微的错误，似乎仅仅是局部操作上的失败，实际上却是系统级
别的问题。其次，维护人员通常不是编写代码的开发人员。

5.  使用能消除、至少是能指明副作用的程序设计方法，会在维护成本上有很大
的回报。设计实现的人员越少、接口越少，产生的错误也就越少。

6.  维护工作破坏系统的架构，增加了系统的混乱程度。随着时间的推移，系统
变得越来越无序，无法再成为下一步进展的基础。这时，系统的重新设计完全是
必要的。

系统软件开发是减少混乱度的过程，软件维护是提高混乱度的过程，即使是最熟
练的软件维护工作，也只是放缓了系统退化的进程。

winston

人月神话阅读笔记

简介
人月神话
软件项目管理领域很少能有著作能像《人月神话》一样具有影响力和畅销不衰。Brooks为任何人管理复杂项目提供了颇具洞察力的见解，既有很多发人深醒的观点，也有大量的软件工程现实。这些论文出自Brooks的IBM System/360家族和OS/360项目管理经验。在第一次出版20年后的今天，Brooks重新审视了他原先的观点，增加了一些新的想法和建议。这既是为了熟悉原有内容的人们，也为了第一次阅读它的读者。
增加的章节包括（1）原著中的所提出观点的一些精华，包括Brooks《人月神话》的核心论点：由于人力的划分，大型项目遭遇的管理问题与小型项目的不同；因此，产品的概念完整性很关键；取得这种统一性是很困难，但并不是不可能的。（2）一个时代以后，Brooks对这些观点的看法。（3）重新收录了1986年的经典文章《没有银弹》。（4）以及对1986年所下论断——“在十年内不会出现银弹。”——现在的认识。

作者
FREDERICK P. BROOKS, JR.
Frederick P. Brooks，Jr.是北卡罗来纳大学Kenan-Flagler商学院的计算机科学教授，北卡来罗来纳大学位于美国北卡来罗来纳州的查布尔希尔。Brooks被认为是“IBM 360系统之父”，他担任了360系统的项目经理，以及360操作系统项目设计阶段的经理。凭借在上述项目的杰出贡献，他、Bob Evans和Erich Bloch在1985年荣获了美国国家技术奖（National Medal of Techology）。早期，Brooks曾担任IBM Stretch和Harvest计算机的体系结构师。
在查布尔希尔，Brooks博士创立了计算机科学系，并在1964至1984年期间担任主席。他曾任职于美国国家科技局和国防科学技术委员会。Brooks目前的教学和研究方向是计算机体系结构、分子模型绘图和虚拟环境。
Frederick P. Brooks，Jr.荣获了计算机领域最具声望的图灵奖（A.M.Turing Award）桂冠。美国计算机协会（ACM）称赞他“对计算机体系结构、操作系统和软件工程作出了里程碑式的贡献。”（landmark contributions to computer architecture, operating system, and software engineering.）
第一章 焦油坑
1.         编程产品包括：通用化，测试，文档，维护，等等。这些至少是程序工作量的三倍
2.         编程系统包括：接口，系统集成，等等。这些至少是程序工作量的三倍
3.         编程系统产品包括编程产品和编程系统，这些至少是程序工作量的九倍

第二章 人月神话
1.         造成项目滞后的原因主要有以下几点：
l         对估算技术缺乏研究，总是认为一切将运作良好；
l         假设人和月可以互换，人增加一倍，时间必将减少一倍，错误的将工作量和进度互相混淆；
l         对自己的估算缺乏信心，总是否认自己正确的估算，因为自己正确的估算往往时间较长；
l         对进度缺少跟踪和监督；
l         当进度滞后的时候，为了保证最后的交工时间，总是增加人力，而不是调整项目计划。
2.         编程人员由于很年轻，所以往往是乐观主义者，而且由于程序是思维上的东西，往往无法有实际进行验证，所以更容易造成编程人员站在自己的角度看问题，认为自己的看法是正确的，造成更加乐观的看法
3.         如果认为的每个部分需要和其他单独协作，则工作量按照n(n-2)/2递增，所以添加人手的时候需要尽量减少他需要合作的人或者部门
4.         软件开发沟通、交流的工作量非常大，它会很快消耗任务分解所省下来的时间，所以，添加更多的人手，实际上会延长开发时间，而不是缩短开发时间
5.         软件任务的进度安排：1/3计划，1/6编码，1/4构件测试和早期系统测试，1/4系统测试，所有的构件已完成
6.         二次成本远远高于其他开销，所以，在早期的进度策划中，允许充分的系统测试时间是非常重要的
7.         在基于可靠基础的估算之前，项目经理一定要确信自己的经验和直觉，这个比在老板压力下派生出的结果要好得多
8.         在项目进度落后的时候，基本有四种选择
l         假设该部分的估算出错，加派人手开发该部分
l         假设全部的估算都出错了，加派更多人手开发全部内容
l         重新制定项目计划“Take no small slips”，这种情况往往意味着进度的延后
l         消减任务
基本来说，1和2都是本书极力反对的，因为无论多么优秀的工程师，在进入项目之前都需要有已经在项目组的工程师进行培训，这样只可能造成：向进度落后的项目增加人手，只会导致进度更加落后

第三章 外科手术队伍
1.         优秀工程师的工作效率是一般工程师的10倍，程序效率是一般工程师的5倍，所以多发给优秀工程师工资是划算的，但一定不能让其偏离程序设计和开发
2.         项目开发总面临着两难的境地：一方面由于效率和沟通的原因，最好由少数优秀的工程师进行设计和开发；而对于大型系统，则需要大量的人手，以使产品在时间上满足要求
3.         10人开发队伍的组织结构
l         外科医生：系统结构师，需求人员，技术主要负责人，大部分程序编写者，不能少
l         副手：接口定义者，少部分程序编写者，充当外科医生的保险机制，减少外科医生的沟通量，不能少
l         程序职员：版本维护工作，可以少
l         工具维护人员：开发环境的维护，也可以制作一些小工具来加速项目的开发进度，可以少
l         测试人员：进行白盒测试的人，不能少
l         语言专家：专门解决大家程序问题的专家，可以少
l         管理员：非技术问题的主要解决者，可以少
l         编辑：所有文档的编写者，外科医生是不用写文档的，但是他必须要讲自己的想法讲给编辑听，讲给别人听，还要保证别人能听懂，这样写出来的文档才不至于成为烂文档，不能少
4.         整个系统必须具备概念上的完整性，需要有一个系统结构师从上至下的进行所有的设计
5.         在工作中，必须清晰地划分体系结构设计和实现的界限，系统结构师只需要专注于体系结构

第四章 贵族专制、民主政治和系统设计
1.         功能的强大和使用的复杂是软件开发中需要考虑的因素，两者的比值才是我们系统设计的最终标准，简单来说：造出来一个功能复杂，但同时很难使用的软件并不是一件好事，最好的方法是让用户根据自己对程序的理解来学习软件的用法，这就牵涉到概念的一致性
2.         概念的完整性要求设计必须由一个人，或者非常少数互有默契的人员来实现
3.         将设计和编码分开是获得概念完整性的好方法，但是在具体开发中很难将设计和编码完全分开，落实该方法也并不像想象中的那么容易
4.         系统的结构师，如同建筑的机构师一样，在工作的时候，需要考虑用户的利益，同时兼顾自己的成本
5.         系统的概念完整性决定了使用的容易程度，不能与系统基本概念进行整合的良好想法和特色，只能放到一边不予考虑，如果出现了很多非常重要但不兼容的构想，就应该考虑是不是抛弃原来的设计，对不同的基本概念进行合并
6.         如果大家进行一种民主的设计，许多创意就开始喷涌而出，在毫无限制的开发过程中，会出现大量的想法和争议，这样就造成了争执不下。我倒是比较赞成先由大家民主，然后由几个人决定的制度
7.         实现同样是一项高级别的创造性活动，并不会由于制定了外部技术说明而大为减少
8.         分三个阶段：体系结构，设计实现，物理实现。这三个阶段最好能重叠进行，在重叠的时候，两个阶段的人可以进行充分的交流
9.         在说明完成的时候，才雇用编程实现人员，这是一个方法
10.     用户所见的技术来自少数人的思想，并不意味着该开发模式下的系统需要更长的时间来创建

第五章 画蛇添足
1.         本书认为，可以通过设计人员和架构师的充分交流来限制
2.         架构师的方法只能是建议，但不代表设计人员必须听，而架构师在一个方法被否决之后，必须要时刻准备为所制定的架构提供另一种实现方法，最后由设计人员敲定
3.         二次开发的时候，很容易过分的设计第二个系统，导致很多不必要的功能被实现了
4.         第一个系统的某个设计思路，在第二个系统中被达到顶峰，但是这个设计思路本来就可以被当时的新技术所代替，所以没有必要再第二个系统中将陈旧技术尽善尽美，这种尽善尽美也可能造成功能所需要的空间和时间大大加大，可以通过某个准则来限制这种做法：每次改建，功能x不超过m字节内存和n微妙计算时间，也就是说，放慢效率的更改，我们一定要避免

第六章 贯彻执行
1.         文档是非常重要的工具，需要被不断的重复修改，版本工作也应该做好，文档的风格必须清晰、完整和准确
2.         事情可以多个人商量，但文档只能1到2个人编写
3.         文档可以用形式化和记叙性定义，一般以一位为主，另一个为辅
4.         形式化还有一种情况比较少见，是用原形的方法来做，但这种在体系结构容易规定过多的东西
5.         在整合的时候，尽量应用现在语言的模块化，改动的少一些
6.         每周都应该有例会，例会的成员是架构师、设计师、程序员和用户代表。首席架构师有决定权力，给一些急需解决的问题以结论，允许工作继续进行，开会之前需要把讨论的内容以文档的形式抄送给所有人
7.         开发的工程中，一定要保证文档的同步修改，不要因为有时候工作压力比较大，只改程序没有改文档，本人建议将文档和代码放在一起，一边修改了，只需拷贝到另外一边就可以了
8.         架构师在回答程序员电话的时候，需要在日志中记录问题和自己的回答，每天都将这些东西发给程序员，这种方式虽然不正式，但很有用
9.         本人认为可以由测试人员来写需求文档，或者说需求人员在需求结束后作为测试人员加入测试组

第七章 为什么巴比伦塔会失败？
1.         大型项目的交流主要通过三个方面：电话（包括其他非正式渠道），会议，文档
2.         文档由于过多，所以最好使用树状的索引结构
3.         其实很多人看文档的时候，都希望自己一下就看到修改的地方，我认为这个东西可以用Word的修订功能来实现，每次发布版本的时候，除了发布2.0之外，我认为还可以发布1.0到2.0的文档
4.         一方面，我们需要充分交流，这是为了避免错误；另一方面，我们需要减少交流，这是为了节省时间。避免交流的方法主要有：人力划分和限定职权范围
5.         在规模较小的项目中，产品负责人和技术主管可以是一个人，在规模较大的项目中，一般是分开，一个人很难兼顾两方面的工作
6.         在技术主管不参与任何管理工作的同时，建立技术主管决策上的权威是一个难题，主要有以下方法：
l         产品负责人必须预先声明技术主管的技术权威
l         在主要的技术问题出现前，产品负责人要和技术主管讨论好，决不能出现技术主管的技术意见被产品负责人推翻的情况
l         通过办公室的大小、地毯、装修、复印机等体现技术主管的权威
7.         产品负责人作为管理者更为常见一些

第八章 胸有成竹
1.         不能由开发人员一段时间的生产率来推算平均生产率，而得出项目能在较短时间按做完乐观开发
2.         编译器的复杂度是批处理程序的三倍，操作系统的复杂度是编译器的三倍
3.         OS/360的生产率是600-800指令/人年，代码量应该是1800-4000行/人年，高级语言的话，应该是9000-20000行/人年，也就是说，一个专门实现的程序员，每年的代码量应该不少于9000

第九章 削足适履
1.         对于性能的三个教训
l         和定制主流空间预算一样，应该制定总体规模的预算；和定制规模预算一样，应该制定后台存储访问的预算
l         在指明模块的空间预算的时候，确切定义模块的功能，防止开发者互相推诿
l         在每个人都局部优化自己的程序的时候，架构师必须保持警惕，确保连贯的系统完整性
2.         一方面，模块的最大尺寸是固定的，另一方面，模块过多必然会耗费空间和降低性能，所以，模块的规模和数量是一对矛盾
3.         空间和时间也是一对矛盾，所以需要在编程的时候注意这些方面，对于一些常用的队列、搜索、排序等公用库，至少应该有两个程序实现：运行速度快的和短小精炼的

第十章 提纲挈领
1.         对于计算机产品的文档，以下文档是较为重要的：
l         目标
l         技术说明
l         进度、时间表
l         预算
l         组织机构图
l         工作空间的分配
l         报价、预测、价格
2.         需要正式文档的原因：
l         决策需要书面记录，这样分歧才会明朗，矛盾才会突出
l         文档可以作为同其他人的沟通渠道
l         文档可以反映现在的进度

第十一章 未雨绸缪
1.         最初的想法、设计在后来的开发过程中，不修改是不可能的
2.         变更的时候，要把变更的影响都考虑到，以减少变更引起的错误，最重要的措施是使用高级语言和自动文档技术
3.         很多人不愿意写文档的原因也有一个是，一些文档就容易被别人批评，然后就要求狂改，不如等都弄好了造成既成事实
4.         当系统变化的时候，适当的对管理结构调整也是一种方法
5.         软件公司一般都是两条线，技术线和管理线，本书建议从技术线向管理线同级调动的时候，不能伴随着待遇的提升，想法从管理线往技术线调动应该伴随着待遇的提高，以此作为对传统意识的补偿
6.         外科手术队伍式的软件开发团队让大家觉得做高级人才编程和开发的时候，才能受到人的尊敬，这种方法有利于在公司内部形成技术的良好氛围
7.         程序维护的一个基本问题，缺陷修复总会以20-50%的机率引入新的bug，所以整个过程是前进两布，后退一步。原因一方面是局部错误往往隐含着系统错误，而改错的人只修改局部错误，一方面是由于维护人员常常不是代码的开发人员，而是一些初级程序员或者新手
8.         理论上，在每次修复之后，必须重新运行先前所有的测试用例，从而确保系统不会以更隐蔽的方式被破坏，实际情况中，回归测试要想接近上述状态的话，成本非常高
9.         经过统计，发现模块数随着版本号的增加呈线性增长，但是受到影响的模块数随着版本号的增加呈指数增长，所有的修改都倾向于改变系统的架构，破坏系统的完整性，增加系统的混乱程度，所以，崭新的，基于原有系统的重新设计是完全必要的
10.     系统软件开发是减少混乱度（减少熵）的过程，所以它本身是出于亚稳态的，软件维护是提高混乱度（增加熵）的过程，即使是最熟练的软件维护工作，也只是放缓了系统退化到非稳态的进程

第十二章 干将莫邪
1.         个性化的工具妨碍沟通
2.         建议每个小组配置一名工具维护人员，但不建议建立一个工具维护小组，这样效率反而会降低
3.         持续的精力能减少思考的时间，所以在分配测试环境的时候，最好有一个整段的时间供一个人只调试自己的东西，这样反而效率会更快一些
4.         在硬件是崭新的时候，需要一套运行稳定的仿真平台，这样才能保证当出现异常的时候，只可能是软件的问题，总之，把其他东西都搞定，然后再调试自己的程序
5.         程序的拷贝属于经理，他可以独立的授权程序的变更；发布的过程需要有一个正式流程，也就是说，开发是开发，发布是发布，集成是集成（用来测试）
6.         大项目的文档规模是不可避免的，只能选择性的阅读，这个也需要划分的时候注意
7.         高级语言能完成开发者想做的事情，目标代码经过新的编译器，就空间而言，会越来越小，就速度而言，经过优化编译器生成的代码，比很多程序员手写的要快，而且是在不行，还可以将其中的1-5%替换成手写的代码，这样就可以解决效率的问题

第十三章 整体部分
1.         自顶向下的设计从以下几个方面避免bug：
l         清晰的结构和表达方式更容易对需求和模块功能进行精确的描述
l         模块分割和模块独立性避免了系统级的bug
l         细节的隐藏使结构上的缺陷更容易识别
l         设计在每个精细化步骤地层次上是可以测试的，测试可以尽早开始，并且每个步骤的重点可以放在何时的级别上
2.         调试的时候，应该把程序划分为测试段，对执行终止位置进行计划，不要一次把所有的程序都放上去
3.         系统调试花费的时间会比预料的长，需要一种完备系统化和可计划的方法来降低它的难度
4.         系统集成调试要在每个部分都能正常运行之后开始，每个部分都需要自己进行伪装调试，即通过伪构件来实现
5.         在发布补丁的过程中，需要在日志中记录所有的修改，还需要在源代码中标记快速补丁和正式修改之间的区别（正式修改是指经过测试的修改）
6.         理想情况下，一次只修改一个构件
7.         紫色线束技术：每次修改都标记，在全部测试通过以后，再发正式版本，将紫色换成蓝色。在正式补丁发布前，一直发布快速补丁，在快速补丁测试通过后，修改程序设计文档，同时发布修改的程序和修改的文档

第十四章 祸起萧墙
1.         灾祸常常来自白蚁的肆虐，而不是龙卷风的侵袭，同样，项目进度常常是以一种难以产决，但是残酷无情的方式慢慢落后
2.         里程碑有明显的边界，并且没有歧义，绝对是百分之百的时间，如“结构师和实现人员签字认可的规格说明”，“100%源代码编制完成，纸带打孔完成并输入到磁盘库”，“测试通过了所有的测试用例”
3.         在大型项目的估计过程中，最好每两周对计划进行修订，这样即使坏也坏不到哪去，对于时间长短的过高或者过低估计，都会随着修订的进行
4.         对于项目来说，进取是非常重要的，它提供了缓冲和储备，使开发队伍能处理小的异常事件，可以预计和防止小的灾祸
5.         PERT图可以从事实中反驳“其他部分反正也会落后”的看法
6.         当项目经理了解到老板收到项目报告之后不会惊恐，也不会越俎代疱的时候，他才会提交真实的项目进度，而且老板最好不要在一次会议上同时进行了解进度和发布指令两件事情
7.         无论怎么样，都需要了解现在的真实进度，这个是防止满屋蟑螂的最好办法
8.         大型项目需要一个小组（1-3个人）来专门关注它的项目进度、计划修订和项目报告，这样的小组投入大的人力是非常重要的，否则项目可能会以每次一天的速度拖后一年

第十五章 另外一面
1.         一份好的文档需要：
l         目的。主要的功能是什么？开发程序的原因是什么？
l         环境。程序运行在什么样的机器、硬件配置和操作系统上？
l         范围。输入的有效范围是什么？允许显示的合法范围是什么？
l         实现功能和使用的算法。精确地阐述它做了什么。
l         输入－输出格式。必须是确切和完整的。
l         操作指令。包括控制台及输出内容中正常和异常结束的行为。
l         选项。用户的功能选项有哪些？如何在选项之间进行挑选？
l         运行时间。在指定的配置下，解决特定规模问题所需要的时间？
l         精度和校验。期望结果的精确程度？如何进行精度的检测？
2.         对于使用程序的人来说，需要体现正常功能的测试用例，体现边界的测试用例，体现边界之外的测试用例，这些对于使用程序的人来说，可以知道功能是什么，什么时能用的，什么是不能用的，不能用的会怎么样
3.         对于修改程序的人来说，需要更多，在上面的东西之外，还需要详细的流程图、结构图和数据流图，所用的算法，还有文档的说明
4.         流程图不要超过一页，而且不用逐一记录
5.         本书和我的观点一直，文档应该放在程序里面：）

附录
没有银弹－软件工程中的根本和次要问题
1.         软件任务前，需要做到：
l         仔细地进行市场调研，避免开发已上市的产品。
l         在获取和制订软件需求时，将快速原型开发作为迭代计划的一部分。
l         有机地更新软件，随着系统的运行、使用和测试，逐渐添加越来越多的功能。
l         不断挑选和培养杰出的概念设计人员。
2.         软件开发为什么不能大规模生产？
l         概念：软件是一个互相牵制关联的概念接口，无法像硬件一样用比特统一所有的概念；
l         复杂度：很少有两个软件很相似，软件拥有大量的状态，无法大规模生产；再次，由于软件是处理具体问题的，所以无法建立模型来处理，模型意味着对一部分因素的忽略，但软件不可以这样
l         一致性：对于物理或者化学研究者来说，他们研究的对象有一定规律，但对于软件开发者来说，软件是以人的行为和活动作为对象，根本没有什么通用的规律，而且在这种发展下，还往往需要符合别人的接口，就更麻烦了
l         可变性：由于思维是常常变化的，所以软件也常常变，而人们对于软件变化没有一个成本概念，所以变更的压力就放到软件开发者的身上了
l         不可见：软件是不可见和无法可视的，无法像建筑等有准确的设计图纸
3.         软件开发过程中的三次进步：
l         高级语言
l         分时
l         统一编程环境
4.         本书认为面向对象只能解决表达上的问题，但不能解决复杂度的问题，而复杂度才是根本问题
5.         专家系统的能力不是来自于自己的代码，而是以前非常丰富的知识积累，所以更加精确的反映了现实世界，这种技术把具体应用的复杂性和程序本身相分离
6.         软件多拷贝几份，某种意义上也算降低开发成本
7.         由于软件是模仿人活动的，所以增量开发更符合人活动的规律
8.         卓越和一般之间相差一个数量级
9.         软件机构更缺少的是好的设计人员，不是管理人员，对于好的设计人员，应该：
l         尽可能早地、有系统地识别顶级的设计人员。最好的通常不是那些最有经验的人员。
l         为设计人员指派一位职业导师，负责他们技术方面的成长，仔细地为他们规划职业生涯。
l         为每个方面制订和维护一份职业计划，包括与设计大师的、经过仔细挑选的学习过程、正式的高级教育和以及短期的课程——所有这些都穿插在设计和技术领导能力的培养安排中。
l         为成长中的设计人员提供相互交流和学习的机会。

再论《没有银弹》
1.         重用和交互的开发可以解决软件开发中的根本问题，但是现在的成果只是在某个层次上解决根本问题，而不是在全部层次上解决这个问题
2.         质量好一些的确能减少debug的事件，但不能过分追求，否则开发效率会降到令人可怕的地步
3.         一方面是拷贝被不停的卖出，另一方面，人们买过来的拷贝都不想用，因为人希望更少的操作完成很多的工作，而拷贝达不到这一点
4.         面向对象不会加快第一次或者第二次开发，只有在项目进行到第五次的时候，才显示真正的威力
5.         重用说起来容易，但做起来难，需要良好的设计和文档，而且就像学习语言一样，大量的库需要：
l         人们在上下文中学习，所以我们需要出版一些复合产品的例子，而不仅仅是零部件的库。
l         人们只会记忆背诵单词。语法和语义是在上下文中，通过使用逐渐地学习。
l         人们根据语义上的分类对词汇组合规则进行分组，而不是通过比较对象子集。

20年后的人月神话
1.         核心观点：概念完整性和结构师，概念的完整性很重要，即使粗糙一些，只要保证概念年的完整性，也是能取得成功的，如MS-DOS，而拥有一个架构师则是概念完整性的具体做法
2.         开发第二个系统所引起的后果：盲目的功能和频率猜测
3.         软件开发应该是增量的，可以回朔的，而不是瀑布的，尽管瀑布用的最多，而且也成为业界的标准
4.         并不是所有人都需要了解整个项目，模块，隐藏，定义接口是更好的
5.         最优月单位工作量是整体项目人月的立方根，就是需要的人数是整体项目的立方根，最优时间T=2.5（MM）^1/3，而且没有项目能在最优时间的3/4内完成，当计划时间大于T的时候，成本缓慢增加，当计划时间小于T的时候，成本急剧增加
6.         向进度落后的项目中添加人手总会增加项目的成本，但并不一定会使项目更加落后。人手越早添加越好，后添加者不得改进过程
7.         相同组织中开发人员的表现之间，和工作空间和生产率以及缺陷水平之间令人吃惊的关联
8.         将权力下放给小面更小的团体是一个好的方法，通过权力委派，中心的权威实际上是得到了加强；从整体而言，组织机构实际上更加融洽和繁荣
9.         软件工程就像化学工程一样，与如何扩展到工业级别处理过程的非线性问题有关。而且，和工业工程类似，它总是被人类行为的复杂性所困扰。

wishel

人月神话，人件，软件人的必读。