CMM的本质

CMM的本质

 

陈能技

2007-8-31

 

原文：Essence of the Capability Maturity Model – Judy Bamberger

 

作为动态软件开发（software development dynamics）的研究者,我对CMM很反感。我认为它过分简化了软件过程的问题，对于我们这些已经理解软件开发的人来说提供的益处太少，而对于那些不懂软件开发的人来说则提供了危险的建议。这是我推崇Judy Bamberger的原因。Judy不是一个过程官僚主义者-她是一个充满热情的、有自己思想的思考者。她应用CMM。而且她驯服了CMM，她让CMM跳过了火圈，她把CMM的智慧带出了字面，抛弃了CMM字面的苍白的内容。我从她的方法中感受到很多真实，让我想进一步理解得更好。-James Bach

 

前不久我跟一个软件公司的副总聊天。他说他们公司发明了一种新的概念和方法，工作得很好，叫缺陷委员会（bug council）。这是一个变更请求和bug评审的例会，会议讨论并决定增加、修改、放弃哪些功能特性。

 

我笑着问他：“如果我告诉你，我们已经在用相同的方法工作了15年，只不过我们叫配置控制委员会（configuration control board），你会有什么反应？”

 

“哦”他说，“那我可能会不理你！”

 

我继续问他，希望能给他一些帮助，“我有15年的经验可以跟你分享，这样你的公司就不需要自己创造发明什么自己的方法，而是快速地借鉴其他公司的做法”

 

回答是：“我都不清楚。”

 

最后我问：“你知不知道CMM或者其他软件开发指南能提供很多好的做法？”

 

“知道，”他说，“但是那些东西对于我们来说都不适用，我们公司是很不一样的。”

 

具体上下文中的CMM

我是CMM的主要编写人之一，参与了1.0版本的CMM的全部评审。自从CMM1.0在1991年8月发布后，我就必须要处理很多关于CMM的误解。我发现CMM是在技术文献中最容易让人误解的其中一个。

 

CMM还有很多IEEE标准和指南都尝试从软件开发产业中的有限部分收集各种最好的智慧。但是由于它的规模和密度，我发现人们很难掌握CMM。

 

CMM反映的是大公司的软件开发环境、CMM只是涉及到软件开发的一小部分好的做法、CMM的语言很难懂，这些我都同意。

 

在我帮助一些选择CMM作为改进开发过程的工具的组织时我会面对很多挑战。

 

如果CMM真的是为大公司而写的，那么我作为作者之一有责任让其他人也理解。

 

我在咨询和教授CMM的时候，总是想办法弄清楚我的听众都是从什么样的公司来的，我尝试使CMM通俗易懂，使用他们自己的语言。

 

当我与他们一起的时候，我们会去找寻CMM的本质，CMM带给他们的好处。

 

可重复级：稳定项目

我听到很多人说他们的项目的软件开发是“失控”的。例如：

1、  不知道哪个版本的文件是“正式的”

2、  一个人修改了问题，却引发了另外一个人的问题

3、  在某个版本的特性没有很好地保留到后面的版本

4、  用户与开发人员对功能特性的理解不一致（通常是没有很好地理解最终用户的需求）

5、  功能特性在最后一刻还在改变，并且变更请求是以即兴的方式进行

6、  当开发人员认为不能满足开发任务的要求时不能“回退”

7、  不清楚离完成开发任务还有多少工作要做

8、  不同开发人员开发出的模块或产品显著不同，导致在集成或重写时的混乱

9、  重写或修改比重新开发还要多的时间

 

导致其他的情绪问题：士气低下、缺乏激情、害怕等等。

 

这就是CMM在可重复级要处理的问题：把一些基本的东西控制起来，这样开发人员可以专心地开发软件。这就是CMM在可重复级的本质：

1、  控制产品的发布、控制处于开发阶段的产品组成部分（CMM的软件配置管理关键过程域）

2、  定义特性集合，保证用户的需求被开发理解，控制特性集合以便变更影响被充分理解（需求管理关键过程域）

3、  使用特性集合来评估工作（确保所有承诺的功能特性都得到提供），使用评估来创建进度表和其他计划（软件项目计划关键过程域）

4、  确保进度表和计划可见，以便每个人都清楚他们的目标和对进度的影响；跟踪进度，以便庆祝成功和更好地理解进度调整或功能特性更改对进度的影响；让管理层知道状态、风险和问题，以便得到他们的支持；当基本的假设发生改变时修改进度表和计划（软件项目跟踪和监督关键过程域）

5、  帮助开发组清晰描述计划、所遵循的标准和约定；确保开发组遵循计划、标准和约定；识别和纠正发生的误差（软件质量保证关键过程域）

 

所有这些都是为了帮助开发人员、管理层、测试员、市场人员建立基本的稳定性和可视性。通过使事情明朗化，每个人都直接参与或间接参与进来，增加成功的机会，更加愉快地工作，花更多的时间在增值的活动。

 

这些概念对我自己本身而言也是非常有价值的，无论我是在写代码或是开发培训教程，还是写报告或做咨询服务。

 

普遍特性：没有什么神秘的

我从来没有看到重复级神秘地出现，即使是一个团队、项目或组织认识到能通过重复级获得真正的益处。我会问：

你是如何让那些最佳实践发生的？

你是怎样评估你正在做那些实践？

 

这些是CMM的普遍特性的本质-那些触发者和评估者需要确保的是：大家需要做的做了并且做对了，并且第一次如此，以后每一次都是如此。好的触发和评估实践会帮助开发人员知道他们做的是对的、好的，从而做出高价值的产品。

 

触发者

在CMM中，触发者包括检查单、模版、培训、工具、规范和程序等，这些都是为了提供给大家知识、技能、工具去正确地完成工作，并且每次都跟第一次一样正确地完成工作。

 

评估者

在CMM中，评估者包括工作是否完成的检查、状态监督、质量检查、效率评估。这些信息提供给开发人员、项目经理和管理层，以便他们及时有效地做出决定。

 

 

以上是我对CMM的本质的理解，你也应该有你对CMM的本质的理解，找出来并应用到你的项目中去，为你的项目提高软件开发能力服务。