Introduction to CMMI培训总结报告

来源:互联网 发布:php pdo exec 编辑:程序博客网 时间:2024/06/05 16:26
 

Introduction to CMMI培训总结报告

作者:罗耀秋                    笔名:馨园主人

关于进度

按照整体进度的要求,三天的课程要学完9Module。分别如下:

第一天:

Module 1—— Preliminaries and Course Overview

Module 2—— Model-Based Process Improvement

Module 3—— Overview of CMMI Models and the Staged Representation

Module 4—— Maturity Level 2-Managed

第二天:

Module 4—— Maturity Level 2-Managed Continued

Module 5—— Maturity Level 3-Defined

第二天:

Module 6—— Integrated Product and Process Development

Module 7—— Maturity Level 4-Quatitatively Managed

Module 8—— Maturity Level 5-Optimizing

Module 9—— Summary

但正如先前培训的同事所说的,吴老师是那种典型的大学教师。概念讲的很细,而且喜欢翻来覆去。有些很浅显的地方也不厌其烦的举例子,最典型的是相关干系人和干系人的区别,大家都已经明白了,还满打满算扯了25分钟。

最后的实际进度是:

第一天:讲到了Module 3的小半,占整个讲义厚度的1/10左右

第二天:讲到了Module 5的第9页,还有64Module 5的内容没完成,大概讲到占整个讲义厚度的2/5

第三天:开始开快车,讲完64页剩下的Module5内容,剩下2小时左右讲完45级内容。Module 6 IPPD没有讲。

 

关于学习方式

由于有了科室内部的先期培训同事回来后的宣讲,以及科室内组织了CMMI评估表的翻译,培训前对课程大致架构、CMMI2/3级知识有了较多了解。所以学起来还是较主动,当初吉总和沈龙他们提到的一些疑问和心得处,也在课堂学习中有意识的进行了重点关注并加以印证。如提到上下文关系图的正序反序、如连续式没有GG4GG5等。

当然,由于很多人是带着问题来听讲的。所以难免先入为主的问一些很细节的问题,有些甚至是工程实施的问题。老师可能理论方面很厉害,但具体实施上不一定能有企业EPG这 么能联系实际。所以难免为维护权威而兜圈子,讲一些漫无边际的主题发挥开来。我个人认为,这本来就是一门偏向理论的培训,带着印证问题的想法或是陷入“我 们怎么做,怎么做才对”这样先入为主的思想去听这门课,都是不适合的。把它当作大学里的一门理论课,好好把握其中的概念与脉络,至于怎么与实践结合,课后 再慢慢琢磨吧。所谓道理都是一样的,成就靠个人造化。

由于管苏玮和沈龙他们在前面都就模型本身做了详细的宣讲,我就还是延续吉总的老路,把过程中记录的一些概念、心得和疑惑和大家分享一下吧。个中还加入了自己的一些理解,有不当处,还望大家斧正。

 

一些业界动态

ö         明年可能会换用新版的讲义,最重要的变更可能是不分了连续式和阶段式。因为SEI倾向于认为连续式更有助于一个组织的持续提高。一个过程域的提高是不能跳过等级的,是一个循序渐进的过程。而阶段式只不过是一个组合而已。连续式可以为了特定的目标去改进,如我们虽然处于二级,但为了强调某一目标,我们可以引入三级的某一PA执行。阶段式对于一个不太明确自己组织改进方向的组织,也许是一种很好的模型或者说组合。因为它的2345三种组合,可以说是实践证明了较普遍适用的组合方式,虽然对个体组织来说不定是最佳组合方式,却是最稳妥的方式。

ö         10月底的年会可能会把这个课程在非英语国家或过程改进刚起步的国家扩展到5天。因为SEI不容许翻译教材的出现。目前的台湾版虽然是经过SEI授权的,却还未能通过第一次校审。

ö         CMMI V1.1将在2006年更新。目前国内具备新版教材讲师资格的国内只有吴和周两人。

ö         明年可能开始进行PSPCertificatTSPCouching,以对抗影响日益增强的PMPIPMPTSP其前提是小组成员都接受呢PSP的训练。

ö         将会多一个模型:CMMI-SA,采购,实际就是多了一个过程域。

 

一些基本概念、抑或疑问、抑或心得分享

1、  处于什么等级,取决于你的GG(注:非特殊说明,下面描述的都默认为阶段式表述方式情况下)。

处于什么样的等级就看你的GG,因为每个等级就一个GG,但工程过程除外。也就是说,除了工程外,SP都是要做的。

换句话说,就是按照GP的方式去做SP

大家观察每个PAGG2可以发现,10PA并没说明必做,也没说明不必做。即可以是N/A,也可以是可替代的

能力等级又6级,成熟度等级有5

能跳级吗?——答曰不能,因为上级的GG包含下级的GGegGG3中包含了GG2GG3

能力等级与成熟度等级的关系:能力等级相当于把成熟度等级的视角化小了

换句话说:SGGG是必须的,GG中的GP没说是必须的,但SPGP是期望的

2、  实现代号为x PAy等级,就是按照从GG1GGy下的所有GP的方式去做该PASP

3、  Staged表达式没有GG4GG5,是因为目标是不能给定的。

这里我的理解是:连续式给予了每个PAGG1GG5的连续表现以及持续提高,而staged的成熟度却是预先排好了的,业界证明了比较普遍适用的过程改进的组合。

吉总和施总的意思是,没有必要去区分这种细节,姑且把它当作两种组合方式。在他们传说下,我也总算从老师一开始下的套中解脱出来。

4、 验证和确认的概念

我画了个示意图,可以看到,验证是对上游的工作产品进行检验;

确认是对项目组入口的确认,而不管中间过程。

影射到过程中,VALVER的活动其实差不多,无非就是那些评审/测试活动。只不过——凡是与客户需求有关的,都叫确认。

5、 预审的概念

在讲到VERVAL时候,老师还讲到,PR中的Prepare for Verification并不是预审,而应该是评审的Schedule;而Prepare For Peer Review才是评审的预审。

单纯的PR不一定是VerificationVer是一个综合的目标,有三个SG

6、 Stakeholderrelevant Stakeholder

干系人:与项目有关的人。(可以从我给谁、谁给我这个角度看看)

相关干系人:参与任务的人,eg,技术评审参与者(即他有特定的活动和具体的任务)

(这里我问了一个问题:技术评审的外请专家算啥? 答曰:因为他没有对项目有责任关系,实际上两者都不是。)

7、 关于报告的周期

如果milestone的周期<月报周期,则没有必要出月报了

如果milestone的周期>月报周期,则milestone报告+月报

Milestone的报告包含:

A.定义的点上的量的完成情况(主要是指进展,采用01法则)

B.定义点上的质完成没有

C.如果量不够,怎么办?eg,砍功能,但砍了功能以后,怎么一个实施策略?

D.如果是质不够,怎么办?eg,约定解决措施后续达成质量目标?

8、 认证和评估的概念

9000是认证,发给证书,因为它是外部评价

CMM是内部评估,目的是了解组织的现状,推动过程改进。就像是给病人看病治病的关系,依据的是模型而不是标准。(模型+评估方法)

9、 既然不给证书,那评估个啥啊?即CMMI)存在提供给各个企业的商业目标吗?

SEI提供给各个公司的商业目标就是过级(如在网站上发布过级组织的名录)

CMMI有内部的评估,也有外部的评估

据说,也有公司请评估师对供应商进行成熟度等级的评估,以确定其候选资质。有点象dell、沃尔马等对供应商的认证一样

10、              CMMI评估与ISO9000的认证有啥差异?

ISO9000给组织一个当时的结论,而CMMI则是给组织一个下一步要改进的地方

11、              过程及质量杠杆

质量杠杆:人——技术——过程 过程是质量提高的关键

过程让人SMART的去做工作,而不是去Work hard

过程对于高技能的人来说,可能作用不大,但于对于普遍个体,则作用很大,过程拒绝精英主义。

这里举个红绿灯的例子:

个体:即使有红绿灯的存在,我也可以凭借我灵巧的步伐和敏锐的眼光在车丛中不受约束的穿马路而过而不必等红绿灯

整体:减少交通事故,保证道路畅通

12、              模型的重要意义在于

a、告诉你从哪里开始

b、以往经验的好处

c、一个共同的语言和共享的平台

d、定义一个组织改进方面的含义

e、一个框架for prioritizing Actions

据咨询师提供的小道消息说,现在微软也快扛不住它在软件开发过程管理中的问题了,已经请SEI对这个巨无霸进行会诊了。

呵呵,插一句,原来的象模型来自NASA等这样的需求,那象微软这样的大众用户商业软件的机构,会不会导致模型进行大的革新呢?(顺便说一句,两者要求的质量目标是数量级上的差异)

13、              过程管理的前提来自于长期的过程承诺

一般是两年以上承诺的过程改进才能是过程有固化的成果。所以,要在一个位置上吧一个过程改进做到有结果,频繁的岗位调整和人员变动对过程改进不利。

14、              过程度量、过程改进与考核

讲过程中的数据直接拿去做考核并不是很适合的,但可以作为过程改进的一句。因为以考核为导向会误导一些人的做事方法与目的。

把过程要求和KPI拷屏做一个整合,但度量与拷屏应该是绝对划分开的。

15、              模型簇的关系

图中任何一个节点顺着箭头下来都是一种模型的组合,eg(15)、(35

SSIPPD有点类似我们公司的中试转产和康讯 所以SSIPPD应该是从公司层面进行考虑

而虚框+CMMI Core则可以在个分业务组织中管。

 

Introduction to CMMI培训总结报告(2)


1、 二三级的区别

ö         就阶段上来讲,三级抽取了二级每个项目的公共要求è标准的过程定义+裁减指南

ö         二级中项目的过程定义取决于改项目,三级则是由EPG来具体提供建议。EPG团队中专长工程过程和组织级过程的人负责自己那块的裁剪偏差。

ö         三级才有OPF,因为二级后总结出了有权威的人去负责,这些并不是高层能替代的。也就是说二级没有必要有EPG

2、 连续式和阶段式浅辨

ö         成熟度等级给组织提供了一个改进方向,这点上stagecontinues更有优势。特别是组织自己也不明确改进方向,如不知道先做什么,后做什么的情况下

ö         continues可以一个PA一个PA的去做,而staged则不可以,是一些固定设置的组合

ö         两者的评估结果都能达到组织的商业目标

ö         对某个过程域,提供的内容基本一致,只不过实现的方式不一样

ö         连续式有6个等级,从CL0CL5,而阶段是只有一个è因为阶段式是看不到能力等级的,阶段式只有ML15

3、 SGGG

ö         SG不是能力——要做什么事,不是能力

ö         GG才是能力——做了什么事,如何做才是能力

ö         GG1è能力1GG2è能力2

也就是说:“我做成了这件事,这并不代表我有能力;我每次总能做成这样的事,这才代表我很有能力”。

4、
IDEAL模型的过程改进

I—初始;D-诊断;E-建立;A-执行;L-学习。

基于诊断的发掘问题(D),基于总结经验教训的过程改进(L

2QA和项目组都处于摸索阶段,实际上,QAEPG都要高于项目经理的经验,QA要有能力知道项目经理完成过程活动。

某些公司实行EPGQAPM轮岗制度。

5、 POLICY

体系文件的架构:POLICY/过程/规程&指南/模板表单

每个PA都要由Policy

我们公司的Policy写在哪里呢?

6、 过程域、过程描述和过程定义

过程域不是过程描述,也不是过程定义:因为没有形成必须怎么怎么,也没有形成先后次序

也就是说,过程域不管你怎么做,怎么做,是组织的过程定义的事情。

CMMActivity对应CMMISP

另外,CMM没有common future映射的GP

7、 关于估算

如果规模与工作量无关,就没有必要去估计规模:如审计,维护,应该侧重估计重用率并分析时间的关系。要分析规模是否给你带来直接的工作量?即估计一个折扣值,因为这个时候影响计划工作量的已经不仅仅是规模。

PP中我问及Plan for Data ManagementData含义时,老师讲估算的文档也算是data

8、  当谈到为什么要把measurement and analysis单独列为一个PA时候,老师提到,CMM中只有度量数据,没有度量过程与度量能力。我们可以从每个PAGP2.8中查找需要度量的对象,从这个PA中找到具体的度量方法。也就阐明了为什么有GP2.8还要有这个PA的关系。

9、 目前公司内部度量和计划过程的一些误区

a、管理好计划,必须管理好开始时间,因为不管理好开始时间,很难保证结束时间

b、缺陷率是按月进行的,意义不大,也不合理,应该是按照里程碑和版本去划分进行比较

c、应该从使用数据度量结果的人的角度入手,选择度量数据与度量方法。Eg:评审报告给质量人员看,缺陷密度是可以的,但如果给总工看,则是关注发现了那些缺陷

d、在计划变更前不要改计划:即在调整前的计划和现在的计划都要保留,并且应该从趋势图上分析怎么赶上原计划的

e、不要随意延期,要注意分析:承诺的事情要努力的去做,然后提前告诉人家可能的变更,然后再更改计划

10、              关于PPQA

如何评价过程:观察流程的入口条件、观察过程中间的事情是否都做了,QA要了解过程中间哪个点是关键点,哪个点是易犯错误的点

如何评价工作产品及服务:主要是insight的方式去观察服务,如服务态度、客户问题响应、用户手册的友好性、用户手册给客户做培训了没有,对于产品则关注标准化和规范化的内容。

组织的OT做得比较差,因为没人评估,没有执行这块的QA职能人员。从而,应该有组织级的和项目级的QA存在。

NC即使解决了也要记录在案。

11、              关于CM

一个CR带动多个CI,建议拆分成多个CR,每个CR只关联一个CI

SCM人员是项目组内部的人员,应该有外部一个专门的人员去检查CM规范的人(如功能审计和物理审计)(即有的公司SCM是项目组兼职,而公司的CM人员则是检查各项目的SCM执行情况并提供专业技术支持。因为配置管理与功能关系密切,可能业务领域的人更容易把其做好)

12、              CMMICMMCM上的区别

CMMCM是项目的CM

CMMICM是所有的CM,不关是项目的还是组织上的。如每个PAGP2.6

(e.g.:过程能力基线、过程定义基线、过程改进基线)

13、              区别三个重要的词

Measure——度量源,度量的实体(e.g.102行的“行”),或者说度量项目

Measurement——一系列的相关度量结果(如方法、工具结果)

Measure Value——具体的值(e.g.102行的“102

14、              组织过程的一些概念

EPG的三大块:   过程资产——给项目组提供标准

                            过程数据库:给项目组用(过程数据库不是过程资产)

                            过程改进计划:指导自己的工作

15、              IPM中的一个上下文关系图关于StakeholderRelevant Stakeholder的疑问

PPstakeholder,而IPPDRelevant Stakeholder,所以更具体了。

这里整个是讲Relevant Stakeholder,但在右边方框的小圆圈却是提出了stakeholder,我的看法是:引入这个方框的是Integrated Plans,也就是说,这个方框中站立的角度是各个子项目,对于子项目来说,原来对于IPM是内部的约束,到了这个里面就变成了各个子项目的外部约束了,所以变成stakeholder了。如“站在GSM系统上看和站在BTS的角度看问题”。

当时老师有点在这个问题上兜圈子,答复含混。

16、              关于“风险时间框架”

在讲到风险管理的时候,老师讲到了一点点新的东西,在定义风险参数的时候,加了一项“风险时间框架”。风险时间框架的含义是给你一个采取行动措施的时机,从此Risk由二维变成三维了(概念、影响、时间框架)——具体可参见《持续风险管理一书》

17、              RM里面的这个上下文关系图中我认为少了一个M&C的关联PA

PP进入,肯定有M&C进行管理。因为风险管理是一个持续的过程。

老师建议去SEI的网站上去提一个培训教材的“CR”。

18、              DAR的一些重要概念

ö         进入DAR的一定是项目经理或项目组内部解决不了的,如高风险的、高费用的

ö         所以评估时候有的企业确实找不出需要DAR的东西,但为了评估却必须要凑一个DAR的实例,这个真是有点矛盾

ö         这个PA的上下文关系图入口为Other PAs,也就是说它是其他PA所不能解决的问题而提出来的。

19、              ML4和前面ML23的关系

ö         成熟度等级4提供了一些基本概念,一些detail的事情在前面的PA中都已经提供

ö         不增加过程定义,但修订改进原有过程定义,更强调量化的控制

ö         提出控制计划并按照计划去实施控制,过程被度量了并且基于过程的度量数据去管理自己

ö         二、三级也有threshold(阀值),但是来自于Voice of Customer,是拍脑袋的结果,而不是statisticalquantitative methoud

ö         到了第四级变成了Voice Of Process:基于过去的表现和过去的质量,可以预测未来过程的表现、产品质量和服务质量

ö         这个时候项目组的定义过程中开始带有质量目标

原创粉丝点击