当客户需求变更时，根据CMMI如何确保需求与其他工作产品的一致性？

问题分析

不管是不是基于CMMI研发管理的要求，所有工作的产出都是基于需求的，他们本来是一体的，但是为了某些需要而被分离开，所以保持他们之间在知识、概念及信息上的一致性是至关重要的。

在这里，我们首先要明确唯一的一条原则，也是最重要的一条原则：对于软件开发过程来说，如果纯粹是为了让计算机（机器）去理解我们的产出物（如代码），那么一致性问题始终是一个较容易解决的问题，毕竟我们与机器之间的沟通，虽然很困难，但至少是单线程的，如果出现了理解不一致，则很容易被反映在最终成果上，也就容易被修改。换句话说，我们要保持工作产出物一致性的根本动机是：保持在整个团队成员在认知上的一致性，也就是保持可沟通。

一旦我们确定了这条最高原则，我们至少可以尝试用CMMI这样的过程改进与评估方法去衡量什么是优秀的一致性了，即：只要能充分满足不同团队成员之间的有效沟通，则就满足了工作产出物之间的一致性，达到了此标准后，哪怕在这个问题上再多一分的投入，都是一种浪费。

下一个问题就变成了：在CMMI所要求的软件过程中，哪些工作产出物是急需保持一致性的？

这是个关键问题，对于许多工作来说，最大的问题就是不分轻重缓急、大包大揽。保持一致性是一件极其困难的工作，其成本代价很大，如果不是以保持有效沟通为原则，很容易就陷入什么都要去维护的死循环。

一旦提出了正确的问题，操作是较为简单的，将项目团队所有关键的成员聚集在一起，了解在所有的工作产出物中，到底哪些产出物（如代码、测试用例、需求书等）对于沟通是至关重要的，并且是真的起到了沟通作用的，将他们列出一张列表，并且在其后的工作中，严加审核与控制。

通常，就我们在CMMI过程改进中的经验，由于许多的产出物是一种草稿，根本不值得维护（如许多的UML设计）。另一些，则根本起不到沟通的作用（如许多需求规格书只是样子，在实际沟通中根本乏人问津）。根据软件公司在进行CMMI认证与改进的经验来看，最大最可能需要被强烈维护的产出物包括：

● 需求说明书（或者如敏捷里的Story）

● 代码

● 数据库设计书

● 测试用例

当然维护一致性的操作与内容一样重要，再下一个重要问题是：如何保持一致性？

基于我们的最高原则，即有效沟通，我们能够理解维护工作产出物的一致性只是手段，其目的是为了保持团队沟通与理解的一致性。

多数情况下，我们根本没有对机会、问题、概念与信息达成一致，就已经更新到产出物中，这也是为什么一致性维护的工作始终不受人欢迎的主要原因，因为他根本不能维护一致性，起不到应有的效果。

理解这个问题之后，我们要明白一致性工作不是简单的编写文档，而是沟通。将某一内容的所有涉众组织起来进行一次一致性沟通会议，在会议过程中同时对重要的产出物进行逐一评审，这样的评审会不仅目标明确，而且富有效率，重要的不是怎么去编写文档，而是如何达成理解的一致。一旦达成一致，文档中该用什么形式保持这种理解，就是水到渠成的事情了。

最后，我们可以提供一些建议和意见。

解决方案

1、使用最精简的工作产出物

在CMMI的要求中之所以产生《需求说明》，是用领域语言来表达解决方案，一份《需求》是用来在客户与工程团队，设计人员与开发人员，研发人员与测试人员之间进行交流与沟通的桥梁。而《代码》则显然是用来在工程人员与电脑机器间建立沟通的桥梁。

《需求》与《代码》试图表达的是同一个内容，只是表达形式不同，这样一次变更就必须维护两份文档。这就是为什么如今众多的工程或技术书籍都如此强调编码规范的问题，尤其是强调代码可读性的问题，如果《代码》只是人们写给计算机去理解的，那么只要符合程序语言规范，计算机就一定能够理解。

如今，我们之所以在代码可读性上大做文章的主要原因是，试图用写给机器的文档——代码，用来作为项目团队中不同角色之间也可互相沟通的文档。

如果去除那些不必要的文档（对应CMMI认证改进中的裁剪），同时让文档发挥更多的沟通作用，从而精简工作产出物将有利于提高维护工作产出物一致性的工作效果与效率。

2、严格的审核与重构

对于那些已经确定必须要维护一致性的工作产出物。现在，人们已经学会去重构代码，即保持代码的精简，实际上在整个重构过程中就好像是写作过程中重新读一遍自己的草稿，从而不断加深对于不同部分的印象。

这对团队之间的沟通具有里程碑式的意义。同时，人们虽然意识到团队之间的沟通很重要，但是人们还没有意识到由于项目周期较长，变更众多，所以人们还需要不断和自己沟通与交流，与过去的自己交流。

这就是重构的意义所在，但是我们还没有尝试有目的和有计划的重构工作中其他重要的产出物，而这可能比代码重构带来的意义更加巨大。无论如何，基于第一问题所挑选出来的列表中内容必须被严格的审核与维护，这是无法讨价还价的。但另一方面也只有值得被维护的文档才值得花费工作量。

3、多用反向工具

由于维护一致性的工作量是如此巨大，以至于如果没有提高效率的工具，人们很难尝试去展开维护一致性的工作。现在我们有许多的反向工具，如从代码中反向出设计图，从具体的数据库中反向出数据表视图等等，这些反向工具十分容易获取和操作。

4、沟通与培训胜于编写文档

最后一条实际上已经在整个文档中不断被提及，那就是工作产出物的意义在哪里？在于沟通与理解。所以，如果可以给出最后一条建议，那就是加强沟通，而不是编写文档，才是维护产出物一致性最为关键的工作，文档只是记录工作。要知道，没有研发团队不是超负荷运作的，团队不能白白浪费工作量。