第5部分(第1/4 页)

书包　网　。　想看书来

获取反馈

在规范书付诸实现之前，越多的眼睛看到它，它就会变得越好，并且将来要求的返工也会越少。如果你想很容易就能获得反馈，你也想别人很容易就能提出反馈，至少你要将规范书草稿放到SharePoint上，并进行变更跟踪和版本控制。做得更好一点，你可以把规范书放到一个维基站点上去，或者贴在功能团队主要活动区域的一块白板上。

撰写规范书的这个过程、反馈和变更管理需要有多正式呢？像我在前一个栏目讨论的那样（即本章的“停止写规范书”那个栏目），正式的程度取决于沟通是否直接，以及沟通的“带宽”有多大。在同一个共享区域、同一个时间、工作在同一个功能的人们，他们可以使用很不正式的规范书和过程；而在不同时区、不同时间、工作在不同功能的人们，他们则必须要有高度正式的规范书和过程。

不管怎么样，你想让规范书随时都可以修改，直到团队认为它不需要再改为止。那你怎么知道规范书不需要再改了呢？答案是，要等到测试团队验证规范书通过了所有的质量检查。

集成质量检查

这是我们目前正在使用的规范书最离谱的地方。各个部门不是把安全、隐私和许多其他问题当作质量检查，而是把它们一节一节单独地写在了规范书中。这是个灾难，原因是：

？ 规范书变得更大并且复杂得多。

？ 作者必须在各节中复制信息。

？ 读者对后面的节次重视不够，导致严重的质量缺口。

？ 设计变得难以理解，因为它们的描述分散在多节之中。

？ 错误和缺口很容易被忽略，因为没有一个节次对设计作了完整的描述。

？ 更新几乎是不可能的，因为一个最新的改动会影响多个节次，牵一发而动全身。

取而代之的是，采用适合于每一份规范书的质量检查，它以一个清单的形式出现，并且每个人都能触手可得。一开始的几个检查对于每个团队都是一样的：

？ 需求清楚、完整、可验证、并与有效的应用范例关联了吗？

？ 设计满足了所有的需求吗？

？ 所有关键的设计决议都被解决并存档了吗？

接下去的一套质量检查也相当基本：

？ 所有的术语都被定义了吗？ ？ 有没有兼容性问题？

？ 安全问题解决了吗？ ？ 故障和错误处理解决了吗？

？ 隐私问题解决了吗？ ？ 谈到安装和升级问题了吗？

？ 用户界面完全可达到吗？ ？ 维护问题解决了吗？

？ 为全球化和本地化准备好了吗？ ？ 备份和恢复问题解决了吗？

？ 对于响应和性能的期望是否清楚并可测量？ ？ 是否有足够的文档用于支持故障检修？

？ 源代码插桩和可编程能力定义清楚了吗？ ？ 有没有潜在的问题会影响打补丁？

各个团队还可以为他们自己或者他们的产品线增加更多的质量检查，解决他们常常面临的特殊的质量问题。

在线资料：规范书检查清单（Spec　）。

这里的关键是，设计节次对功能进行了完整的描述，而质量检查保证了没有东西被遗漏。是的，这意味着设计节次可能会变得非常庞大，以覆盖所有需要涉及的领域。但这些领域不再是把功能按照每一个质量要求展开的累赘品（比如对话框的安全、对话框的隐私、对话框的可达到性等）。

取而代之的是，所有的领域将是功能的逻辑组成部分（比如应用程序编程接口、对话框、菜单等）。重复消除了。每个功能组成部分完整地被描述出来，并且所有的质量要求都融合在了设计情境中。

作者注：一个奇怪而有趣的巧合：在本栏目发表之后的第二天，Office部门把他们的规范书模板做了简化，只使用单独的一个节次来描述设计，并且采纳了我发布的质量检查清单。尽管我不能对这个改变邀功，但我的成就感着实得到了满足。

书　包　网　txt小说上传分享

差别在哪？

如果增加了所有的这些检查和测试，你可能会怀疑我根本就没有对规范书作出简化。其实，这里的最大改动是：

？ 节次的数量减少到了只剩下3个（需求、设计和问题）。

？ 设计在一个节次中得到了完整的描述。