it

    1.外科手术队伍The Surgical Team

    项目经理在项目的初期必须清楚的估计项目的人月运作模式（时间、人力在项目各阶段的分配），例如什么时候需要出什么样成果，决定了什么时候需要什么样的人加入项目，这是项目经理的责任。

    2.贵族专制，民主政治Aristocracy,Democracy,System

    要获得概念的完整性，设计必须由一个人或具有共识的小组来完成。

    有四个问题：

    1。如何得到概念的完整性

    2。是否要有一位杰出的精英，或者说是结构设计师的贵族专制.....

    3.如何避免结构设计师产出无法实现或代价高昂的技术规格说明，使大家陷入困境。

    4。如何才能与实现人员就技术说明的琐碎细节充分沟通，以确保设计被正确地理解，并精确地整合到产品中。

    对1。2。4的回答基本上都可以找到，但第3个似乎找不到。

    3.画蛇添足The Second-System Effect

    讲述的基本都是基于IBM 360操作系统以及编译程序等方面的经验，讲述如何避免开发第二个系统的风险，作者认为开发第二个系统的设计师设计出来的系统是最危险的,因此要求他们自律。

    4.贯彻执行Passing the word

    印象比较深刻的是"体系结构设计人员必须为自己描述的任何特性准备一种实现方法，但他不应该支配具体的实现过程。"

    5.为什么巴比伦塔会失败Why did the Tower of Babel Fail?

    讲述巴比伦塔会失败的原因是缺乏交流。

    6.胸有成竹Calling the Shot

    主要讲述如何计算编程时间，以及提出几个人的经验算法。

    讲述的各种算法可能都不太适合与现在的高级语言，但Portman的观点仍然适合现在，即编程人员实际的编程时间只有50%，其他的时间都花在了无关的琐碎事情上。

    7.削足适履Ten Pounds in a Five-Pound Sack

    主要讲述程序占用的空间等，在70年代比较突出，但现在好多了。

    8.提纲擎领The Documentary Hypothesis

    说明文档的作用

    9.未雨绸缪Plan to Throw One Away

    唯一不变的是变化本身。

    在大型项目中，项目经理需要有两个和三个顶级程序员作为技术轻骑兵，当工作繁忙最密集的时候，他们能急驰飞奔，解决各种问题。 讲述技术人员与项目人员的互换是，对我有一定的提示，但图中IBM的两条职位晋升线，不太理解。

10.干将莫邪Sharp Tools

    主要讲述项目中管理好各种工具的重要性，项目经理首先要制定一种策略，让各种工具成为公用的工具，这样才能使开发、维护和使用这种工具的开发人员的效率更高，这种工具可能是开发人员开发出来的，也可能是使用现有的，可能是通用的，也可能是专用的或个人偏好的。比如：文档编写工具、开发工具（包括各种不同开发平台）、调试工具、测试工具、数据库工具、版本管理、项目管理工具等。

    11.整体部分The Whole and the Parts

    一读这一章，就让我感触颇深，特别是这句话"BELL实验室监控系统项目的V.A.Vyssotsky提出,'关键的工作是产品定义。许许多多的失败完全源于那些产品未精确定义的地方',细致的功能定义，详细的规格说明，规范话的功能描述说明以及这些方法的实施，大大减少了系统中必须查找的BUG数量"。虽然这句话的意思只是说明精确定义产品将减少BUG的数量，但我看到了系统分析的最重要的工作——产品定义。现在，许多 开发人员嘴里口口声声说也做过需求调研、系统分析、系统设计，但大多数没有涉及到产品定义的深度，严格意义上不能叫做系统分析。这句话对我的以后想从事系统分析工作有很大的帮助。

    这一章余下的内容，也值得一看，虽然有些地方有些过时，但剔除BUG的设计以及部分测试/调试方法仍值得一看。

    12.祸起萧墙Hatching a Catastrophe

    这章节说明使项目进度拖后的最大原因不是重要的事件，如新技术、重组等，而是一些琐碎的小事，每件小事只耽误半天或一天时间，但这种小事多以后，将使项目的进度严重拖后。

    项目对于公司就如程序对测试工程师一样，如果不了解它，它就是一个黑盒子，如果不打开这个黑盒子，你可能永远不知道盒子里面有什么。

这部分描写项目经理以及小组主管的一些心理，值得一看。

    13.另外一面The other face

    本章说明程序的另一面——文档。

    不了解，就无法真正拥有——歌德，作者引用的歌德的话来描述文档对客户的重要性，提出客户需要什么样的文档以及文档的格式和包含的内容，指出当时存在的大多数文档只描述了树木，形容了树叶，但没有整个森林的图案。

    想想，这种情况在现在仍然没有改变。于是作者提出了两个观点：

    1.流程图：流程图是被吹捧得最过分的一种程序文档。许多程序甚至不需要流程图，很少程序需要一页以上的流程图

    2.自文档化（self-documenting）的程序：提出文档与程序合为一体，能很好的解决文档与程序分开造成的文档过时的问题，并说明了在程序中加入文档的一些方法和技巧。2002年，我看到一位网友关于文档与程序合一的文章，当时就觉得是个好方法，没想到70年代，老美已经提出来了。

    14.没有银弹-软件工程中的根本和次要问题(No Silver Bullet-Essence and Accident in software Engineering)

    这是一篇论文，发表于1986年,我自认为我的理论水平没有上升到可以对他的论点和论据做出怀疑或质疑的结论，我只是说说我的感想。

    人狼是传说中的妖怪，只有银弹才能杀死他。作者认为软件项目具有人狼的特性，因为软件项目也可能变成一个怪物，一个落后进度、超出预算、存在大量缺陷的怪物。

    作者通过软件系统的内在特性复杂性、一致性、可变性和不可见性来分析说明了软件天生就没有银弹。
作者试图通过分析软件问题的本质和很多侯选银弹的特征来探究其中的原因。他行动的第一步是将大块的“巨无霸理论”替换成“微生物理论”。这个变化的过程告诉你，进步是逐步取得的，伴随着辛勤的劳动，对规范化过程应

    进行持续不懈的努力，而这个努力的过程相应的就诞生了软件工程。作者对软件工程诞生的原因做出这样的解释，我觉得符合外国思维的特点，这正是国人所缺乏。记得有一位朋友说过，中国妈妈与德国妈妈的区别，他说，如果手里拿的针掉到地上了，中国妈妈的第一反应是估计针掉下去的范围，然后在这个范围里面找，可能很快就找到了，也可能一直都找不到；但德国妈妈不同，她会拿一根粉笔来，把整个屋子画成一个大圈，接着把大圈分成许许多多的小圈，然后再到每个小圈里找，虽然比较慢，但最终肯定可以找到。仔细想象，大多数情况下，中国妈妈都会找到得比较快，这确实符合大多数中国妈妈的思维习惯，每个中国妈妈都这样找，这好象是与生俱来的本事，但为什么德国妈妈没有这个本事呢？是德国妈妈笨吗？为什么中国妈妈也有找不到的情况？而德国妈妈，虽然速度慢了点，却始终能够找得到？如果把这件故事推而广之，多年以后，德国妈妈创建了找针工程，她通过多次找针的实验数据，分析出针掉到整个房间中各个小圈的概率，总结出针在哪个小圈的概率最大，很快就可以找到针，找针速度早已高过中国妈妈，而中国妈妈还在依循与生俱来的本事。你能说德国妈妈笨吗？为什么中国妈妈和德国妈妈会有这么大的区别？是德国妈妈把大块的“巨无霸理论”替换成“微生物理论”吗？我觉得是是，你说呢？作者在后面的论述中用数学和物理的发展为例子也说明了，这种思想的成立。

    余下的作者把软件工程按“巨无霸理论”替换成“微生物理论”的过程详细的说明，值得看，我关注的不是具体的内容，具体内容可能有些不合适宜，我关注的是作者的思考方式以及处理方法，这是非常重要的。

    在“以往解决次要困难的一些突破”和“银弹的希望”章节，从概念上讲述了软件的发展，其中讲到“专家系统”时，使我想起一部科幻电影，忘了电影名字了，有个情节大致是这样的，一位非常有经验的主管死后，有一名较优 秀的下属接任，但这时出现了一位非常厉害的敌人，这位新主管无论如何也战胜不了敌人，这时想起了以前的主管，心想前主管一定有办法对付这个敌人，而前主管的大脑就存放在系统里，于是新主管调出前主管的大脑，把敌人的各种特征都描述给'他'听，就好象前主管仍然活着一样，他与前主管的大脑通话后，前主管的大脑告诉了他对付敌人的方法，后来通过这个方法真的把敌人打败了。这是否专家系统的最佳境界呢？

    还有讲到“自动”编程章节时，使我想起我以前也有过类似的想法，但没想到这些想法竟然早就有人提出过。还有记得“图形化编程”好象也风行过一段日子。

     15.再论《没有银弹》No Silver Bullet Refired

    看完再论《没有银弹》后，虽然作者说有不少人对他的观点持反对或不同意见，但我始终觉得他的观点是对的——根本和次要问题的划分以及定义。作者认为软件开发困难的部分是概念的结构，如规格化、设计和测试等概念的结构，而不是概念的表述和实现概念，虽然实现概念可能占用了小于90%的时间，就如现今的软件开发一样，系统分析通常占用的整个项目开发时间不超过20%，而80%的时间花在编程上一样。