缺陷清除率的简单分析
发布于 2024-10-02
883
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
某项目的缺陷清除率分析摘要
在一个迭代周期内,对某项目的缺陷注入与发现数据进行了采集。缺陷的注入分为三个活动:需求分析、设计与编码、测试;而缺陷的发现则涵盖了四个活动:Sprint planning、设计与编码、代码评审与测试。统计数据表明,在一个月内共计发现了42个缺陷。
分析这些数据发现,缺陷清除率在不同活动中表现不同。具体来看,缺陷清除率在Sprint planning、设计与编码、代码评审三个活动中呈逐渐升高趋势,分别为33.3%、62.5%和96.8%。而在测试环节,缺陷清除率达到了100%。
重要的观察结果包括:
- 代码评审是发现缺陷最有效的手段。
- 需求分析阶段注入的缺陷在Sprint planning阶段发现较少,指出了需求沟通和讨论的不足。
- 设计与编码活动中的缺陷逃逸率较高,暗示需加强这一阶段的需求沟通和讨论。
- 对于设计与编码阶段未度量或未记录的编码缺陷,提出了质疑。
该统计表没有包含产品发布后的度量数据,仅限于交付前的数据。由于缺乏测试交付后的缺陷度量,测试阶段的缺陷清除率数据可能不具备参考价值。最后,如果采取改进措施后各个活动的缺陷清除率显著提升,则可视为过程质量得到了提高。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
425 篇文章
浏览 642.9K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
白话SCRUM 之四:燃尽图
Burn down chart翻译为燃尽图或燃烧图,很形象,是Scrum中展示项目进展的一个指示器。我一直认为用户故事、每日站立会议、燃尽图、sprint review、sprint retrospective真是越琢磨越有味道的好东西,也因此很喜欢scrum这种方法,这些实践简单有效、经典! 燃尽图的样例如下: 横坐标为工作日期,纵坐标估计剩余的工作量,每个点代表了在那一天估计剩
如何比较两种估算方法的准确性?
有公司在做软件规模估算时,采用了经验法估计了代码行,又设置了难度系数,重用率,重用规模系数三个调整参数。如果初始估计规模为1KLOC,难度系数为1.1,重用率为20%,重用规模系数为50%,则调整后的规模为:1*1.1*(1-20%)+1*20%*50%=0.88+0.1=0.98KLOC。我看到该估算方法后认为有些复杂,而且不好理解,有可能是做了无用功了,所以我想通过数据进行检验看看调整后的规模是否比初始的规模估计更准确,如果不如初始的规模估计更准确,则可以放弃三个调整系数。该公司A部门有11个历史项
流程管理的基本理念
澄清一下关于流程的基本概念与理念。
经验管理与量化管理
经验管理是依赖于管理者的经验判断,选择、实施各种措施以达成管理目标的管理方式。管理者的经验有丰富与匮乏的区别,经验也有其适用的范围,有时正确,有时又可能错误。正如我们去看中医大夫,有的大夫经验丰富,很容易就能对症下药,对症后见效很快,但是有时也看不准,如果不对症,则吃了3天后可以进行调整,如果调整仍然不到位,说明经验失效了,这个病不是这个大夫所能应对的。有的大夫经验不够,难以对症下药,下药后见效慢或者无效。中医看病也有其一套推理的规则,这套规则可以称为经验法则、启发式规则或统计推断,从A推理出
如何确定测试的重点?
测试投入不足是大多数项目都面临的棘手问题。在此前提下,如何最大限度的提升软件的可靠性呢?本文给出了一个简单框架,帮助组织与项目组定义自己的测试策略、测试重点。
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线