为CMMI正名

2010-09-08  籽藤 

  这两天跟着Maggie,猛往脑子里灌CMMI的知识,我总算是对22个过程域有一点概念了。其实CMMI是有3大体系的:面向开发的CMMI(CMMI-DEV),面向采购的CMMMI(CMMI-ACQ),面向服务的CMMI(CMMI-SVC)。尽管它们的核心是一样的,但是每个体系都对应各自专门的过程域。当然,我们关注的22个过程域,都是面向开发的CMMI-DEV体系中的。
 
   近几年,企业进行CMMI评估已经成了一种风气,有资格的没资格的都爱往上凑。大学课堂上,曾听一位老师讲述对CMMI的看法。他说,CMMI只对企业有用,对个人没什么用;规范和改进软件的开发过程,这本身就是只对团队有利,它削弱了个人英雄主义。这段话对当时的我而言,很受用。因为我当时存在两点误区:
   1.CMMI需要大量不必要的文档,这无形中增加了个人的工作量,而企业过了CMMI几级后,无论是否遵循CMMI,对个人的专业技能都没有什么提高;
   2.把太多的东西文档化,会降低个人在团队中的价值(因为你设计的思想、算法,大家都能了解,也就能很快接手你的工作)。
 
  现在看来,我真的错得很离谱。因为我没有意识到,CMMI的初衷并不是制定严格的标准,而是提出开发过程改进的建议。当然,国内很多不知所谓的企业急功近利地过级,已经把CMMI”妖魔化"了。大家觉得CMMI很虚很假,脱离实际,过级了也没什么用。
  如果你认真看过SEI的CMMI说明,你会知道那些只关注成熟度级别,而非过程绩效改进的人有多么可笑。(当然,我曾经也是那些可笑之人中的一员)
 
  CMMI的核心是过程域(Process Area)。我个人理解的过程域,就是软件开发过程中某些活动的集合,如项目计划、需求开发、配置管理等等。每个过程域都对应一些目标(Specific/General Goal)和实践(Specific/General Practice)。对于Practice,CMMI会对相应的活动、文档进行举例说明;同时,CMMI对每个过程域的相关过程域都进行了描述。
比如“项目计划”,它的特定目标和实践有:
Specific Goal and Practice Summary
SG 1 Establish Estimates 

 SP 1.1 Estimate the Scope of the Project 
 SP 1.2 Establish Estimates of Work Product and Task Attributes 
 SP 1.3 Define Project Lifecycle 
 SP 1.4 Determine Estimates of Effort and Cost 
SG 2 Develop a Project Plan 
 SP 2.1 Establish the Budget and Schedule 
 SP 2.2 Identify Project Risks 
 SP 2.3 Plan for Data Management 
 SP 2.4 Plan for Project Resources 
 SP 2.5 Plan for Needed Knowledge and Skills 
 SP 2.6 Plan Stakeholder Involvement 
 SP 2.7 Establish the Project Plan 
SG 3 Obtain Commitment to the Plan 
 SP 3.1 Review Plans That Affect the Project 
 SP 3.2 Reconcile Work and Resource Levels 
 SP 3.3 Obtain Plan Commitment 
我们可以看到,CMMI已经教我们在项目估算(SG1 Establish Estimates )时,可以做以下几件事情:

  1. 确立项目范围(SP1.1)
  2. 确立工作产品和任务属性的估算(SP1.2)
  3. 定义项目生命周期(SP1.3)
  4. 确定项目成本的估算(SP1.4)

  当然,CMMI告诉你的不仅仅是这些,它还告诉你在“项目计划”过程中,还要“计划实施项目所必要的知识和技能”(SP2.5)、“计划利益相关人的参与”(SP2.6)……不仅如此,在CMMI的文档中,对每个SP都有Typical Work Products,即产出物的例子。对于SP1.1有:

  1. Task descriptions
  2. Work package descriptions 
  3. WBS

  所以你知道了吧,CMMI是帮助我们去更好地进行软件开发,更好地控制开发过程。哪怕你是在几个人的小团队,也完全可以借鉴CMMI的思想,把它融入到敏捷开发中。

最后推荐大家看一份PPT:http://www.slideshare.net/sempsalon/agilecmmi#
它会告诉你,CMMI和敏捷,不是敌人而是朋友。

351°/3514 人阅读/0 条评论 发表评论

登录 后发表评论