扫码阅读
手机扫码阅读
例解:如何分析同行评审的度量数据?
119 2024-10-03
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
查看原文:例解:如何分析同行评审的度量数据?
文章来源:
麦哲思科技任甲林
扫码关注公众号
同行评审度量数据摘要
在同行评审过程中,通常会收集以下度量数据:
- 评审文档或代码的规模,使用页、功能点或行作为度量单位。
- 个人评审和评审会议所花费的时间,以小时计。
- 个人评审和评审会议发现的缺陷数量,以个数计。
- 缺陷总数,即评审会议确定的缺陷数量,已排除重复或非缺陷项。
- 个人评审和评审会议的工作量,以人时计。
- 评审的总工作量,为个人评审与会议工作量之和。
- 个人评审速率,即评审规模除以工作量。
- 评审总体效率,为发现的缺陷总数除以总工作量。
- 缺陷密度,为发现的缺陷数量除以评审规模。
对于如何利用这些数据,以下是一些案例分析:
- 若个人评审发现的缺陷少于会议上发现的,表明个人投入不足,可能需要重新评审。
- 设计审查时个人评审的时间不足,表明需要更多时间进行审查。
- 代码走查速率过快,可能影响评审效果。
- 如部分专家未进行个人评审,建议延迟评审或改变评审方式。
- 若个别专家的评审速率异常高,应该考虑调整其角色。
- 缺陷密度超出组织退出准则,需重新审查和原因分析。
- 评审效率超出组织基线,需要分析是否由于审查不够仔细或文档太简单。
- 会议周期过长,建议拆分为多次评审。
想要了解更多内容?
查看原文:例解:如何分析同行评审的度量数据?
文章来源:
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
425 篇文章
浏览 105.3K
麦哲思科技任甲林的其他文章
需求与设计的界线
需求与设计的区别究竟是什么? 教科书上的经典答案是:需求关注系统“做什么”,设计关注“如何做”,其实这是一个很模糊的说法。无论是在结构化方法中还是在面向对象的方法中,需求分析的结果既包括了“做什么”也部分包括了“如何做”,只不过描述“如何做”时抽象的层次比较高或者描述了某个局部需求的“如何做”。客户在提出系统需求时,可能对“如何做”提出一些约束条件,比如客户要求必须采用三层结构,必须采用某个中间件
项目回顾案例
某公司从2015年6月下旬开始启动了一个敏捷开发的项目,截止到8月中旬结束,投入的开发人员、测试人员、管理人员达到60多人,2015年8月31日,由咨询顾问作为主持人带领该团队的10多名核心人员,对整个项目进行了系统回顾总结,整个回顾总结的过程如下: 1 咨询顾问花了1小时的时间,讲解了进行项目回顾的方法。强调了回顾的目的、方法、步骤、注意事项等,给出了一些公司的总结样例。对本次总结的会议制定
敏捷的过程改进方法:从经验教训中学习
每次去客户现场做差距分析或者运行检查,总是习惯于找他们的缺点,但是每次也总能从客户那里发现他们的优点,时间久了,慢慢地对缺陷麻木了,审丑疲劳了,只有发现他们的优点时,我才会精神一振,心情愉快。 今年1-2月份期间我去给一个客户做运行检查,整理完发现报告后,我查阅了那6个项目组的阶段总结报告与项目总结报告中的经验教训部分,我发现的60%的缺陷他们自己也感觉到了,只是没有人去提取、去系统的归纳整理、
成为一个好员工的七个忠告
如何成为一个好员工呢?请看以下七个忠告。
软件企业以人为本的16项措施
以人为本不能停留在口头上,要落实到具体的实施上,以下是我的实践或是我在软件企业看到的实践: (1) 重视现有的员工胜过去搜索外面的新人 (2)鼓励员工在职深造,学成归来的要重用 (3)招高水平的员工进来 (4)稳定的高于本地域行业平均水平的收入,使其没有后顾之忧,专心事业 (5)为每一个员工进行职业路线的规划 (6) 通过股权等激励措施鼓励员工长期在企业内工作 (7)用人所长,不勉强员工做不乐意做
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设
白皮书上线