我说CMM2.0之:风险与机会管理
发布于 2024-10-01
2200
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
摘要
风险与机会管理(RSK)在CMMI 2.0版本中已经不仅局限于风险管理,而是增加了机会管理。风险指的是未预料到的负面事件,而机会则是未预料到的正面事件。二者都有一定的发生概率,但都不是确定性事件。
基本理念
风险与机会管理要求在事情发生前就进行管理,而不是事后处理。需要尽早识别和处理风险,并在项目执行过程中持续关注风险与机会。在管理上要权衡成本与收益,不是所有风险或机会都需要预先采取措施。
实践列表
- 识别和记录风险或机会,并持续更新。
- 分析所识别的风险或机会。
- 监控风险或机会并与相关干系人沟通状态。
- 识别并使用风险或机会分类。
- 定义和使用风险或机会分析及处理的参数。
- 制定并更新风险管理策略。
- 制定并更新风险或机会管理计划。
- 通过实施计划中的风险或机会管理活动来管理它们。
通俗解释
风险或机会的识别、记录不要求立即采取应对措施。分析风险或机会时,应考虑严重性、可能性、紧迫性三个维度,并根据优先级制定策略。监控风险或机会以及与干系人沟通是一个周期性的过程。风险或机会的分类有助于合并相似风险的应对措施以节约成本。
风险或机会的分析和解决涉及到三个参数的定义,包括严重性、可能性和紧迫性的具体划分。管理策略涵盖责任分配、管理时机、方法、参数定义等。管理计划应包括缓解措施、应急措施以及机会的创建和应对计划。最后,风险或机会的管理要根据计划实施相应的措施来执行。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 1225.7K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
如何拆分业务需求为系统功能需求?
(按业务事件、操作意图、用户角色、数据生命周期、规则分支切分)进行拆分,我们可以将模糊的业务目标转化为清晰、可执行、可测试的开发任务。在软件开发的整个生命周期中,需求分析是基石,而将模糊、宏观的业务需求,精准地拆解为清晰、可执行的系统功能需求基本单元,则是这一基石中最关键的一步。:一个功能单元执行完毕后,系统应达到一个明确、一致的稳定状态,而不是处于一个中间的、不确定的状态。遵循 VISTA 原则,可以确保我们拆分出的功能单元是清晰、独立且可管理的,为后续的开发、测试和维护工作奠定坚实的基础。
白话SCRUM 之四:燃尽图
Burn down chart翻译为燃尽图或燃烧图,很形象,是Scrum中展示项目进展的一个指示器。我一直认为用户故事、每日站立会议、燃尽图、sprint review、sprint retrospective真是越琢磨越有味道的好东西,也因此很喜欢scrum这种方法,这些实践简单有效、经典! 燃尽图的样例如下: 横坐标为工作日期,纵坐标估计剩余的工作量,每个点代表了在那一天估计剩
需求交付周期的分析
需求交付周期的分析
再谈如何推广单元测试
以前曾经写了一篇博文谈如何推广单元测试,最近有朋友问我如下的问题,因此便又写了本文,阅读时请综合原来的博文。问题: 有开发人员认为进行单元测试会花费大量时间来编写测试用例,因此他们做单元测试的意愿比较低,请问有何好的建议进行单元测试的改进?解答: 1 首先应该明确单元的含义。单元在面向对象的程序中指的是一个类,在结构化的方法中指的是一个函数。 2 其次应该明确单元测试的方法。单元测试的常用方
AI编程的三大痛点及其工作模式
文章浏览阅读436次,点赞7次,收藏7次。AI结对编程面临三大核心痛点:遗忘前期约定导致返工(痛点一)、擅自脑补需求细节造成偏差(痛点二)、使用陈旧API引发兼容问题(痛点三)。本文提出20种"懒人友好"工作模式精准应对:通过"回归校验+约束内化"防止遗忘,采用"思路先行+逆向评审"避免脑补,运用"伪代码翻译+红绿蓝测试"规避版本问题。特别推荐三大万能模式(约束内化、回归校验、红绿蓝)可同时缓解所有痛点。这些即插即用的方法无需增加工作量,能显著减少AI编程中的返工成本,
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线