例解:如何将规范的过程敏捷化?
发布于 2024-10-03
993
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
文章提出,许多企业在基于CMMI模型建立过程体系后感到过于繁琐,难以贯彻执行,因此提倡将过程体系敏捷化。敏捷化的目标是为了实际效果,而不仅是为了评估。
以CMMI中的DAR过程域为例,文章详细解释了如何将规范的过程敏捷化。首先,确认过程的根本目的是选择最优解决方案,减少返工量。然后,审视目的是否经济实惠,并确保过程原则为多识别候选方案,多人参与决策,以及全面客观评价方案。
敏捷化过程需要确定客户交付物,并将其简化表示为会议纪要中的决策结论和方案优缺点。此外,需要识别可以简化的活动,如选择决策准则和方法,同时保留必要的中间产品,并提出其最简单的表达方式。
为了弥补减少文档的影响,可以在组织级定义常用的决策步骤和方法,且在决策会议前讨论决策方法。简化过程的前提是参与者具有成功决策的经验。最后,为了及时发现过程输出的缺陷,需要在开发过程中实时评价决策的有效性,并在发现问题时团队内部重新评估。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
425 篇文章
浏览 571.1K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
人之初,性本善
古人很伟大,说了一句符合统计学原理的话。 如果以95%作为置信度,人刚生下来时,应该是有95%的概率是一个好人,5%的概率是个坏蛋。如果人之初,性本恶的话,你走在马路上,遇到100个人,会有95个人过来伤害你,这不是现实,因此人之初,性本善。 是一个好人,不代表好人不做坏事,只是好人做好事的概率大,做坏事的概率小,好人做坏事是小概率事件。 是一个坏人,不代表坏人不做好事,只是坏人做好事的概率小,坏
如何推广单元测试
在我咨询的客户中,软件企业对于单元测试的执行情况可以划分为4类: (1)不做单元测试 (2)组织级要求了开发人员做单元测试,但是开发人员在做单元测试时,测试用例仅覆盖了程序中的正常路径,基本上是一个函数只有一个单元测试用例 (3)组织级要求了每千行代码必须有多少个单元测试用例,一般是在50个/KLOC到100个/KLOC之间。 (4)要求语句覆盖与分支覆盖必须达到100%。其中(3)、(4
软件开发的质量红线
质量红线是我的一个客户提出的概念,即质量管理的底线、最低要求、最低标准,无论在什么情况下,项目都不能违背这个底线,比如项目组在进行多快好省四个要素平衡时,无论如何平衡,都不能违背质量的最低要求。我认为这个名词很直观形象,因此借用一下。 在定义质量红线时应该从质量的投入与质量的产出两个方面进行定义。 质量的投入如: 评审投入的工作量;
测试过程分析的15个常用度量元
测试过程分析的15个常用度量元序号优先级度量对象度量元度量单位采集周期采集/计算方法分析方法作用11用户发现的各类型的缺陷缺陷个数个交付阶段维护阶段直接统计80-20分析:对缺陷类型按缺陷个数排序,找出客户发现的最多的20%的缺陷类型分析客户的关注点是什么?为什么客户能发现这些类型的缺陷,为什么我们
软件项目量化管理目标举例
1 产出类目标 1.1总体目标进度:项目工期偏差率介于+-15%之间;质量:项目的缺陷逃逸率不高于5%; 项目交付的缺陷密度不高于1个bugs/KLOC;规模:需求变更率不超过15%;成本:工作量偏差率不超过+-30%; 每人月实际投入项目的时间不少于上班时间的50%;项目返工工作量不高于20%;效率:全生命周期生产率不小于1KLOC/MM;其他:人员变更率不超过20%;
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线