同行评审培训练习点评结果
发布于 2024-10-03


版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。


麦哲思科技任甲林
扫码关注公众号

扫码阅读
手机扫码阅读
同行评审培训摘要
在2008年3月3日举行的同行评审培训中,共有20人参与,19人参加了练习。培训包括了3小时的同行评审方法讲解,1小时的实践练习和45分钟的点评。参与者被分为三组,针对同一实际项目需求的一部分进行评审,该需求文档只有一页但质量较差。
三个小组的评审结果显示,第1组确认的bug最少,但效率最高;第2组确认的bug最多,但效率最低且工作量最大;第3组发现bug数和工作量均最少,显示评审质量不高。
度量数据分析点评:
- 第3组的准备阶段和会议中发现的缺陷数比例小,表明评审投入不够。
- 第2组参与人数过多,导致效率低下。
- 第1组个人评审充分,效果好。
- 第2组多发现的缺陷并不符合其投入的工作量。
- 第1组和第2组工作量的度量数据可能存在统计口径不一致。
- 个人评审的平均速率与发现缺陷数成反比。
- 个人评审阶段发现的BUG越多,评审效率越高。
小组总结的经验教训:
- 主持人与作者需对检查项有共同理解。
- 分析检查单中各检查项的命中率。
- 主持人应控制会议节奏,避免过多时间在一个问题上。
- 记录员需与评审员沟通保持一致。
- 细分评审员角色可提高效率。
- 模拟用户使用场景的方法效果良好。
- 保证度量数据的准确性。

麦哲思科技任甲林


麦哲思科技任甲林
扫码关注公众号

麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
425 篇文章
浏览 246.1K
麦哲思科技任甲林的其他文章
待人如待己
最近略有所感:希望别人如何待己,就应如何待别人。别人就是你的镜子,你是如何待别人的,别人就会如何待你。你若以诚待人,别人也会以诚待你;你若敌视别人,别人也会敌视你;你对别人不礼貌,别人也会对你不礼貌;你对别人充满爱心,别人也会对你充满爱心;“爱人者人恒爱之,敬人者人恒敬之。”“你敬我一尺,我敬你一丈。”应发自内心地与人为善。
如何学习设计模式?
1 先理解概念,再学习原则先理解OO的基本概念,比如:封装、继承、多态、组合/聚合、依赖等,理解各概念的内涵,弄清楚这些概念的具体实现方式及各实现方式的优缺点。2 先学习原则,再学习模式设计原则是蕴含在设计模式后最根本的思想,掌握了基本的设计原则可以做到不拘泥于某个具体的设计模式,可以更容易的理解设计模式,知道在何种情况下应该采用某种模式,可以自己创造合理的设计模式。设计原则可以参考的2本书籍是《
如果做好过程裁剪?
1 裁剪的含义: (1) 增加 (2) 删除 (3) 替换方法或格式 (4) 修改顺序 (5) 多选一 (6) 修改权限、级别2裁剪的对象: (1) 过程 (2) 活动 (3) 方法 (4) 度量元 (5) 质量目标 (6) 控制权限 (7) 评审方式 (8) 活动频率 (9) 生命周期模型 (10)参考的度量数据、基线(11)其他3裁剪的步骤 (1)确定项目类型
如何画业务流程图?
业务流程图是用来描述客户业务作业方式的有效手段,它可以清晰地客户业务流程中涉及的人员角色、业务活动、业务数据以及他们之间的关系,是用来澄清需求的有效手段。
软件研发过程客观体检指标
在给软件企业做差距分析时,经常听到大家说:“我们需求变更很频繁”,“我们项目拖期很严重,客户很不满意”,“我们开发人员太忙了”等等各种主观的说法,这些论断基本上是有通用性的,各个组织都存在,表面上看,软件组织的问题都是类似的。这些论断也是有争议性的,因为不同的人得出的结论可能是不同的,张三认为需求变更频繁,而李四可能认为就是正常的。因此,我们需要客观准确地刻画企业的现状、描述问题的原因。
加入社区微信群
与行业大咖零距离交流学习


PMO实践白皮书
白皮书上线
白皮书上线