《人月神话》-贯彻执行

假设一个项目经理已经拥有行事规范的结构师和许多编程实现人员，那么他如何确保 每个人听从、理解并实现结构师的决策？对于一个由 1000 人开发的系统，一个 10 个结构师 的小组如何保持系统概念上的完整性？

1. 文档化的规格说明

手册、或者书面规格说明，是一个非常必要的工具，尽管光有文档是不够的。手册不但要描述包括所有界面在内的用户可见的一切，它同时还要避免描述用户看不 见的事物。规格说明的风格必须清晰、完整和准确。用户常常会单独提到某个定义，所以每条说 明都必须重复所有的基本要素，所以所有文字都要相互一致。这往往使手册读起来枯燥乏味， 但是精确比生动更加重要。

一份合格的手册或者规则说明通常定义了兼容性，描述了将达到的目标，列举了很多外部显示的各个部分：源于某个模型与其他模型差异，带来变化的部分和保持不变 的部分；或者是某个给定模型的拷贝不同于其他拷贝的地方；甚至是工程上的变更引起拷贝 自身上的差异。而这正是一个规格说明作者所应该追求的精确程度，他必须在仔细定义规定什么的同时，定义未规定什么。

2.形式化定义

手册的作者必须注意自己的思路和语言，达到所需要的精确程度。一种颇具吸引力的 作法是对上述定义使用形式化标记方法。

一句古老的格言警告说：“决不要携带两个时钟出海，带一个或三个。”同样的原则也适用于形式化和记叙性定义。如果同时具有两种方式，则必须以一种作为标准，另一种作为 辅助描述，并照此明确地进行划分。

3.会议

无需多说，会议是必要的。

周例会的决策会给出迅捷的结论，允许工作继续进行。如果任何人对结果 过于不高兴， 可以立刻诉诸于项目经理，但是这种情况非常少见。 这种会议的卓有成效是由于：

（1）数月内，相同小组——结构师、用户和实现人员——每周交流一次。因此，大家对 项目相关的内容比较了解，不需要安排额外时间对人员进行培训。
（2）上述小组十分睿智和敏锐，深刻理解所面对的问题，并且与产品密切相关。没有人 是“顾问”的角色，每个人都要承担义务。
（3） 当问题出现时，在界线的内部和外部同时寻求解决方案。
（4）正式的书面建议集中了注意力，强制了决策的制订，避免了会议草稿纪要方式不一致。
（5） 清晰地授予首席结构师决策的权力，避免了妥协和拖延。

随着时间的推移，一些决定没有很好地贯彻，一些小事情并没有被某个参与者真正地接受，其他决定造成了未曾遇到的问题。对于这些问题，有时周例会没有重新考虑，慢慢地， 很多小要求、公开问题或者不愉快会堆积起来。为解决这些堆积起来的问题，我们会举行年度大会，典型的年度大会会持续两周。

4.电话日志

随着实现的推进，无论规格说明已经多么精确，还是会出现无数结构理解和解释方面 的问题。显然有很多问题需要文字澄清和解释，还有一些仅仅是因为理解不当。

一种有用的机制是由结构师保存 电话日志。日志中，他记录了每一个问题和相应的回 答。每周，对若干结构师的日志进行合并，重新整理，并发布给用户和实现人员。这种机制 很不正式，但非常快捷和易于理解。

5.产品测试

项目经理最好的朋友就是他每天要面对的敌人——独立的产品测试机构/小组。该 小组根据规格说明检查机器和程序，充当麻烦的代言人，查明每一个可能的缺陷和相互 矛盾的地方。每个开发机构都需要这样一个独立的技术监督部门，来保证其公正性。

在最后的分析中，用户是独立的监督人员。在残酷的现实使用环境中，每个细微缺陷 都将无从遁形。产品－测试小组则是顾客的代理人，专门寻找缺陷。不时地，细心的产品测 试人员总会发现一些没有贯彻执行、设计决策没有正确理解或准确实现的地方。出于这方面 的原因，设立测试小组是使设计决策得以贯彻执行的必要手段，同样也是需要尽早着手，与 设计同时实施的重要环节。