您现在的位置:e-works > 智造书屋 > 书籍列表 > 代码之殇 > 2007年2月1日:“糟糕的规范书:该指责谁?”

第三章 根除低下的效率

第五节 2007年2月1日:“糟糕的规范书:该指责谁?”

    变得稳健

    规范书必须是稳健的。它必须是可被验证的,并且所有定义的功能需求和质量需求都能被满足。你可能会问,“怎么做到?”但“怎么做到?”究竟是什么意思?怎样在第一时间验证需求?那就要编写测试,对吗?对!这就是你怎么写出一份稳健的规范书的方法。在规范书的第一节中,当你列出功能和质量上的需求时,应该包含如下内容:

    唯一标识优先级功能或质量简短描述相关应用范例用于验证需求的测试

    如果你不能指明一个测试来验证一个需求,那么这个需求就不能被满足,因此要把需求丢弃。不能丢弃?那好吧,重写需求,直到它能被测试为止。

    作者注:我相信,一个可靠的设计把“测试”和“需求”放在基本同等重要的地位。每个需求都应该有一个测试。每个测试都应该基于一个需求。这将导致,清晰而可被验证的需求;更加全面的测试;一致的完成标准(即所有测试通过等于所有需求得到了满足);以及更好的设计,因为测试驱动的设计自然要更加简单,更加内聚,具有更松的耦合。

    获取反馈

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

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

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

    集成质量检查

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    隐私问题解决了吗?涉及安装和升级问题了吗?

    用户界面是否有亲和力?维护问题解决了吗?

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

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

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

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