初窥软件项目管理——《人月神话》读书笔记

人月神话读书笔记

借助软件工程作业的机会，我阅读了Frederick P. Brooks的《人月神话》这本书，作者从大量的软件工程实践中，总结出了很多具有洞察力的见解，提出了很多发人深省的观点。不过由于缺少工作经验，对于实际软件系统的开发也不是很熟悉，所以更多地站在学生和程序员的角度来阅读这本书的。书中的几篇文章是针对项目经理或者其他管理人员的，作为学生不敢妄加评论。因此就记录一下几篇对我有启发的文章的理解。

焦油坑

过去几十年的大型系统开发就犹如这样一个焦油坑，很多大型和强壮的动物在其中剧烈地挣扎。他们中大多数开发出了可运行的系统——不过，其中只有非常少数的项目满足了目标、时间进度和预算的要求。

这篇文章将大型软件系统的开发比作焦油坑，并且用一张图阐释了单个程序员开发的程序，到一个可以发布的软件系统所要做的工作和成本。这中间需要程序完成通用化、测试、文档、维护的工作，并且保持和接口、资源、其他构建资源的相互协作，才能成为一个可以发布的软件系统。

文章还讲了开发软件系统的职业的乐趣和苦恼之处，使我对以后可能从事的职业也有一个大致的了解。

人月神话

这篇文章提出了缺乏合理的时间进度是造成项目滞后的最主要原因。至于如何造成时间进度缺乏的呢？作者认为，编程人员期待在实现中不会遇到困难和bug。然后，管理人员错误地估计了开发人数和时间的关系，即“人”与“月”的关系，任务有次序的时候，人手的添加对进度没有帮助。这是因为人数的增加必将带来沟通和交流的负担。除此之外，没有预留充分的测试时间也是造成时间进度不合理的原因。最后作者提出了一下的法则：

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

贯彻执行

这篇文章提出了手册是文档化的规格说明，它描述和规定了用户所见的每一个细节。这是结构师的主要产物，而对于实现人员而言，他们的设计和创造不应该被手册限制。

形式化定义精确、更加完整、差异明显，但是不易理解。记叙性文字可以显示结构性的原则，很容易地表达一场和强调对比的关系，可以解释原因。这两种定义方式各有所长，必须一种作为标准，另一种作为辅助描述。

除此之外，文章提出了周例会和年度大会两种会议形式，并且希望保留问题和回答的电话日志。

通过以上的措施，保证团队中顺畅而及时的交流，贯彻执行设计的一致性和概念的完整性。

削足适履

这篇文章主要是讲了程序在设计与实现时需要注意，程序所占据的空间也是主要的开销，程序规模是软件系统产品用户成本中一个大的组成部分。从而在文中提出了规模控制、空间技能等措施。

关于规模控制，作者认为应该制订总体规模的预算和后台存储访问的预算，同时在指明模块有多大的同时，确切定义模块的功能，防止在模块空间规模出现问题时，出现功能上的相互推卸。

程序可以有很多的选择功能，每个功能仅占用少量的空间之时，可以设计成拥有若干选项的分组，根据选项组来剪裁程序，这需要设计人员来决定用户可选项目的粗细程度。

数据的表现形式是编程的根本，开发软件系统战略上的突破通常来自数据或表的重新表达，通过从代码中挣脱出来，回顾、分析实际情况，仔细思考程序的数据。

未雨绸缪

这篇文章阐释了变化是永恒的，用户的需求和期望在变化，开发者对用户需求的理解在变化，适用的技术也在变化，故而最佳的解决策略也可随之变化。软件开发团队应灵活地配置人力和资源，适应开发过程中的种种问题。程序的复杂性、用户需求的不确定性、软硬件技术环境的发展等因素导致了软件维护工作并非总是能够百分之百地获得回报。主要包括以下三点：

试验性工厂和增大规模
- 构建一个试验性的系统，然后实现系统的丢弃和重新设计，最后开放一个更灵巧或者更好的系统。
- 预先计划抛弃原型的开发。
唯一不变的就是变化本身
- 变化是与生俱来的，不是不合时宜和令人生厌的异常情况。用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。
- 软件产品易于掌握的特性和不可见性，导致它的构建人员面临永恒的需求变更。
为变更计划系统
- 包括细致的模块化、可扩展的函数、精确完整的模块间结构设计、完备的文档。
- 最重要的措施是使用高级语言和自文档技术，以减少变更引起的错误。
- 变更的阶段化，每个产品都应该有数字版本号。

干将莫邪

项目经理应该制订一套策略，为通用工具的开发分配资源，同时必须意识到专业工具的需求，这篇文章说明了软件开发项目选择的技术和工具在项目的开发中至关重要，包括目标机器、辅助机器和数据服务。

目标机器就是软件所服务的对象，程序必须在该机器上进行最后的测试。所以团队开发的监督程序或其他系统核心软件需要自己的机器，需要配备调试机器或者软件。

辅助机器和数据服务主要有以下三种。仿真装置，如果目标机器是新机器，就需要一个目标机器的逻辑仿真装置。编译器和汇编平台提供了程序的辅助平台，为目标机器编译代码，然后在仿真器上进行后续的调试。程序库和管理属于经理。

整体部分

这一篇文章提出了自顶向下的设计，将程序开发划分为体系结构设计、设计实现和物理编码实现。

自顶向下设计将设计看成一系列的精化设计，先得出粗略的任务定义和大概的解决方案，然后对该定义和方案进行细致的检查，将上述步骤的解决方案进一步精化，最后得到算法的精化和数据表达方式的精化。

自顶向下设计的清晰的结构和表达方式更容易对需求和模块功能进行精确的描述，模块分割和模块独立性避免了系统级的bug，细节的隐藏使结构上的缺陷更加容易识别，设计在每个精化步骤的层次上是可以测试的，所以测试可以尽早开始。

另外一面

这篇文章主要记述了作者对文档的理解以及写作文档的方法和技巧。

软件项目开发中需要的文档有三种。

使用程序。对程序进行描述的文字。包括目的、环境、范围、实现功能和使用的算法、输入-输出格式、操作指令、选项、运行时间、精度和校验。
验证程序。测试用例（针对遇到的大多数常规数据和程序主要功能进行测试、对输入数据范围边界进行检查、非法数据测试）。
修改程序。调整程序或者修复程序。

然后文章提出了自文档化的程序，即把文档整合到源代码。有三种方法来实现这种程序。

借助那些出于语言的要求而必须存在的语句，来附加尽可能多的文档信息。例如标签、声明语句、符号名称。
尽可能地使用空格和一致的格式提高程序的可读性，表现从属和嵌套关系。
以段落注释的形式，向程序中插入必要的记叙性文字。

上面的三种方法，以及后面提到的文档写作技巧，有一些在以前接触的javadoc和python文档的编写规则中接触过，这次阅读也加深了自己的理解。

上面几篇文章是我这次阅读印象比较深刻的几篇，其他文章也给了我或大或小的启发，但是囿于我现在的代码水平以及项目开发的经历和经验，深觉自己不能完全理解文章的核心和精华，所以能写出来的笔记或感想也很少，希望在以后的学习和工作中，能够有机会温故知新。