扫码阅读
手机扫码阅读
我说CMMI2.0 之监督与控制
565 2023-07-12
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
查看原文:我说CMMI2.0 之监督与控制
文章来源:
麦哲思科技任甲林
扫码关注公众号
监督与控制PA摘要
监督与控制PA(MC)是对照计划监督与管理计划的执行情况。以下是实践列表及其通俗解释的摘要。
实践列表摘要
- MC 1.1 - 记录任务完成情况,包括是否完成、完成百分比以及是否存在延期。
- MC 1.2 - 识别并解决问题,包括问题的跟踪与关闭。
- MC 2.1 - 对照规模、工作量、进度、资源、知识技能和预算的估计结果跟踪实际结果,确保定量估算与定量对比跟踪。
- MC 2.2 - 跟踪已识别的干系人的参与和承诺,检查任务完成情况和是否满足技术与管理要求。
- MC 2.3 - 监督向运维和支持的移交,确保解决方案正确移交并监督执行情况。
- MC 2.4 - 当实际结果与计划的结果有显著偏离时,采取纠正措施并管理至问题解决。
- MC 3.1 - 使用项目计划和项目过程管理项目,确保项目计划作为管理的参照物。
- MC 3.2 - 管理关键依赖和活动,确保项目延续性。
- MC 3.3 - 监督工作环境以识别问题,维持项目组的环境标准。
- MC 3.4 - 和受影响的干系人一起管理和解决问题,实现问题的最终解决。
业内案例摘要
不同公司可能会有不同的跟踪策略,以下是一些常见的跟踪手段及其关注的跟踪对象:
跟踪手段\跟踪对象 | 任务完成 | 工期 | 工作量 | 质量 | 风险 | 问题解决 | 环境 | 目标 |
---|---|---|---|---|---|---|---|---|
每日站立会议 | Y | Y | Y | |||||
燃尽图 | Y | Y | Y | Y | ||||
周例会 | Y | Y | Y | Y | Y | Y | ||
里程碑评审 | Y | Y | Y | Y | Y | Y | Y | Y |
月度例会 | Y | Y | Y | Y | Y | Y | Y | Y |
项目总结会议 | Y | Y | Y | Y | Y | Y | Y | Y |
专项问题评审 | Y | Y |
想要了解更多内容?
查看原文:我说CMMI2.0 之监督与控制
文章来源:
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
425 篇文章
浏览 134.6K
麦哲思科技任甲林的其他文章
我说CMM2.0之:风险与机会管理
风险与机会管理,简写为RSK,在以往的CMMI版本中都是描述为风险管理,在2.0中增加了机会管理。风险是意料之外的坏事,机会是意料之外的好事,风险是惊吓,机会是惊喜。我们要抓住机会,规避风险,趋利避害。风险与机会都不是一定发生的,发生的概率都是大于0小于1的。 基本理念1 风险与机会是事先的,不是事后的,事后的是事件管理,问题管理。2 要尽早报告风险,处理风险。3 风险与机会在...
维护项目的管理策略案例
维护类项目的定义: (1)在已交付的软件基础上增加少量功能; (2)对已交付的软件进行局部的需求变更; (3)修改已交付软件的bug;维护类项目的特点: (1)工期短,客户要求相应快; (2)对已有的软件进行局部修改,投入的人力少; (3)变更容易对已有的功能造成影响,容易注入新的bug; (4)需求沟通、设计方案的确定、测试的
建立组织级过程性能基线的注意事项
过程性能基线的建立方法有箱线图法、控制图法、置信区间法等等,在实际中,还要数据分析者的经验进行分析,以下举例说明在建立组织级过程性能基线时的注意事项:1 注意识别数据分层的现象 数据分层,即样本点存在明显的局部聚集现象,聚集在不同值范围附近的样本点可能是属于不同类型
度量体系建立与COSMIC方法应用36问
Q1:度量体系建设的难点有哪些?后来是采取哪些策略解决的?A1:难点:采集哪些数据是有用的?有了数据如何抓结论出来。Q2:故障解决闭环率,类似这种KPI考核指标,有什么好的方法可以高效推进闭环呢?A2: 分析故障解决的时间分布,看看哪个环节耗时最长,是否针对这个环节有改进措施。短期见效的措施最受欢迎。Q3:度量规模给传统公司带来了哪些价值啊?A3:有了规模才可以比较生产率和质量。从软件开发方的角度,通过生产率的度量,判断当前的生产率究竟是高还是低,比较不同项目组,不同部门..
快速学习COSMIC方法之四:早期快速估算功能规模的方法
在介绍详细的COSMIC方法之前,我们先介绍一下在项目早期,在需求没有详细到可测试的程度时,如何估算软件的规模。实际上很多公司为了减少度量的工作量,往往采用近似的估算方法进行确定项目的预算。 进行快速估算的原理为:通过分析历史的粗颗粒度需求与实际规模之间的相关关系,找到二者之间的换算关系,然后对于新的粗颗粒度需求参考历史的换算关系快速地得到近似规模。这里的粗颗粒度需求的规模可以是功能处理个数
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设
白皮书上线