CMMI入门 - 通用实践的实施GP 2.6

上文谈到GP2.5，培训人员。本文继续讨论GP2.6。

GP2.6 控制工件

GP2.6要求每一个任务都符合这个要求：

* 选择一些需要管理的工件，
* 在不同的时间段，
* 用适当的严格程度加以控制。

控制与任务有关的工件，在配置管理过程域里面已经有详细的定义。既然项目在满足配置管理的处理中，已经识别好需要管理的配置项，大部分的CMMI评委都会认为，如果项目可以满足配置管理的要求，这个GP2.6就理所当然地可以通过。这样就解决了CMMI过级的问题。

但如何控制工件，才可以提高效率？作为通用实践的要求，就表示已经养成使用配置管理的习惯，在所有任务都可以恰当地管理好各种工件。混乱的工件很明显对任何任务都可以造成很多麻烦。这个问题的答案在于“恰当”的管理。但什么是恰当？这确是一个问题。过分的管理当然可以因为额外的工作量而降低效率，也经常限制了下游的工作，造成情绪上的问题，破坏项目团队的士气。

我们很多配置管理操作都比较生硬：我们只有一个变更管理的程序，一个变更管理工具，然后从头到尾，当用同一个程序管理所有的工件。这不是一个高效的配置管理模式。

其实有效的工件管理需要考虑上面所提到的三个因素：工件的种类、控制的严格程度、项目的时间段。考虑这些因素的原因，就是要使用最恰当的手段管理这些工件。

首先，就是那些工件需要受控？我们不希望投入任何成本管理一些不会再有人查阅的文件。但是如何判断一个工件将来是否有人需要查阅？这个与任何知识一样，开始的时候，只能通过分析、猜想、判断。后来经验多了，有了历史信息，我们就可以建立一些工件在产品生命周期中的使用的表格，以后的项目，就可以更恰当地管理任何任务的工件了。

分析哪些工件将来需要查阅，可以从识别产品生命周期里的各种“干系人”入手。例如：产品的版本发布之后，就需要生产，就要查阅产品的料单。安装、维护、就需要查阅产品的版本说明与安装、维护的手册。营销需要知道产品能够提供的价值，就是说，产品的功能、性能、操作程序、等等资料。客户下单之后，就需要产品的种种可能的配置组合。所有有关这些资料的，都非常需要保存好，版本需要与产品的版本一致。所以这些都是在整个产品生命周期之中用最严格的方法管理。这些都可以看成配置项，加以配置管理。配置管理包括：保存、版本、变更、与产品版本挂钩的基线管理等等。

另外一种需要长期管理的，就是与法律有关的资料。任何可能承担法律后果的决策，它们的决策过程纪律都要保存。这是记录通常不能变更，是最低的管理层次，但是它们的管理是长期的，需要满足法律的时间要求与限制。

使用范围只限于研发活动的工件，在项目进展中比较多。比如项目计划，它是指导项目活动的依据，所以如果有任何变更，都需要管理好，保证项目成员查阅的时候，都是查到“当时有效”的文件，项目的活动才能有序。所以我们可以看到，项目计划是需要版本管理，也需要变更管理。但是这个管理的实践，很少需要延伸到项目完结之后。

一个与时间段关系最密彻的工件，就是“需求”。需求是一个配置项，因为他的内容与产品的版本需要一对一地对应起来基线。所以需要有版本、有变更控制。但是它的变更控制，可以在项目开始的时候比较灵活一点。比如，变更的评审与认证都不一定需要。但是越接近版本发布，需求的变更就需要控制得比较严格，任何变更，都需要经过评审、批准，都需要经过认证才能检入到配置库里。

同一个文件的管理可以有不同的状态，比如：源代码文件，开始的时候，只要负责人存放好，就可以了。它可以有版本，但是变更就不需要控制得很严格。但是这个文件在集成测试之前，就一定需要变更受控。如果通过集成，就需要基线，等等。管理的层次与严格程度，不断提高。这是理所当然的，文件的价值越高，就越需要管理好。我希望大家可以了解到一个工件，在不同的时间点，可以需要不同的管理严格层次。

一般来说，工件的管理严格层次，从低到高的严格程度，就是：存放、版本、变更、基线。我们可以按文件的性质，在不同的时间，采取不同的，但是恰当的管理手段，达到用最少的工作量，提供最大的价值。

一个有趣的问题就是：既然通用实践是习惯，是我们无论任何任务，都会用上。那么，日常我们有很多处理文件的情况，比如：我有一个文件草稿，《某某草案》，需要分发给甲、乙、丙三位同事评审。甲员工检阅了文件，做了一些修改，然后发回给我。一般来说，我们都不会变更文件名称。所以，我会收到三个文件，他们都是《某某草案》，连我自己本来的，就是4个文件，都是同一个名称。我会做成很大的混乱，我经常因为这个多花很多工作量把他们的内容理顺。后来我就在收到甲发回来的文件的时候，立刻把名称改成《某某草案-甲》。一次类推，我就有4个文件：《某某草案》，《某某草案-甲》，《某某草案-乙》，。我就可以分开那位同事提供的意见。

通常我会把所有的意见汇总到一个文件里，并把这个文件叫做《某某草案-v2》。如果我认为乙同事的意见需要多沟通，我就把我的意见记录在《某某草案.乙》里。乙同事再发回来的回复，我立刻把名称改成《某某草案.乙.乙》，然后才汇总。

我希望从这个小故事可以看到，通用实践其实一点都不深奥，它的作用只不过是一些高效的办事习惯而已。我希望大家可以尽可能地把通用实践落实到日常工作里，这样自己的工作就会高效一点。