《人月神话》读书笔记

  第一次听说《人月神话》这本书是在本科的软件工程课程上。当时老师向我们推荐过多本相关领域的经典著作，现在能回想起的也就是四人帮的《设计模式》以及这本《人月神话》。当然，之前一本也没读过。

  这次终于硬着头皮读完了《人月神话》（当然是为了完成作业）。现在谈一谈我对该书的整体感受。首先，作者站在一个项目经理的角度，讨论了软件开发过程中的方方面面，涉猎甚广。其次，书籍正文中有十几个章节，讨论了技术、工程、团队和管理等等方面的问题，我认为这些话题是可以统一起来的，也就是“没有银弹”中所提出的软件开发的根本困难和次要困难。所有的问题、观点和解决方案无非就是揭露软件开发过程中存在的问题以及阐述其本质，最终给出看似可行的解决方案。最后，我对本书的感受是多少有些晦涩难懂。这可能由于以下两个原因。一方面自己还是一个学生，并未在公司参与过实际项目的开发，所有的软件工程方面的知识来源于课本和在学校做的小项目积累的经验。另一方面，作者为了解释自己的观点，讲述了多个实际开发项目，而这些项目年代久远，所涉及的一些技术不是十分理解。

  虽然书名为人月神话，但全书所涉及的内容远远不止这一话题。很多内容，没有亲身经历过项目经理这一角色，我想还是不能理解的。而且读的是中文译本，这更加增大了理解的难度。即使看了书的最后部分，作者本人对一些观点的解释，最终还是觉得云里雾里的。我将自己已读懂的观点分为三个部分：团队建设与管理、工程项目管理和软件开发产品本身。

  第一、对于真正投入市场运营的软件产品，即使是再优秀的程序员，也不可能独立完成，必然需要一定规模的软件开发团队协作，来达到最终的目的。而对于团队的建设和管理，作者给出了很多自己的看法和建议。

  在外科手术队伍一章中，作者指出小型、精干队伍是最好的——尽可能的少。这些最优秀的程序员的工作效率是较差程序员的十倍。但是对于真正意义的大型系统，小型精干的队伍太慢了。这一矛盾就需要我们设计一种类似于外科手术队伍的团队架构——既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底地减少了沟通的工作量。

  在贵族专治、民主政治和系统设计这一章中，作者指出为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。这应该也可理解为对团队建设的一个建议。

  团队建设中的一个重要问题就是团队成员之间的有效沟通，如何降低沟通的成本。在画蛇添足一章中，作者认为结构师要牢记开发人员承担了创造性的实现责任，对此结构师只能提出建议。在为什么巴比伦塔会失败一章中，作者提出团队应该以尽可能多的方式进行相互之间的交流：非正式、常规项目会议，会上进行简要的技术陈述、共享的正式项目工作手册。项目工作手册是成员之间交流的有效形式。在该章中，作者同样谈到了组织架构的问题，团队的权力结构是树状组织的，而组织中的交流确实网状的。每个子项目应具有两个领导角色——产品负责人、技术主管或结构师，两种角色中的任意组合都可以是非常有效的。

  在祸起萧墙一章中，作者谈到了成员的态度问题。文章指出，慢性进度偏离是士气杀手。进取对于杰出的软件开发团队，同优秀的棒球队伍一样，是不可缺少的必要品德。

  第二、软件工程，顾名思义，是一个工程领域学科，应具有工程学科的基本共同点。但是软件工程又有别于其他工程学科，有着自己独有的规律。这一特点需要我们思考如何才能高效地完成软件工程管理的任务。

  人月神话这一章，毫无疑问是本书的核心章节。一开始，作者就表明缺乏合理的时间进度是造成项目滞后的最主要原因。所有的编程人员都是乐观主义者，大家总是认为：“一切都将运作良好”。可实际上，在项目进行过程中，总会出现各种不可控因素对项目进度造成影响。并且某些任务无法在不损害结果的情况下加快速度。盲目地向进度落后的项目中增加人手，只会使进度更加落后。因为向软件项目中增派人手从三个方面增加了项目必要的总体工作量：任务重新分配本身和所造成的工作中断；培训新人员；额外的相互沟通。

  在胸有成竹这一章中，作者给出了一些对生产率进行估算的数据，结果表明在基本语句级别，生产率看上去是个常数；当使用适当的高级语言时，程序编制的生产率可以提高5倍。

  在提纲挈领这一章中，作者阐述了规范化的文档的重要性。每一个文档的准备工作都将注意力集中在对讨论的思索和提炼，而书写这项活动需要上百次的细小决定，正是由于它们的存在，人们才能从令人迷惑的现象中得到清晰、确定的策略。同时在本章中，作者对项目经理这一角色的职责做了解释，文章认为项目经理的职责是使每个人都向着相同的方向前进。项目经理的主要日常工作是沟通，而不是做出决定；文档使各项计划和决策在整个团队范围内得到交流。

  在祸起萧墙这一章中，作者提出了里程碑这一概念。里程碑必须是具体的、特定的、可度量的事件，能进行清晰能定义。如果里程碑定义得非常明确，以致于无法自欺欺人时，程序员很少会就里程碑的进展弄虚作假。

  第三、在文章中，作者给出了很多关于软件工程产品本身项目的观点。虽然本书形成的年代的软件和现今的软件产品有着相当的差异，但一些本质上的性质是永恒的，不会随着软件产品的表现形式而改变。

  在焦油坑这一章中，作者表示编程系统产品与程序是不同的两个概念。相同的编程产品的成本，至少是经过测试的软件的三倍。测试工作将会非常耗时，因此相同功能的编程系统构件的成本至少是独立程序的三倍。如果系统有大量的组成单元，成本还会更高。由以上知，编程系统产品，它的成本高达9倍。然而，只有它是真正有用的产品，是大多数系统开发的目标。

  在贵族专治、民主政治和系统设计这一章中，作者围绕概念一致性这一观点进行了讨论。作者认为概念完整性是系统设计中最重要的考虑因素，而为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。

  在削足适履这一章中，作者对软件项目的规模进行了讨论。作者认为规模本身不是坏事，但不必要的规模是不可取的，软件开发人员必须设立规模目标，控制规模。同时，规模预算是必不可少的手段。

  以上是我前面所说的团队建设与管理、工程项目管理和软件开发产品本身这三个方面。当然书中还有很多其他精彩的观点，只举以下两个例子。第一章焦油坑，作者谈到了软件开发人员职业的快乐源泉是什么以及这个行业一些内在的苦恼。在干将莫邪一章中，作者提到了一些提高效率的辅助工具。

  读这本书还是很吃力的，毕竟与作者不在一个次元。等我结束学生生涯，真正走上工作岗位，一定会再看看，相信那时候会有新的收获。