<人月神话>书摘

人月神话 《The Mythical Man-Month》

描述都应该简短精炼。

第一章： 焦油坑

史前史中，没有别的场景比巨兽在焦油坑垂死挣扎的场面更令人震撼了。过去几十年的大型系统开发就犹如一个焦油坑。

第二章：人月神话

缺乏合理的时间进度是造成项目滞后的最主要原因，比其他所有因素加起来的影响还要大（如同烹饪）。因为乐观主义，人月的度量方式（软件开发是复杂关系的实践，有大量沟通交流，添加人手时间却延长），早期测试（没有足够时间），空泛的估算（经理缺乏勇气坚持进度安排），进度再安排（重新进度安排保证充分时间；削减任务）

进度安排：1/3计划，1/6编码，1/4构建测试，1/4系统测试。

Brooks法则：向进度落后的项目中增加人手，只会使进度更落后。

第三章：外科手术队伍

小型精干队伍（2人）是最好的：

效率高和效率低的实施者之间具体差别非常大，经常达到了数量级的水平。头等人才的小队伍（10人以下）比大型几百人团队更有效。简而言之，20万年薪是10万年薪生产率10倍。因为沟通影响开发成本，人越多沟通效果越不好。而且经验和实际表现没有相互联系。

Mils对大项目开发的建议-外科手术团队：大项目的每一个部分由一个团队解决，但是该队伍以类似外科手术的方式组建，而非一拥而上。外科医生，即首席程序员，定义功能和性能技术说明书，设计程序等，他需要极高天分，十年经验和应用数学业务数据处理或其他系统和应用知识；副手：后备；管理员及其秘书：管理法律合同财务等；编辑及其秘书：产生文档；程序职员：专注产品；工具维护人员：检查和维护开发工具；测试人员：大量测试用例；语言专家；

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

系统设计中，概念完整性是最重要的因素。就是为了反映一系列连贯的设计思路，宁可牺牲一些不规则的特性和改进，不提倡独立和无法整合的系统。

目标是易用性，功能与理解上复杂程度（简单且直白）的比值才是系统设计的最终测试标准。单是功能本身或易于使用都无法成为一个好设计评判标准。

对于大型项目，将设计方法，体系结构（各类用户接口说明：编程手册，功能手册等）和具体实现相分离是获得概念完整性的强有力方法。体系架构是做什么解决用户问题，决定易用性；开发实现是如何做但更有创造性，决定成本和性能。外部的体系结构是增强而不是限制实现小组的创造性。

虽然不是架构师才有好创意，但是系统概念完整性决定了易用性。所以，只有能与架构兼容的好想法才实现，否则放弃。为了系统概念上的完整性，必须是一种无需任何歉意的贵族专制统治。

在等待时，开发实现人员做什么？在编写操作系统外部规格说明书，程序实现经理150人比架构经理10人时间不会缩短而且质量更低劣，就因为怕架构组工作缓慢程序实现干等，结果确实这样损失几百万美元。因为创造性活动因为规范性而得到增强（在良好架构下）。那么开发人员和架构师并行做的有很多：定义时间和空间目标，了解平台配置，设计模块的边界，表结构，算法和工具，和架构师沟通等。

工作的垂直划分（不是水平划分）简化劳动量而提高概念完整性：划分为三个阶段，体系结构（architecture），设计实现（implementation）,物理实现（realization）,可以并发进行。

第五章：画蛇添足

构造师和建筑人员之间彻底和谐交流。实际情况，尽早交流和持续沟通使架构师有较好成本意识，使开发人员获得对设计的信心，并且不混淆各自责任。架构师必须：只有建议没有支配权；建议实现方法和接收其他方法；建议要平静低调；准备放弃改进建议（相信开发人员）；

第二个系统是最危险的（倾向过度设计和修饰，画蛇添足），因为第一个谨慎，第三四个有规律。所以，要学会自我约束，舍弃一些功能；架构师有超过2个系统开发的丰富经验；不断提出正确问题使确保原则；

好的准则：每个功能都分配物理值，功能X不超过m字节的内存和n微秒速度。以此为决策。

第六章：贯彻执行

杜鲁门的关于总统权力：他只是坐在那里，嘴里是‘做这个！做那个‘当然，什么都不会发生，光说不做是没有用的。

文段化，不断的阶段化修改。规格书只描述所有用户看得见的，避免描述看不见的，编程设计人员的创造不应该被限制。

一个古老的格言警告说：“绝不要携带两个时钟出海，带一个或三个。”同样的原则也适合于形式化(专业化标记)和记叙性(一般写作)定义，一定以一种方式为标准，另一个汇种为辅助描述。

周例会可以在会上提出任何问题和修改意见，但是仅以书面方式，在会议之前分发。重点是创新，而不是结论。会议是达成共识，做出结论。

对于有疑问的开发人员，应鼓励他们打电话询问相应的架构师，而不是自己猜测。架构师保存电话日志，定期发给用户和开发人员。

项目经理最好的朋友就是面对的敌人—独立的产品测试机构。

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

巴比伦塔的失败因为交流和组织，开始争辩沮丧和猜忌最后分裂和孤立。交流和组织技能需要管理者仔细考虑，相关经验的积累和能力的提高同软件技术本身一样重要。

交流途径：非正式途径（电话沟通）；会议（技术陈述）；工作手册（实时更新）。

第八章：胸有成竹

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

经验发现：进度一般落后大约1/2，花费估计是2倍。

第九章：削足适履

规模控制即是技术工作一部分，也是管理工作一部分。花费在内存上的金钱是值得的，比任何其他配置投资要好，规模不是坏事但不必要规模是不可取的。一定做规模上（内存，访问次数）的预算。

项目经理做两件事取得空间—时间折衷：1团队在编程技能上得到培训；2公共库开发，很多公共单元构件。管理层培养开发员从系统整体出发，面向用户的态度，而不仅仅做局部优化。

程序改进是战略的突破而不是技巧提高，可能是算法，但更多是数据或表的重新表达。数据表现形式是程序核心。表数据比程序流图更重要。

第十章：提纲挈领

软件项目关键的文档：目标，用户手册，内部文档，进度，预算，组织结构图，工作空间分配。应该从项目早期规范化文档。

第十一章：未雨绸缪

富兰克林.罗斯福：普遍的做法，选择一种方法，试试看；如果失败了，没关系，再试试别的。不管怎么样，重要的先去尝试。

即使最优秀的项目经理，也不能无所不知地在最开始解决各种问题。所以，做规划的时候就计划丢弃原型，再做个更好的系统。那么会意识到变化与生俱来，而不是不合时宜和令人生厌的。随着学习的过程更改设计。

设计人员越少，接口越少，产生错误越少，软件维护性越好。

修改的模块数量是线性增长，但受影响的模块是指数级别增长。当系统越来越无序时候，就应该重新设计系统。软件开发是减少混乱度，软件维护提高混乱度（缺陷修复总以20-50%几率引入新bug）。

高级管理人员也要从事高级的编程工作，甚至亲自参与开发工作。

第十二章：干将莫邪

巧匠因为他的工具而出名。

项目的关键是沟通，工具与个人偏好有关。但是项目经理制定策略为通用工具分发资源，对专业工具不能吝啬人力和物力。有：目标机器（客户机器）；辅助机器和数据服务；编译器和汇编平台；程序库和管理；编程工具；文档系统；

同天文工作者一样，系统调试总是大部分在夜间完成。

第十三章：整体部分

莎士比亚：谁都可以召唤遥远的精灵。问题是你真的召唤的时候，它们来吗？

提出bug的设计（有时必须推翻设计重来）：防范bug的定义（开发者做出的假设不匹配，产品未精确定义，细致功能定义，详细规格说明，规范性的功能买描述说明）；测试规格说明（测试人员）；自顶而下（不断精化）；结构化编程（一入口一出口，无goto）；

系统集成测试要尽早。一次加添加一个构件。开发辅助调试平台和测试代码是值得的，代码量甚至可能是测试对象的一半。

变更阶段要么很大，间隔很宽；要么小而频繁。后者很不稳定。

第十四章：祸起萧墙

灾祸来自白蚁的肆虐，而不是龙卷风的侵袭。同样项目进度以难以觉察但残酷无情的方式慢慢落后了。项目防止以一次一天的方式落后一年。

里程碑必须是具体的，特定的，可度量的事件，能够进行清晰定义。某项活动从着手估计，每两周一修订（不断修正）。好的里程碑是一项服务，而不是负担，不准确的里程碑会摧毁士气。

进取是一种心理素质。人们比较乐观地放缓工作节奏，所以必须关心每一天的滞后。对那些关键路径的滞后特别关注（广义的PERT技术）。

进度的偏差：减少角色的冲突（老板不能对项目经理越俎代庖，只关注信息）和猛地拉开地毯（每月的评审机制，有专门的控制小组）；

第十五章：另外一面

歌德：不了解，就无法真正拥有。

销售经理带着新销售员示范销售。同理，做讲座的时候，不要讲优秀文档的特点，直接演示写文档。

文档-使用程序（3-4页）：1目的：主要的功能和开发原因；2环境：运行机器硬件和操作系统；3范围：输入的有效范围；4功能和算法；5输入-输出格式；6操作指令：控制台及输出内容中正常和异常结束的行为；7选项：功能选项；8运行时间：解决问题时间；9进度和校验：精确度。

文档-验证程序（使用方法和测试用例）：用例的数据范围划为3种：1大多数正常数据；2边界值；3非法数据。

文档-修改程序：非常细节的描述，关于流程，修改的讨论，文件规划，算法。

流程图被吹捧过度，很多程序不需要流程图，需要的话绘制在一张纸上体现整体性（不要详细，可不遵标准）。

数据处理的基本原理：试图把信息放在不同的文件中，并努力维持它们之间的同步，是费力不讨好的事情。

降低文档的负担：1多向读者传达意思：用标签，声明，符号等工具；2使用一致格式提高程序可读性；3以段落注释的形式.

没有银弹（购买和自行开发；快速原型和增量开发；优秀人才）：

没有任何技术或管理上的进展，能够独立地许诺十年内使生产率，可靠性或简洁性获得数量上的进步。

概念设计的建议：1市场调研，避免开发市场上已有的产品；2快速原型开发；3逐渐增加功能；4不断挑选和培养概念设计人员。

怀疑论者不是悲观主义者。虽然没有银弹，但是一直的革新会使将来数量级提高。路在脚下。

畸形是：不是由于软件发展太慢，而是因为计算机硬件发展得太快了。

软件最困难的是规格化，设计和测试这些概念上的结构（数据集合及关系，算法，功能调用），而不是对概念进行表达和对现实逼真程度进行验证。有复杂性（软件太复杂），一致性（接口和兼容性），可变性（需求变更等）和不可见性（抽象）。

杰出的设计人员和卓越的管理人员一样重要，各种待遇应该一样。培养杰出的设计人员：1尽早识别，通常不是最有经验的；2指派职业导师负责成长和规范职业；3职业发展计划和各种课程；4提供交流和学习的机会。（使产品更快更小更简单更好）

再论《没有银弹》

所以任何推销“使用这种方法，工具或产品，它使软件生产率提高十倍”都不会满意。

环境和次要因素无论多么积极，仍无法提高生产率，但是当它们产生负面影响时，会使生产率降低。

质量带来生产率。

20年后的人月神话

只能根据过去判断将来，然而永远无法根据过去规划将来。

核心观点（适合所有复杂事物）：概念完整性（条理分明的概念模型使之易用：应用及其方法，用户界面使用策略等）；有很多由一个或者两个人设计的优秀软件产品例子；委派一名产品架构师是最重要的行动（负责概念完整性，就像导演）；架构，设计实现，物理实现相分离；体系结构的递归（体系太大的话，分为子系统递归做）；

设计二次系统：盲目的功能：牺牲性能甚至可用性的代价，过头添加功能；定义用户群：他们是谁，他们需要什么，他们认为自己需要什么，他们想要的是什么；为用户群的属性明确地记载各种猜测。清晰和错误都比模糊不清好的多。

放弃权利的力量：《小就是美，人们关心的经济学》（Smallis beautiful: Economics as if people mattered），提出最大化员工创造力和工作乐趣。(如果较低级组织的自由和责任得以保留，中心权威实际上得到了加强，整体会更加繁荣)

人就是一切。项目的成功，项目人员的素质，人员的组织管理是比使用工具或采用的技术方法更重要的因素。一定要对人的关注，激励，培养上研究。项目转移十有八九会失败，因为破坏了团队的整体性。最后，创造力来自于个人，而不是组织架构或开发过程。

项目估算（Boehm）的模型（《软件工程经济学》）：时间T=2.5*[（MM即人月）的立方根]，计划进度一定要和最优进度匹配。向进度落后的项目添加人手会增加成本而且可能会更加落后（《软件项目动力学：一条完整的路》），不要对落后项目盲目和本能的修补。

信息隐藏和封装：代码模块定义良好的接口，内部是程序员的私有财产，外部不可见，这种效率最高！而不是让所有程序员了解所有的材料。

软件开发必须存在逆向移动，在代码实现之前，往复迭代两个或更多的体系结构-设计-实现循环。即增量模型更好：很早开始测试，按预算开发策略，鼓舞士气。将软件作为一系列相关产品族来设计。