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

第三章 根除低下的效率

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

    在线资料:规范书检查清单(Spec checklistdoc)。

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

    取而代之的是,文档中的相关区块都可看成是功能的逻辑性组件(比如应用程序编程接口、对话框、菜单等)。重复消除了。每个功能组件完整地被描述出来,并且所有的质量要求都融合在了设计情境中。

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

    差别在哪里

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

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

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

    所有功能和质量上的需求都可以被验证。

    我也已经谈到了,我们还有机会把规范书写得不那么正式一点,并且更容易被理解。

    那么谁该为糟糕的规范书负责呢?其实我们都有责任。不过,糟糕的规范书主要还是由不良的习惯和糟糕的工具造成的。只要做一些小小的改变,并且使用大大简化的模板,我们就能改进我们的规范书,改善部门之间的沟通,并且促进工种之间的关系。总而言之,这样做可以让我们在微软工作得更加开心而富有效力。