扫码阅读
手机扫码阅读
随需而变,拥抱CMMI V2.0新时代

我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。


麦哲思科技任甲林
扫码关注公众号

摘要
一、前言
CMMI DEV V2.0于2018年发布,是自2011年CMMI V1.3以来的首次更新,结合了敏捷开发等新兴方法,并在全球范围内获得广泛应用。
二、思想的变化
CMMI V2.0强调围绕商业目标进行过程改进,通过性能变化衡量改进效果,要求高层管理者积极参与,并将员工行为固化为习惯。同时,模型变得更灵活,能够适应多种实践方式,随机抽样检查有助于过程的固化。
三、关键术语的变化
实践域取代了过程域,新增了能力域的概念,能力域类型由工程类、项目管理类等四类构成,引入了视图的概念。
四、结构与描述方式的变化
采用更平实的语言描述,整合了People CMM等模型,不再对实践域划分等级而是对实践划分等级。实践域和能力域均配以图标,不再区分特定实践与共性实践,区分了内核信息与特定场景内容。
五、过程域的变化
CMMI DEV V2.0减少至20个实践域,对一些实践域进行了名称调整、合并或增减。
六、评估方法的变化
评估方法中最显著的变化是抽样规则,新增了维持性评估,并允许一次评估包含多个视图,要求提交性能报告,并对评估组成员进行认证考试。
七、结语
CMMI模型积极拥抱变化,适应了组织的更多业务领域,变得更易懂、评估成本更低,并对实践方法的包容性强,将为组织带来更大的商业价值。
想要了解更多内容?


麦哲思科技任甲林
扫码关注公众号

麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
425 篇文章
浏览 194.7K
麦哲思科技任甲林的其他文章
软件项目宏观管理策略点睛
根据国际知名调查机构standish集团的统计,真正成功的项目仅有26%,而其他项目都可以算作失败项目。为什么这么多的项目都失败呢?问题出在哪里呢?依据笔者的经验,很多项目实际上是败在了初期,败在了启动时,败在了项目的宏观管理策略上。即,没有根据项目的特点采用合适的管理策略,即使后续的管理方法再细致也没有用了。我推荐如下八个感触颇深管理策略,供软件项目的管理者借鉴:
控制图典型错误应用一例
有公司在画控制图时,对进度偏差率画了XMR控制图。原始数据如下: 度量日期 开发进度偏差率 05-14 -2% 05-19 0% 05-21 -1% 05-22 -2% 05-23 -2%
唐僧团队是否是一个优秀的Scrum团队?
唐僧团队通常被认为是一个成功的团队,因为他们是不同风格的成员组合在一起,经过了磨合后,同心协力达成了最初的目标,封神成佛。一个成功的团队,未必是一个优秀的Scrum团队。如果站在Scrum的角度来检视唐僧团队,他们有哪些突出的待改进之处呢?1 不是学习型团队在整个团队组建以后,团队成员的技能没有发生变化,孙悟空仍然还是那些绝技,猪八戒沙僧也没有学到新技能。每次打完妖怪后,没有总结经验教训,如何更好、更快地降服妖怪,打完一次妖怪,团队的整体技能没有提升,说明该团队不是一个学习型团队!...
软件需求的12条最佳实践
笔者在咨询实践中总结了针对软件需求工程的12条最佳实践,罗列如下。所谓最佳并非严密的逻辑证明,而是经过大量的实践与观察依据经验确定的,智者见智,仁者见仁,有争议在所难免,仅供参考,能够对大家有所启发,足矣。1 成立甲乙双方参与的需求控制组项目的成功不单是乙方的成功,而是甲乙双方的成功,甲乙双方紧密配合,互相理解,互相合作才能成功,需要避免一方独大,一方具有绝对控制权的现象,所以成立甲乙双方参与的需求控制组是避免需求蔓延的有效手段。该组织具有对需求的决策权,对于每项需求的增删改都要平衡了进度、质量、投入后才
需求控制组的构成
在软件项目中常见如下的现象: 用户提出了需求变更,市场人员答应了,开发人员认为工作量太大,不好实现; 软件项目签订了合同,规定了价格,在后期的开发过程中,需求变更很多,变更的成本都是乙方承担,项目结束后发现项目做亏了; 用户提出了需求的变更,开发人员直接修改软件,没有通知相关人员; 用户张三提出了需求变更,开发人员修改了软件后,张三又认为不妥
加入社区微信群
与行业大咖零距离交流学习


PMO实践白皮书
白皮书上线
白皮书上线