CMMI实践 - 需求追踪的实施

 

需求追踪的实施

 

需求开发与管理，一向都是开始CMMI 过程改进的短板。这个问题在中国比较普遍。要把需求的工作做好，就需要首先培养需求意识。需求意识导致一系列在需求管理领域的改进与提升。需求意识的一个关键概念，就是就是“项目的使命是实现需求”。用一个比较实在的说法，就是“不多不少地按需求实现产品”。CMMI 的需求管理过程域里，谈的都是如何更好地满足这个目标。其中最能直接确保“不多不少地按需求实现产品”的方法，就是需求追踪。

 

很多人员都投诉，认为需求追踪的工作量太大。而且有很多操作的疑问。其中最重要的包括：

1.   追踪的需求粒度

2.   谁负责追踪

3.   投入是否值得、等等

 

这些都是与需求意识有关的问题。让我们在这里讨论一下这些问题。

 

追踪的需求粒度

 

这个问题的出现，表明需求文化还没有树立。你想想，如果项目已经认识到项目的使命，就是实现需求，那么，对于那些需求需要实现，就会非常明确。否则，产品的开发，就不是真正依照需求，而是有些需求被遗漏、可能包括需求以外的、开发人员附加的。我们很多时候阅读需求文档，不一定可以确认那些是必须实现的需求条项，哪些只是帮助读者了解含义的描述。在这方面，我们可以从CMMI 的定义中找到启发，因为 CMMI明确规定在模型定义里面哪些是必须（mandatory）的，哪些是常规（expected）的，那些是描叙、哪些是解释、哪些是特例、引申、等等。

 

我们的需求开发，也应该可以做到这个程度：看需求文档的时候，都可以明确知道哪些是需求，那些是描叙。如果没有做到这一点，谈需求粒度是意义不大的。

 

（明白这一点，是需求意识，要求做到这一点是需求管理。当领导与下游员工要求需求文件具备这一点的时候，系统工程人员才有机会发展在这方面的能力，需求描述是需求开发的一个方面。所以需求管理，是需求开发的基础。）

 

那么，追踪需要精确到什么程度？这是一个实在的问题。

 

答案在于项目自己。如果追踪需求，是为了满足CMMI 的过级要求，那么，任何在这方面的工作都是额外的，所以任何粒度都是太小的。最好就是不需要追踪。

 

如果我们希望开发客户满意的产品，项目就需要不多不少地按需求实现产品。（当然，需求能满足客户是一个前提。如上面所说，不多不少地实现需求的态度，才是提升需求水平的动力。）那么，如果有些需求内容没有实现，你在乎么？可能你说，有些在乎，有些不在乎（其实这个态度本身就不很正确。为什么？）。那么，那些你在乎的需求内容就值得花很多一点精力去确保它的实现。这就是需要追踪的粒度，意义就是在于投入的工作量是值得的。

 

我举一个例子：汽车的颜色需要是“什么什么亮度”、“什么什么表滑度”的“中国红”。

 

你看，如果汽车是 QQ ，一般客户不在乎亮度与滑度，那么，你的需求粒度就是“汽车的颜色是中国红”。如果汽车是BMW，劳斯莱斯，等，客户也会同时关注表面的光滑度。那么，你就有三个需求需要追踪了。就这样，到底需求追踪的粒度是一个“汽车颜色”，还是三个：“中国红”、“某程度的光反射度”、“某程度的平滑度”，就需要明白需求的人来决定。这个人应该就是需求文件的作者。

 

总结一下，需求追踪的粒度，在于需求的性质、重要性、项目的操作习惯、投入的回报等等。这是一个项目的决定。对于不很成熟的项目，当然可以从比较粗一点的粒度开始，体现哪怕只是一部分，但回报是蛮高的好处。这也非常不错呀。

 

谁负责追踪

 

这是一个很值得思考的问题。CMMI 在 GP2.4不是说要明确职责与权限么？职责的定义，是需要有原则的。常用的原则有：谁承担后果，谁负责、谁负责效益最大、与任务关联性最大、等等。这些职责的分配，有时也会因为使用的方法不同而有它的特殊性。在这里让我们假设是用一个Excel的 xls 表来追踪。

 

第一，谁负责明确追踪从哪里开始、追踪到哪里？比如，追踪是否从市场需求开始，还是产品需求开始？需求是否追踪到架构设计文档？详细设计？等等。这明显是项目经理的责任，因为项目经理需要承担产品质量的后果。

 

项目经理可以决定需要追踪到哪些工作产品（工件）。比如：项目经理可以决定需求不需要追踪到详细设计，因为详细设计与模块是一对一的关系（注：如果这个假设部成立，这个决定就不一定充分）。那么，需求就追踪到模块与测试用例就可以了。

 

决定了之后，每一个需要追踪的文档，就在需求追踪表里建立一个列。通常追踪表都有“需求”、“架构设计”、“模块”、“测试用例”等几个列。

 

第二，谁负责建立这个需求追踪表，并把需要追踪的需求罗列清楚？

 

从后果来看，就是项目经理与系统工程师。加上效益，因为系统工程师清楚每一个需求的重要性，由他来负责，效益最大。

 

第三，谁负责填报各个工件的需求信息？

 

无论从后果与效益来考虑，都明显是这些文件的作者。因为如果需求没有实现，将来要修改，还是作者负责的。同时，作者们在制定文件的时候，应该是依据需求的。所以内容与需求的对应，只有作者最清楚。由他负责填报自己文件里面的需求追踪信息，效益最大。

 

总之，我的提议是：谁做工作产品的，谁填跟踪表。客户需求的作者，负责在需求追踪表里填写客户需求的资料。把客户需求一条一条地填上去。然后产品需求根据客户需要开发，产品需求的作者就把与市场需求对应的产品需求信息，填到跟踪表，和客户需求对应起来。测试人员，把测试用例，填到跟踪表，和需求对应起来，如此类推。

 

需求追踪的投入是否值得

 

这个问题有两个方面。第一个，是需求对产品的重要性。我的感觉就是我们还不能完全地依据需求开发产品。其实建立了需求的文化之后，实现需求就变得非常重要。如果不重要，就不要写到需求文档里面。如果重要，就自然会在乎需求是否得到实现。就希望能从头到尾监控需求实现的过程。因为越早发现问题越好。所以需求追踪从本质来看，是值得的。

 

第二个问题就是回报的问题。我们投入的工作量是否值得。我们就需要找一些最简单、最方便、最有效的方法，来确保我们的投入是值得的。上面的职责分析，就是识别最高效的投入的方法。

 

其实方便、高效的方法，往往都是最简单的、与工作、任务有明显的关联，让这些追踪的步骤融入到任务之中，变成理所当然的境界。这里举一、两个案例：

 

1.   把需求追踪与评审关联起来

 

第一个案例，就是把评审与需求追踪结合起来。如果我们这样考虑：不需要评审的文件，就不需要为需求追踪到这个文件。这个政策是基于重要的文件，都需要评审。这其实不是一个合理的假设。不进行评审，不代表不需要追踪需求。但是用评审帮助需求追踪，是一个补充的方法，而且也强制地让评审彻底检查文件对需求的符合性，这对评审的效率有好处。

 

评审文件时，预备好需求追踪表。可以在评审的过程中，确保实现了哪些需求。而且立刻把这个文件的段落编号、页数、等等信息，填写到相应的需求项的行上面。这样，关键的文件得到评审之后，就有一个最新的需求追踪信息了。

 

2.   建立需求追踪的工具

 

第二个案例，其实是一个工具。但同时，也需要一定程度的成熟的需求规范。比如：对于需求粒度，已经可以用需求项来处理。每一个需求项，都有它的编号。

 

项目里的工件，都要求用一个特殊的符号，标示这个需求编号。比如：

 

*! 界面-301 !*

 

在每一个 *! 与 !* 之间，就是需求编号。在写需求文档的时候，要求以这个符号标示每一个需要追踪的需求项。其他任何文件，在实现这个需求项的地方，都需要使用这个符号与需求项编号来标示。

 

这样，我们就可以开发一个工具。自动地把所有的项目文件过一遍，把文件里的这些符号所在的段落、页数记录下来，与需求编号对应起来，编排成为一个需求追踪表。每一次文档更新了，就用这个工具过一遍，需求追踪表就自动更新好了。

 

结语

 

需求追踪是CMMI 需求管理过程域里的实践。所以是一个“常规”。就是说如果不满足，可能过不了级。CMMI之所以这样规定，就是在于这样才可以真正确保，在整个开发过程中，都可以监控需求是否被不多不少地实现。

 

需求追踪一定有其必要性。问题是，如何可以让需求追踪的投入变得合理，并能得到应有的回报。希望大家可以在这里找到一些冲击与启发。