案例一:客户需求文档评审
参与人员:1位主持人,1位作者,1位记录员,4位专家,1位咨询顾问旁观
开始时间:15:40 结束时间:17:15 会议工时 :6.3人时
会前准备累计工时:9人时 总工时:15.3人时
会议前发现的问题:25个 会中发现的问题:2个 合计问题:27个
会前评审效率:2.8个/人时 会中评审效率:0.3个/人时
评审文档的规模:13页 缺陷密度: 2.1个/页
在会议开始,主持人首先检查了各位专家的准备情况:
甲 花费了3个小时准备,发现18个问题;
乙 花费了2个小时准备,发现了18个问题
丙 花费了3个小时准备,发现了18个问题
丁 花费了1个小时准备,发现了10个问题
咨询顾问作为旁观者经历了评审会议的全过程,对该评审过程进行了如下点评:
1 在评审专家的分工中没有识别需求专家,只定义了2个设计、1个测试、1个用户。
2 专家在个人评审阶段描述发现时,注意:
(1)位置准确 (2)问题准确
3 在开评审会时,主持人需要注意控制会议的节奏:
(1)在同一个时间只有1个人发言
(2)不要讨论个人描述风格的偏好问题
(3)不在同一个问题上花费太多的时间
4 好现象:大家都能心平气和的讨论问题
5 注意客户需求的模板中存在的问题也要记录下来,并优化模板
6 有的专家很适合作为主持人
7 在本次评审中也存在“虫子窝”现象,即某个章节中缺陷比较多
案例二: 需求评审流程定义与推广
场景:
公司存在2个主要的研发部门,部门领导是业务专家,其中一个部门的研发的系统比较庞大,可能会有10多个子系统,每个子系统都有一个需求人员,可能每个子系统的需求人员并不熟悉其他子系统的需求。每次评审的文档量比较大,专家通常就是部门领导与公司领导,开发人员比较年轻,缺乏业务经验。
EPG成员及咨询顾问一起针对公司的实际讨论如何推广需求评审实践。
结论:
需求评审流程定义与推广的要点:
1 在组织级建立领域专家库,针对不同产品、不同类型的评审,识别出来自不同部门的专家。
2 在项目立项时确定参与项目评审的专家
3 在公司例会上,确定各部门本月需要配合参与的评审会,要承诺按时提供专家,确保专家的准备时间与出席时间
4 由质量部经理出任每次评审的主持人,如果有其他部门的领导或公司的老板参加,则仅以专家的身份参与
5 如果系统规模比较大,则首先评审系统的总体需求,此时,领导们可以参与。在评审每个子系统的需求时,领导不再参与。
6 每次评审确定参与的角色:设计、测试、QA、主持人等。
7 先开概况会议,由作者介绍被评审的材料,然后个人评审,记录每位专家发现的缺陷个数,并纳入考核,确保每位专家都真正做了个人评审,最后开记录会议,汇总缺陷。
8 主持人要制定评审计划,明确人员、角色、时间、流程的定义或裁剪、退出的准则等。
9 定义评审过程的度量元:规模、缺陷个数、效率、速率等。
10 流程建立后,在整个公司宣讲,尤其是领导们要熟悉评审的各项规定与要求
案例三:需求评审度量数据分析
某公司6次需求评审度量数据如下:
评审序号 缺陷密度(个数/页) 评审效率(个数/小时)
P1 0.56 0.75
P5 1.47 2.44
P8 1.23 1.79
P10 1.64 1.33
P11 0.33 0.59
P12 0.40 0.85
对缺陷密度进行分析,得到:
• 均值:0.936
• 标准差:0.522
• 离散系数:0.557692
• 离散系数太大,超过15%了,因此以均值的15%作为标准差计算基线:
– 均值:0.936
– 上控制限:1.357
– 下控制限:0.515
– 计量单位:个/页
对评审效率进行分析,得到:
• 均值:1.293
• 标准差:0.675
• 离散系数:0.522
• 离散系数太大,超过15%了,因此以均值的15%作为标准差计算基线:
– 均值:1.293
– 上控制限:1.875
– 下控制限:0.712
– 计量单位:个/人时
参与人员:1位主持人,1位作者,1位记录员,4位专家,1位咨询顾问旁观
开始时间:15:40 结束时间:17:15 会议工时 :6.3人时
会前准备累计工时:9人时 总工时:15.3人时
会议前发现的问题:25个 会中发现的问题:2个 合计问题:27个
会前评审效率:2.8个/人时 会中评审效率:0.3个/人时
评审文档的规模:13页 缺陷密度: 2.1个/页
在会议开始,主持人首先检查了各位专家的准备情况:
甲 花费了3个小时准备,发现18个问题;
乙 花费了2个小时准备,发现了18个问题
丙 花费了3个小时准备,发现了18个问题
丁 花费了1个小时准备,发现了10个问题
咨询顾问作为旁观者经历了评审会议的全过程,对该评审过程进行了如下点评:
1 在评审专家的分工中没有识别需求专家,只定义了2个设计、1个测试、1个用户。
2 专家在个人评审阶段描述发现时,注意:
(1)位置准确 (2)问题准确
3 在开评审会时,主持人需要注意控制会议的节奏:
(1)在同一个时间只有1个人发言
(2)不要讨论个人描述风格的偏好问题
(3)不在同一个问题上花费太多的时间
4 好现象:大家都能心平气和的讨论问题
5 注意客户需求的模板中存在的问题也要记录下来,并优化模板
6 有的专家很适合作为主持人
7 在本次评审中也存在“虫子窝”现象,即某个章节中缺陷比较多
案例二: 需求评审流程定义与推广
场景:
公司存在2个主要的研发部门,部门领导是业务专家,其中一个部门的研发的系统比较庞大,可能会有10多个子系统,每个子系统都有一个需求人员,可能每个子系统的需求人员并不熟悉其他子系统的需求。每次评审的文档量比较大,专家通常就是部门领导与公司领导,开发人员比较年轻,缺乏业务经验。
EPG成员及咨询顾问一起针对公司的实际讨论如何推广需求评审实践。
结论:
需求评审流程定义与推广的要点:
1 在组织级建立领域专家库,针对不同产品、不同类型的评审,识别出来自不同部门的专家。
2 在项目立项时确定参与项目评审的专家
3 在公司例会上,确定各部门本月需要配合参与的评审会,要承诺按时提供专家,确保专家的准备时间与出席时间
4 由质量部经理出任每次评审的主持人,如果有其他部门的领导或公司的老板参加,则仅以专家的身份参与
5 如果系统规模比较大,则首先评审系统的总体需求,此时,领导们可以参与。在评审每个子系统的需求时,领导不再参与。
6 每次评审确定参与的角色:设计、测试、QA、主持人等。
7 先开概况会议,由作者介绍被评审的材料,然后个人评审,记录每位专家发现的缺陷个数,并纳入考核,确保每位专家都真正做了个人评审,最后开记录会议,汇总缺陷。
8 主持人要制定评审计划,明确人员、角色、时间、流程的定义或裁剪、退出的准则等。
9 定义评审过程的度量元:规模、缺陷个数、效率、速率等。
10 流程建立后,在整个公司宣讲,尤其是领导们要熟悉评审的各项规定与要求
案例三:需求评审度量数据分析
某公司6次需求评审度量数据如下:
评审序号 缺陷密度(个数/页) 评审效率(个数/小时)
P1 0.56 0.75
P5 1.47 2.44
P8 1.23 1.79
P10 1.64 1.33
P11 0.33 0.59
P12 0.40 0.85
对缺陷密度进行分析,得到:
• 均值:0.936
• 标准差:0.522
• 离散系数:0.557692
• 离散系数太大,超过15%了,因此以均值的15%作为标准差计算基线:
– 均值:0.936
– 上控制限:1.357
– 下控制限:0.515
– 计量单位:个/页
对评审效率进行分析,得到:
• 均值:1.293
• 标准差:0.675
• 离散系数:0.522
• 离散系数太大,超过15%了,因此以均值的15%作为标准差计算基线:
– 均值:1.293
– 上控制限:1.875
– 下控制限:0.712
– 计量单位:个/人时