《人月神话》读书笔记（六）

第六章 贯彻执行

我们组建好了一个团队，要正式开始执行项目任务了。那么在执行过程中，如何确保项目团队的每个人都能听到、理解项目的需求？如何保证系统概念的完整性？

可以通过以下几种方式来达到目的：

一、需求规格说明书
书里的文字描述是“文档化的规格说明-手册”，根据我的理解，这里说的应该就是用于项目团队内部以及外部沟通对接需求的“需求规格说明书”。

为了保持文字风格和产品的一致性，须由一个或两个人来完成将结论转成书面规格的说明的工作。需求规格说明书的风格必须要清晰、完整和准确。我们可以结合形式化定义和记叙性定义来编写规格说明，形式化定义可以描述此功能需求的精确度，记叙性定义可以对此功能需求进行解释和说明。因此，规格说明书里定义的问题是可以通过测试来进行验证的。

二、直接整合
这一段我看不太懂，我的理解是需要统一某种格式，来定义系统之间的接口，系统开发人员需要按照一种规范来编写接口文档。

三、会议和大会
会议是很有必要的。但是会议一定要能够得出结论，或者达成某种目的。我们可以根据不同的场景组织会议。比如每周进行一次进度汇报和总结的周例会、与项目相关方的需求讨论会等。

为了能够开一个高效和有用的会议，我们可以提前准备一份会议的手册，在会议开始前分发给会议的参与人。会议中，任何人都可以提出问题和意见，提出的问题和意见在会上进行讨论决策，记录在会议手册，在会后统一发布最终结论。

四、多重实现
多重实现我也没看太懂，我的理解，是要保证需求说明统一规范、开发语言统一规范、运行环境统一规范等。在这种多重因素的统一实现之下，能够更好地保证系统概念的完整性。能够使项目执行过程更加的整洁和规范。

五、电话日志
无论需求规格说明书有多么地精确，还是会出现结构理解和解释方面的问题。显然，很多此类问题需要文字澄清和解释。对于存有疑问的实现人员，我们应该鼓励他们打电话询问需求的相关对接人，而不是一边自行猜测一边工作，自行猜测工作的结果很容易因为理解不当而做了无用功。

对于电话沟通的结果，应该公开告知给项目的所有人员。一种有用的机制，就是由项目经理保存电话日志。在日志中记录每一个问题和相应的回答，每周进行一次汇总和整理，然后分发给项目的所有人员。

六、产品测试
设立测试小组是使设计决策得以贯彻执行的必要手段，测试小组会根据规格说明检查机器和程序，查明每一个可能的缺陷和相互矛盾的地方。