《人月神话》

author Shuxin Yang time 2020-06-01
《人月神话》

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

版本信息

  • 作者:[美] Frederick P. Brooks, Jr.
  • 出版社:清华大学出版社
  • 出版时间:2015年4月

第1章 焦油坑

【内容】

本章主要介绍编程系统产品的演进:

  1. 相关功能的编程产品的成本,至少是已调试的程序的成本的3倍;
  2. 相同功能的编程系统构件的成本至少是独立程序的3倍;
  3. 编程系统产品的成本高达9倍,然而,只有它才是真正有用的产品,是大多数系统开发的目标。

第2章 人月神话

【内容】

本章主要介绍编程系统的进度安排:

  1. 一个错误假设:一切都将运作良好,每一项任务仅花费它所“应该”花费的时间(乐观主义)。
  2. 沟通所增加的负担由两个部分组成:培训和相互的交流。人员并不是越多越好,人数越多所需要的沟通越多。
  3. 在早期进度策划时,允许充分的系统测试时间。
  4. 向进度落后的项目中增加人手,只会使进度更加落后。

【感想】

  1. 第2章的大部分内容和项目管理学到的类似;不过提到的进度安排的经验法则倒是打破我平时的认识:1/3计划;1/6编码;1/4构件测试和早期系统测试;1/4系统测试,所有的构件已完成。
  2. 我在平时的项目中给测试安排的时间是不充分的,反思下原因:一是时间紧,二是测试资源的缺乏,三对测试环节的重视不够。

第3章 外科手术队伍

【内容】

本章主要介绍团队及分工:

  • 10人程序开发队伍建议如下构成:首席程序员,副手,程序职员,工具维护人员,测试人员,语言专家,管理员,编辑和2个文秘。

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

【内容】

本章主要介绍概念完整性:

  1. 在系统设计中,概念完整性应该是最重要的考虑因素。
  2. 对于给定级别的功能,能用最简洁和直接的方式来指明事情的系统是最好的;系统的概念完整性决定了其使用的容易程度。
  3. 具体实现中创造和发明的机会,并不会因为指定了外部技术说明而大为减少,相反创造性活动会因为规范化而得到增强,整个产品也一样。

【感想】

  1. 编程系统对简洁和直接的追求让我想起“奥卡姆剃刀原理”–简单有效原理。这个原理在产品设计,系统设计都是适用的。
  2. 在系统多次迭代中,如何保证概念完整性,这是值得思考的。

第5章 画蛇添足

【内容】

  1. 结构师在开发第一个系统时,倾向于精炼和简洁;但对第二个系统却过分地设计,向系统添加很多修饰功能和想法。
  2. 如何避免开发第二个系统所引起的后果,从而避免画蛇添足?
    • 结构师可以有意识地关注这个系统的特殊危险,运用特别的自我约束准则,来避免那些功能上的过于修饰;根据系统基本理念及目的变更,舍弃一些功能。
    • 项目经理必须坚持至少拥有两个系统以上开发经验结构师的决定。

第6章 贯彻执行

【内容】

  • 本章介绍如何贯彻执行结构师的决策,如何保持系统的概念完整性。主要分为手册、形式化定义、直接整合、会议和大会、多重实现、电话日志、产品测试等七个方面。

【感想】

  • 概念完整性不仅在第一个系统设计环节很重要,在之后的每次系统迭代,以及具体执行环节也同样重要。这需要结构师和项目经理额外注意,从大局上对系统进行把握。

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

【内容】

  1. 巴比伦塔失败是由于缺乏两个方面,其一是交流;其二是交流的结果–组织。
  2. 大型编程项目中交流的途径:非正式途径,会议,工作手册。
  3. 团队组织的目的是减少所需的交流和合作的数量,因此良好的团队组织是解决上述交流问题的关键措施。减少交流的方法是人力划分和限定职责范围。
    • 产品负责人和技术主管是同一个人 -> 很难
    • 产品负责人作为总指挥,技术主管充当其左右手 -> 适合大型项目
    • 技术主管作为总指挥,产品负责人充当其左右手 -> 适合小型团队

【感想】

  • 产品负责人和技术主管的几种不同的组合方式对项目是有指导意义的。根据项目性质,找到合适的搭档/合作伙伴,通力配合,能够让项目开展得顺畅。

第8章 胸有成竹

【内容】

  • 编程工作量是程序规模的幂函数

第9章 削足适履

【内容】

本章介绍编程系统中的规模控制:

  1. 和制定驻留空间预算一样,应该制定总体规模的预算;和制定规模预算一样,应该制定后台存储访问的预算。
  2. 在指明模块有多大的同时,确切定义模块的功能。
  3. 培养开发人员从系统整体出发、面向用户的态度是软件编程管理人员最重要的职能。

第10章 提纲挈领

【内容】

本章介绍文档维护:

  1. 文档的跟踪维护是项目监督和预警的机制。文档本身可以作为检查列表、状态控制,也可以作为汇报的数据基础。
  2. 任何管理任务的关注焦点都是时间、地点、人员、项目内容和资金。
  3. 为什么要有正式的文档?
    • 书面记录决策是必要的。只有记录下来,分歧才会明朗,矛盾才会突出。
    • 文档能够作为同其他人的沟通渠道。
    • 项目经理的文档可以作为数据基础和检查列表。

【感想】

  • 我目前在所跟进的项目中,接触较多的是时间、人员和项目内容。几乎没有接触资金(预算)和规模控制。应该多锻炼自己对项目有更全面的了解,提升ownership意识,慢慢尝试推进更复杂的项目。

第11章 未雨绸缪

【内容】

本章介绍变化的应对。

  1. 变化是与生俱来的,不是不合时宜和令人生厌的异常情况。
  2. 软件维护包含对设计缺陷的修复。
  3. 程序维护中的一个基本问题是–缺陷修复总会以固定(20%~50%)的几率引入新的bug。所以,整个过程是前进两步,后退一步。

第12章 干将莫邪

【内容】

本章介绍软件项目中的工具:

  1. 首先是计算机设施。它需要硬件和使用安排策略;它需要操作系统,提供服务的方式必须明了;它需要语言,语言的使用方针必须明确;
  2. 然后是实用程序、调试辅助程序、测试用例生成工具和处理文档的字处理系统。

【感想】

  1. 接受项目中的变化,为变更设计系统,为变更计划相应的组织架构。
  2. 项目中尽量使用通用编程工具,而不是个性化的工具,因为后者会妨碍而非促进沟通。

第13章 整体部分

【内容】

  1. 剔除bug的设计:测试规格说明;自上而下的设计;结构化编程
  2. 构建单元调试:本机调试;内存转储;快照;交互式调试;测试用例
  3. 系统集成调试:使用经过调试的构件单元;搭建充分的测试平台;控制变更;一次添加一个构建;阶段(量子)化、定期变更

第14章 祸起萧墙

【内容】

  1. 通常灾祸来自白蚁的肆虐,而不是龙卷风的侵袭。同样,项目进度经常以一种难以察觉,但是残酷无情的方式慢慢落后。
  2. 里程碑:里程碑的选择只有一个原则,那就是里程碑必须是具体的、特定的、可度量的事件,能够进行清晰定义。
  3. 进取:棒球队长知道,进取是很多优秀队员和团队不可缺少的心理素质。它表现为“比要求的跑得更快”,“比要求的移动得更加迅速”,“更加努力尝试”。对软件开发队伍来说,进取同样是非常必要的。

【感想】

  1. 进度偏离会影响团队士气,因此作为项目经理需要管理好项目进度,合理估算其中的变更和损失。
  2. 在软件开发团队中,营造进取的氛围,进取提供了缓冲和储备,使开发队伍能够处理常规的灾祸。

第15章 另外一面

【内容】

  1. 对软件编程产品来说,程序向用户所呈现的和提供给机器识别的内容同样重要。
  2. 需要什么样的文档:实用程序、验证程序(即测试用例)、修改程序
  3. 流程图:一页纸的流程图是表达程序结构、阶段或步骤的一种非常基本的图示。

【感想】

  1. 好的开发人员不仅仅是开发高效的代码,还需要维护相应的文档,这样才构成完整的编程产品。
  2. 项目管理人员需要在文档上加以规划和引导。

第16章 没有银弹

【内容】

  1. 根本困难:不仅仅是在目力所及的范围内没有发现银弹,软件的特性本身也导致不大可能有任何的发明创新–能够像计算机硬件工业中的电子器件、晶体管、大规模集成一样–提高软件的生产率、可靠性和简洁程度。我们甚至不能期望每两年有两倍的增长。
  2. 银弹的希望:Ada和其他高级编程语言、面向对象编程、人工智能、专家系统、“自动”编程、图形化编程、程序验证、环境和工具、工作站

【感想】

  • 软件方面没有银弹–即不太可能有突破性进步;但总有一些方法能够优化我们当前的项目。能够将平凡的工作做到极致也是一件不平凡的事。

第17章 再论“没有银弹”

【内容】

  1. 向软件系统增加必要的复杂性:
    • 层次化,通过分层的模块或者对象;
    • 增量化,使系统可以持续地运行。
  2. OO:面向对象在整个开发周期中得到了应用,但是真正的获益只有在后续开发、扩展和维护活动中才能体现出来。
  3. 重用:重用是一件说起来容易,做起来难的事情。它同时需要良好的设计和卓越的文档。即使我们看到了非常罕见的优秀设计,但如果没有好的文档,我们也不会看到能重用的构件。
  4. 子弹的本质–形势没有发生变化。复杂性是我们这个行业的属性,而且复杂性是我们主要的限制。

【感想】

  • 本章是对10年前提出的“没有银弹”(第16章)后引起的剧烈争论进行的说明,并更新了在1986年提出的观点。可以发现,大多数基本观点是没有发生变化的,其中复杂性仍然是行业的属性。

第18章 《人月神话》的观点:是与非

【内容】

本章在多年之后,对之前章节所述内容以摘要的形式进行呈现,尤其是那些客观事实和经验中推广的法则。以下几点是之前没注意到但感触较深的:

  1. 人们通常期望项目在接近结束时,软件项目能收敛得快一些,然而,情况却是越接近完成,收敛得越慢。
  2. 人月是危险和带有欺骗性的神话,因为它暗示人员数量和时间是可以相互替换的。
  3. 两个人的团队,其中一个是领导者,常常是最佳的人员使用方法(留意一下上帝对婚姻的设计)。
  4. 一拥而上的开发方法是高成本、速度缓慢、低效的,开发出的产品无法进行概念上的集成。
  5. 对于非常大型的项目,将体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。(其同样适用于小型项目。)
  6. 即使是大型的设计团队,设计结果也必须由一个或两个人来完成,以确保这些决定是一致的。
  7. 战略上的突破常来自于对数据或表的重新表达。数据的表现形式是编程的根本。
  8. 项目经理的基本职责是使每个人都向着相同的方向前进。
  9. 项目经理的主要日常工作是沟通,而不是做出决定;文档使各项计划和决策在整个团队范围内得到交流。
  10. 只要管理人员和技术人才的天赋允许,老板必须对他们的能力培养给予极大的关注,使管理人员和技术人才具有互换性;特别是希望在技术和管理角色之间自由地分配人手的时候。
  11. 有时候必须回退,推翻顶层设计,重新开始。
  12. 如果里程碑定义得非常明确,以至于无法自欺欺人时,程序员很少会就里程碑的进展弄虚作假。

【感想】

  1. 作为一本书,单独开一章对之前观点进行回顾和分析是比较少见的,这也只有在历史相对“悠久”的书籍中才有可能出现;但反观人生,是否可以对关键性的观点或者决策做一下记录,以便之后反思总结呢?
  2. 管理不仅仅是一种职权,更是一种责任,一种艺术。如何让团队成员齐心协力,如何发挥每个人的才能,如何将项目完成得漂亮,这些都需要思考和实践。

第19章 20年后的《人月神话》

【内容】

  1. 《人月神话》是关于人与团队的书,所以它的淘汰过程会是缓慢的。
  2. 结构师:委派一名产品结构师是最重要的行动。结构师负责产品所有方面的概念完整性,这些是用户能实际感受到的。
  3. 概念完整性是产品质量的核心。
  4. 定义用户群:用户群越大和越不确定,就越有必要明确地定义用户群,以获得概念完整性;为用户群的属性明确地记载各种猜测。清晰和错误都比模糊不清好得多。
  5. 瀑布模型的基本谬误是它假设项目只经历一次过程,而且体系结构出色并易于使用,设计是合理可靠的,随着测试的进行,编码实现是可以修改和调整的。换句话说,瀑布模型假设所有错误发生在编码实现阶段,因此他们的修复可以很顺畅地穿插在单元和系统测试中。
  6. 信息隐藏–现在常常内建于面向对象的编程中–是唯一提高软件设计水平的途径。
  7. “向进度落后的项目中添加人手总会增加项目的成本,但并不一定总会使项目更加落后。”特别地,由于新成员总会立刻带来需要数周来弥补的负面效应,所以在项目早期添加额外的人力比在后期添加更加安全一些。
  8. 《人月神话》的大部分文章在讲述软件工程管理方面的事情,较少涉及技术问题。因为对于项目的成功而言,项目人员的素质、人员的组织和管理是比使用的工具或采用的技术方法更重要的因素。
  9. 传统产业倾向于被大型公司以已指定的管理风格和企业文化所支配。始于数百家创业公司的成品软件产业,行事自由,更加关注结果,而不是流程。
  10. 软件系统可能是人类创造中最错综复杂的事物。这个复杂的行业需要:进行持续的发展;学习使用更大的要素来开发;新工具的最佳使用;经论证的工程管理方法的最佳应用;良好的自我判断以及能够使我们认识到自己的不足–上帝赐予的谦卑。

【感想】

  1. 好的软件开发不仅仅是开发本身,而且涉及用户理解、产品设计、工程架构、团队管理等一系列“艺术”。
  2. 除了软件工程,其他需要人合作的项目,最主要的都不是技术,而是团队中的人。
  3. 如何组建团队,沟通协调,调动积极性,这些都是软件工程管理者需要掌握的。

附录一:名家谈人月

【内容】

  1. 有些书对于读者和作者像是年金,它们年复一年地分红。《人月神话》就是这么一本书。
  2. 软件行业实际上是“精英行业”。高素质、具有丰富经验的需求分析人员、结构师往往是软件企业的核心骨干人员,相应的一般编程人员流动性会大一些。
  3. 在实际经验中,Brooks体会到开发大型软件过程中,难以汇集参与人员的设计理念,然后提供给使用者一致的设计概念,因而导致软件的高度复杂性,最终使得大型软件系统往往会进度落后、成本暴涨及错误百出,就是所谓的软件危机。

【感想】

  • 读懂一本书需要相关经验,写一本书更需要相关经验。书籍结合实际能够让日常的工作做得更好。

附录二:名著评人月

【内容】

  1. 数据结构设计是程序构造过程的中心环节。一旦数据结构安排好了,算法就会瓜熟蒂落,编码也比较容易。
  2. 有两种复杂性,即偶发的和本质的。前者由开发人员和方法引起,后者是解决问题所固有的。
  3. 搭建一个软件系统最困难的部分是决定究竟要做什么。正如爱因斯坦所说的,问题本身常常比解决它的方法更重要。
  4. Brooks把架构师的角色定义为两部分:
    • 首先,代表顾客的利益
    • 为了做到这一点,需要从头到尾了解整个产品。
  5. 架构告诉我们发生什么,实现告诉我们如何使它发生。

【感想】

  • 对架构了解地更多了一些:架构不仅仅是熟稔技术框架,工程结构;还需要从用户、产品角度进行思考。在怎么做之前最重要的是知道做什么。

附录三:读者感言

【内容】

  1. 要让一个项目顺利进行,首先要有良好的时程规划,考虑所有的因素;其次,程序人员要有勇气,不要妥协,一定要坚持自己预估的时程。
  2. 软件工程是为开发软件服务的,标准不是目的,只是手段。《人月神话》没有讲标准,但它为怎样做好一个项目提供了一些启发。
  3. 无论是产品/开发人员的区分,还是外科手术式队伍的引入,核心原则都是:职能细分,并将高要求的工作集中在少数人手中。提高软件项目的质量的最好办法之一,就是找到合适的人。

【感想】

  • 本章是几位读者结合自身工作情况,谈了谈对《人月神话》的感想。总体上,这本书能够一次又一次地引起巨大轰动,是因为它贴近软件工程的实际情况。这本书能让相关从业者感觉是对自己工作的一次真实描绘,对其中痛点难点的直接展现。