解读CMMI-序

 


  我不接触CMM已经有好几年了,写《解读CMMI》这本书的想法来源于一次午餐时与同事的讨论。通过这次讨论,我感到大多数人对于CMMI的理解只是停留在书本中,无法将书本中的要求转化为实际工作中。其实我也很长时间没有考虑CMM或是CMMI了,但是那段谈话却又从新激起我对CMM的热情。


  如果从我97年接触ISO9000开始算起,我已经做质量18个年头了。在这11年里我经历了从感触到迷茫,从迷茫到重新的认知,到抛弃CMM,直至今天的感悟。这是一个漫长的路程,也是每个质量人员可能都会经历的路程。当我有2年时间不作CMMI而专做生产质量、工程质量后的今天,我感到对CMMI又有个更深一步的感悟,这也许该感谢我的这2年,它让我更有时间进行思考。


  这里面也会融合一些敏捷的实践,这是我在2003-2004年做XP以后又在2013年2015年进行SCRUM敏捷开发和精益创业结合地实践得到的感悟。不得不说敏捷开发是一种继承也是一种颠覆,我会在这里逐渐介绍这两种敏捷的内容与不同之处。


  我也希望博客上的内容得到更多人的关注并针对一些问题进行讨论,这样我们就能有更多的实例,我会尽快将这些实例梳理后放到博客上面。


  第一PA:需求管理


  CMMI的第一个PA就是需求管理,因为需求是一切开发的基础,他直接影响着以后的各个PA。所以对于一个刚刚起步的公司,首要搞好两个部分:第一个就是需求管理,还有一个是测试。只要抓住这一头一尾,研发质量就会有很大改观。


  需求管理在CMMI中目的只有两点,第一是维护、跟踪需求,另一个是确认需求。www.mypm.net


  针对这两个目标,CMMI将需求管理分成了5个SP。


  SP1.求得对需求的理解。即:如何捕获需求。


  我们的需求人员需要将用户需要转化成量化、可测量的用户需求,这个关键点在于:


  1. 定出用户代表,即谁能代表用户确认用户需求:


  只有先正确定出用户代表才有可能作出正确的用户需求。有的人认为领导就是用户代表,这很大程度上是正确的(至少在中国是这样)。但是我这么说你也可以理解为这么做是错误的。比如我最早在钢厂做自动化控制,一个厂家不太懂事,直接和我们领导定下了需求,等到开发完成后一运行完全不能使,没办法我们领导不能替他们背黑锅,损失他们厂家自己担了,所以领导有时又不一定是用户代表。


  那么如何选定用户代表?我建议:先建立业务模型后,将模型分层,每层再找用户代表,这种方式在OO(面向对象)开发中极为有用,这样可以分解找用户代表的难度和风险。这个如果有时间我可以给大家介绍一下,如何进行业务建模后的分层和按层找到用户代表。


  2. 将用户需要转变为用户需求:


  往往用户提出的要求是需要而不是需求,我们需求人员要将需要量化并确认可实现、可测量,这时才是我们需要的用户需求。举个简单例子:用户会告诉我们一个非功能性需要:打开某某页面时速度一定要快。好了,用户要求快,那什么是快?1秒还是2秒?这个就需要我们来诱导用户来明确。还有一些是隐含需求。用户以为你的产品本来就应该达到的,但是往往你并没有意识到,那样也比较糟糕。例如:用户买冰箱,他觉得你是大品牌厂家,低噪音是本来就应该具备的,那么你的产品是这样的吗?另外捕获用户隐含需求,有时还可以使你的产品增值或提高竞争力。仍是以买冰箱为例,如果你挖掘出用户还有冰箱门左右都可安装的需求,而这个需求你的产品是支持的。嘿嘿,你的机会可能就真的到了。


  3. 需求出口要唯一:


  当需求人员比较多时要明确答应用户需求的流程,出口一定要唯一。如果每个需求人员都可以确认用户需求,我们可以想象,我们的需求可能有重复的、相互茅盾的,需求将会一团糟。


  SP1.2 求得对需求的承诺,即:如何进行需求确认

本文原自http://www.mypm.net/articles/show_article_content.asp?articleID=30112

点击关闭
  • CMMI认证客服

    CMMI3认证客服

    CMMI咨询

    CMMI4认证