The Mythical Man-Month 人月神话笔记

The Mythical Man-Month 人月神话byFrederickp.Brooks,JR IBM360系统之父

焦油坑The Tar Pit
 Een schip op het strand is een baken in zee.[Dutch Proverb]
[A ship on the beach is a lighthouse to the sea]
岸上的船儿，如同海上的灯塔，无法移动

 

                             

职业的乐趣	职业的苦恼
创建事物的纯粹快乐  开发对其他人有用的东西的乐趣  将可以活动、相互啮合的零部件组装成类似迷宫的东西，这个过程所体现出令人神魂颠倒的魅力  面对不重复的任务，不间断学习的乐趣  工作在如此易于驾驭的介质上的乐趣——纯粹的思维活动，其存在、移动和运转方式完全不同于实际物体	将做事方式调整到追求完美，是学习编程的最困难部分  由其他人来设定目标，并且必须依靠自己无法控制的事物（特别是程序）；权威不等同于责任 （我的拙见：一言道尽编程里最困扰人的事情） 实际情况看起来要比这一点好一些：真正的权威来自于每次任务的完成 ，任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外  人们通常期望项目在接近结束时，（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢  产品在即将完成时总面临着陈旧过时的威胁

 

 人月神话The Mythical Man-Month

Good cooking takes time.If you are made to wait ,it is to serve you better ,and to please you.byMenu of Restaurant Antoine ,New Orleans

美酒的酿造需要念头，美食的烹饪需要时间，片刻等待，更多美味，更多享受。

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

由于编程人员通过纯粹的思维活动来开发，所以我们期待在实现过程中不会碰到困难。  但是，我们的构思是有缺陷的，因此总会有bug。 

我们围绕成本核算的估计技术，混淆了工作量和项目进展。人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。 （这是这本书的一个核心观点）

在若干人员中分解任务会引发额外的沟通工作量——培训和相互沟通。 

关于进度安排，我的经验是为1/3计划、1/6编码、1/4构件测试以及1/4系统测试。 

作为一个学科，我们缺乏数据估计。 

因为我们对自己的估计技术不确定，所以在管理和客户的压力下，我们常常缺乏坚持的勇气。 

Brook法则：向进度落后的项目中增加人手，只会使进度更加落后。 （这是这本书的一个核心观点）

 

 外科手术队伍The Surgical Team

This studies revealed large individual differences between high and how and low performers,often by an order of magnitude.bySackman.Erikson ,and Grant

同样有两年经验而且在受到同样的培训的情况下，优秀的专业程序员的工作效率是 较差程序员的十倍。（Sackman、Erikson 和 Grand）

Sackman、Erikson 和 Grand 的数据显示经验和实际表现之间没有相互联系。我怀疑这种现象是否普遍成立。

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

两个人的团队，其中一个项目经理，常常是最佳的人员使用方法。[ 留意一下上帝 对婚姻的设计。]

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

实际上，绝大多数大型编程系统的经验显示出，一拥而上的开发方法是高成本、速 度缓慢、不充分的，开发出的产品无法进行概念上的集成。

一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法——既能获得由 少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底地减少了沟通的 工作量。

补：需要协作沟通的人员的数量影响着开发成本，因为成本的主要组成部分式相互的沟通与交流以及更正沟通不当所引起的不良结果（系统调试）。

 

 

附：AFIPS(美国信息处理学会联合会)