例解:如何分析同行评审的度量数据?
发布于 2024-10-03
1128
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
同行评审度量数据摘要
在同行评审过程中,通常会收集以下度量数据:
- 评审文档或代码的规模,使用页、功能点或行作为度量单位。
- 个人评审和评审会议所花费的时间,以小时计。
- 个人评审和评审会议发现的缺陷数量,以个数计。
- 缺陷总数,即评审会议确定的缺陷数量,已排除重复或非缺陷项。
- 个人评审和评审会议的工作量,以人时计。
- 评审的总工作量,为个人评审与会议工作量之和。
- 个人评审速率,即评审规模除以工作量。
- 评审总体效率,为发现的缺陷总数除以总工作量。
- 缺陷密度,为发现的缺陷数量除以评审规模。
对于如何利用这些数据,以下是一些案例分析:
- 若个人评审发现的缺陷少于会议上发现的,表明个人投入不足,可能需要重新评审。
- 设计审查时个人评审的时间不足,表明需要更多时间进行审查。
- 代码走查速率过快,可能影响评审效果。
- 如部分专家未进行个人评审,建议延迟评审或改变评审方式。
- 若个别专家的评审速率异常高,应该考虑调整其角色。
- 缺陷密度超出组织退出准则,需重新审查和原因分析。
- 评审效率超出组织基线,需要分析是否由于审查不够仔细或文档太简单。
- 会议周期过长,建议拆分为多次评审。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
440 篇文章
浏览 765.3K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
软件研发管理三部曲:以道御术、术以载道与数以达理
软件研发管理的三部曲:《以道御术》系统解释了软件研发管理的what to do。《术以载道》讲解了软件研发管理的Howto do。《数以达理》系统解释了量化研发管理的how to do。
过程改进的关注点之测试过程
总结了一下在咨询过程中看到的测试过程的常见问题,梳理出来进行测试过程改进的关注点
职业程序员培养之道
作者:粘新育 任甲林 来源:希赛网 http://www.csai.cn 2004年06月28日 软件开发是以人为核心的过程,对人的依赖性远高于传统的硬件生产企业,为了保持开发能力的稳定性,一方面需要定义软件过程,以过程为枢纽将人、技术、工具衔接起来,另一方面也要加强人才的培养,使人的工作能力能够稳定、提高人员的自治性。随着社会需求的膨胀,对程序员的需求量、对熟练的程序员的需求量在剧增,然而对程
度量数据分析的3个层次
很多企业在实施CMMI 的MA过程域时,积累了大量的数据,但是不知道如何分析,没有充分发挥出这些数据的作用,花费了大量的人力收集来的数据没有给决策提供应有的帮助,很是可惜。究其根源,是不了解数据分析的方法。在咨询过程中,我总结了进行数据分析的3个层次: 1 简单观察分析 通过对数据进行整理(如排序、分类等),绘制成各种图形,通过这些图形观察出直观的结论,可以绘制的图形如:饼图、条形图、直方图、折线
规模估算的敏捷方法:策划扑克法
策划扑克是估算软件规模的一种敏捷方法。该方法的规模计量单位是故事点(story points),故事点只是一个计量单位的名称而已,你也可以给他命名为其他名字。故事点其实不仅仅是对规模的度量,也包括了对需求复杂度等其他因素的度量。故事点并非业界统一的一个度量单位,不象度量长度的单位:米,大家都知道1米有多长,你说的1米和他说的1米是等长的。故事点仅对本项目具有近似相等的规模,不同的项目所定义的故事点
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线