案例:缺陷个数与返工工作量强相关
发布于 2024-10-04
3104
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
通过对某公司21个项目的缺陷个数与返工工作量的数据进行分析,建立了缺陷数与缺陷修复工时之间的回归方程。该回归方程为:缺陷修复工时=4.0371+6.4217缺陷数,揭示了两个重要的信息:
- 修复缺陷的固定成本为4.0371个工时,表明无论项目大小,都会有一个基本的工时消耗。
- 每增加一个缺陷,返工工作量将增加6.4217个工时,这反映了变动成本的信息。
为了降低返工成本,公司可以采取以下两种策略:
- 减少缺陷发生的数量,从而直接减少返工工作量。
- 提高缺陷修复效率,以降低返工的变动成本,即减小回归方程中的斜率值。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 1272.5K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
需求评审的案例分析
案例一:客户需求文档评审 参与人员:1位主持人,1位作者,1位记录员,4位专家,1位咨询顾问旁观 开始时间:15:40 结束时间:17:15 会议工时 :6.3人时 会前准备累计工时:9人时 总工时:15.3人时 会议前发现的问题:25个 会中发现的问题:2个 合计问题:27个 会前评审效率:2.8个/人时 会中评审效率:0.3个/人时 评审文档的规模:13页 缺陷
需求控制组的构成
在软件项目中常见如下的现象: 用户提出了需求变更,市场人员答应了,开发人员认为工作量太大,不好实现; 软件项目签订了合同,规定了价格,在后期的开发过程中,需求变更很多,变更的成本都是乙方承担,项目结束后发现项目做亏了; 用户提出了需求的变更,开发人员直接修改软件,没有通知相关人员; 用户张三提出了需求变更,开发人员修改了软件后,张三又认为不妥
开发过程中的八种确认方法
确认是确保做了正确的事情,方向不偏。确认可以在项目前期做,也可以在项目后期做,提倡持续确认、质量左移。在前期主要是检测需求的质量,在后期是检测完成的系统是否真的是客户所需。本文概要归纳了开发过程中常见的八种确认手段。
如何选择度量元
选择度量元的5个原则 在设计度量体系时,要针对度量目标选择合适的度量元,同一个度量目标可以有多个度量元,究竟要如何选择合适的度量元呢,我们可以参考如下的5个原则进行选择: 原则1:对度量目标的表达能力,即度量元是否准确刻画了度量目标以及要解决的问题?比如,想要监督项目的进展,我们有如下三个选择: 1) 需求完成的百分比; 2) 活动完成的百分比; 3) 已完成活动的计划工作量/所有活动...
关于需求跟踪矩阵的6个问题
1 需求跟踪矩阵(RTM)有什么作用? (1) 在需求变更、设计变更、代码变更、测试用例变更时,需求跟踪矩阵是目前经过实践检验的进行变更波及范围影响分析的最有效的工具,如果不借助RTM,则发生上述变更时,往往会遗漏某些连锁变化。 (2) RTM也是验证需求是否得到了实现的有效工具,借助RTM,可以跟踪每个需求的状态:是否设计了,是否实现了,是否测试了。 2 需求跟踪矩阵分为哪几类? (1) 纵向跟
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线