CMM质量管理的本质

作为动态软件开发（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、 使用特性集合来评估工作（确保所有承诺的功能特性都得到提供），使用评估来创建进度表和其他计划（软件项目计划关键过程域）

原文转自：http://www.ltesting.net