软件质量管理-04-估算、计划和跟踪

本文主要内容来自 SpriCoder 的博客，更换了更清晰的图片并根据新的课程设计做了补充和修正。

估算

【2013】【2015A】【2018Fall】关于估算

1. 估算目的是给各类计划提供决策依据
2. 估算对象（规模、时间和日程）
3. 估算的常见困惑
   1. 项目交付日期、团队组成等都确定了，估算的意义在哪里？
   2. 哪种估算方法好？
   3. 哪个估算结果更好（靠谱）？
   4. 究竟该如何做好估算？

估算练习-1

1. 计算一组实数的均值和标准差，用 JAVA 程序读取文本文件中的一组实数，然后计算其均值和标准差。
2. 尝试估算代码行和所需开发过程（分钟）
   1. 代码行？30 行
   2. 开发实践？5 分钟

关于估算的一些事实

1. 估算是客观猜测
2. 估算能力很难提升
3. 没有任何人知道准确的数字究竟是什么
4. 多项实证研究表明，是否使用估算模型（例如，COCOMO）并没有显著差异

那究竟该如何做软件估算？

部分相关知识点回顾

1. 软件开发是知识工作——可重复性不高
2. 软件工程师是知识工作者，需要被激励
3. 激励理论的两大因素：
   1. V（价值）：完成这个项目所获得的收益（往往是一定的，个人难以改变）
   2. E（期望/把握）：内心完成这件事情的把握（和个人相关，主观把握）

PSP 和 PROBE

1. 规模度量/估算的困境
2. 以 LOC VS. FP 为例
   1. 精确度量方式往往不便于早期规划/估算；
   2. 有助于早期规划/估算的度量往往难以产生精确度量结果；
3. PROBE（PROxy Based Estimation）的作用：精确度量和早期规划之间的桥梁

PROBE 原理示例

估算一栋房屋的建造成本，大部分人没有概念。然而，在早期规划中，会有如下认识/需求

序号	用途	相对大小及数量
1	厨房	1 个中等大小
2	卧室	1 个大卧室；2 个小卧室
3	卫生间	1 个中等大小；1 个小型
4	书房	1 个中等大小
5	客厅	1 个大客厅

相对大小矩阵

PROBE 估算流程

概要设计

1. 估算的第一步是做出一个概要设计：
   1. 概要设计不是真实设计
   2. 与已有产品/组件 相关联
   3. 定义能够产生期望功能的产品元素
   4. 估算你计划构造之物的规模
2. 对于大多数的项目，概要设计都应相对较快地完成：例如，1000LOC 以内程序，试着将概要设计时间限制在 10 到 20 分钟之内
3. 为了做出概要设计，需要确定产品功能，以及产生这些功能所需的程序组件/模块：“如果我有以下这些部件，我可以构造这个产品。”
4. 然后，将这些程序组件/模块与你以前写的程序相比较，估算它们的规模
5. 最后，将程序组件/模块估算综合给出总规模

如果你对产品的理解还不足以产出一个概要设计，那么你所知道的还不足以做出一个计划

估算练习-2

计算一组实数的均值和标准差，用 JAVA 程序读取文本文件中的一组实数，然后计算其均值和标准差

试完成概要设计之后，估算代码行和所需开发时间（分钟）

1. 代码行
2. 开发时间

整合多个估算结果

整合一个开发人员做的多个估算：

1. 累积各个部分的估算
2. 进行一次线性回归计算
3. 计算一个预测区间

多个开发人员可以整合独立进行的估算，通过以下方式：

1. 进行单独的线性回归预测
2. 将计划的规模或者时间相加
3. 将个人范围的平方相加，再对其计算平方根获得预测区间

估算误差：示例

1. 对于一项估算精度为 \(\pm\) 50%的 1000 小时的工作，估算范围就是从 500 到 1500 小时。
2. 如果估算被分成独立的 25 个部件，每个存在 50%的误差，那么
   1. 总时间会和前面一样是 1000 小时
   2. 估算范围会是从 900 到 1100 小时
3. 当估算多个部件时，总的误差会比各个部件误差的总和要小。
   1. 误差趋于抵消了
   2. 假设没有共同的偏差
4. 估算要点之一：尽可能划分详细一些

SCRUM 中的 Story point

度量实现一个故事（Story）需要付出的工作量

1. 抽象的：混合了对于开发特性（feature）所要付出的努力、开发复杂度、个中风险以及类似东西
2. 相对的：设定标准之后，考虑其他特性（feature）与标准之间的相对大小关系
   1. Fibonacci: 0, 1, 1, 2, 3, 5, 8, 13, 21,34, 55, 89
   2. 拆分
3. 估算要点之二：建立对结果的信心
4. 估算要点之三：依赖数据

关于估算方法的反思

估算的目标：规模估算 VS. 时间估算——估算结果重要吗？估算要点之四：估算要的是过程，而非结果；估算的过程是相关干系人达成一致共识的过程

怎么做估算：

1. 达成共识
2. 建立信心
   1. 足够详细
   2. 依赖数据
   3. 最好的猜测（注意检验猜测所依据的假设）

思考题：PROBE 方法如何实现上述估算要点？

相对大小矩阵（C++语言）

线性回归调整规模估算

1. 如果线性相关，那么就可以使用线性回归。上面的式子可以计算出 plan size。
2. 这个线不是 45 度，是受到估算误差和方法外代码的数量共同影响。

线性回归调整时间估算

1. 该方法没有使用生产效率进行计算，为什么在 PROBE 中不使用生产效率？
   1. 这样子使用好不好？因为 Plan Size 是在一个范围内波动，生产效率也在一个范围内波动，如果将生产效率作为分母，那么可能会导致更大的误差，也就违背了误差的出发点。
   2. 为什么不是用 plan size / 生产效率 得到 plan time

2. 估算能力的衡量：
   1. 越接近于回归线，估算能力越强。
   2. 估算能力的强弱看的是多稳定，而不是多接近具体的实际情况。

【2022Fall】估算要点

• 估算要点之一：尽可能划分详细一些
• 估算要点之二：建立对结果的信心
• 估算要点之三：依赖数据
• 估算要点之四：估算要的是过程，而非结果；估算的过程是相关干系人达成一致共识的过程

预测区间

置信度越高，置信区间越大。

历史数据的获取——度量

关于度量的争议：度量体现着决策者对试图要实现的目标的关切程度

GQM 和 GQM+度量体系构建：GQM 是对应三个部分

PSP 基本度项：

1. 规模
2. 时间
3. 缺陷
4. 日程（TSP）

用户和高层关心的问题：什么时候完成、质量怎么样、成本怎么样

PSP 时间度量（时间日志）

日志内容	注释
序号	该条记录的序号；
所属阶段	该条记录所属的 PSP 阶段，如策划、设计、编码、编译、单元测试、总结等；
开始时间	该条记录的开始时间，精确到分钟；
结束时间	该条记录的结束时间，精确到分钟；
中断时间	该条记录的计时过程中，需要中断的时间，精确到分钟，典型的中断如电话等；
净时间	结束时间-开始时间-中断时间，用以表示某个阶段任务的纯工作时间；
备注信息	如果有中断事件，往往需要在备注信息中简单记录，用以帮助记录者了解时间被消耗的原因；

时间日志示例

PSP 缺陷度量（缺陷日志）

历史数据的处理

某人的历史数据

简单方法

1. 基本思想是:
   1. 将每个方法的代码行数进行排序
   2. 选择最小值作为 VS；
   3. 选择最大值作为 VL；
   4. 选择中值作为 M；
   5. 选择 VS 与 M 的均值作为 S；
   6. 选择 VL 与 M 的均值作为 L。
2. 计算结果：VS = 9.333，VL = 32，M = 12 或者 13，S = 11.2，L = 22.5。

正态分布法

1. 使用正态分布法的计算方法如下：
   1. 选择所有数据的均值作为 M，计算所有数据的标准差 σ。
   2. 那么 S = M-σ ，VS = M-2σ ，L = M+σ ，VL=M+2σ
2. 计算结果：
   1. 在上述例子中，VS=-1.67，S=7.68，M=17.04，L=26.39，VL=35.75。

对数正态分布

1. 大部分人习惯写很多规模很小的程序，少量规模较大的程序
2. 此外，程序的规模不可能出现负数
3. 用 e 作为自然对数，如何进行处理？
4. 计算方法：
   1. 以 e 为底计算所有数据的自然对数；
   2. 计算取对数之后的值的均值作为 M，计算相应标准差 σ。
   3. 那么 S=M-σ，VS=M-2σ，L=M+σ，VL=M+2σ 。
   4. 取反对数；
5. 计算结果：
   1. VS = 5.55，S =9.19，M = 15.22，L = 25.21，VL = 41.75。
6. 长期使用相对矩阵会稳定

三种方法对比

1. 简单方法：计算简单，但是，不稳定
2. 正态分布法：相对稳定，在历史数据基本符合正态分布的情况下，可以给出非常好的相对大小矩阵
3. 对数正态分布法：更加符合人们对于程序的规模的直观感觉

相关性

1. PROBE 方法依赖历史数据，但是实际历史数据有可能
   1. 历史数据少于 3 个数据点；
   2. 有足够的历史数据，但是数据的质量不高
2. 相关性描述的是两组变化的数据之间相互关联的程度;
3. 一般情况下，为确保估算质量，对于历史数据的相关性要求 r≥0.7。

4. 显著性
   1. 它描述的是上述两组数据的相关关系出现的偶然性
   2. 因此，显著性越小越好。软件工程很多场合下要求显著性 s≤0.05（即所谓 p 值）

PROBE 估算规模

1. 使用一次 D 方法，就可以使用 C 方法
2. 使用三次 D 方法，就可以使用 B 方法

极端数据

1. PROBE A 方法和 B 方法的时候，对于数据的相关性有要求。
2. 然而很多时候，历史数据中的一些极端数据会造成相关性的“假象”。

r=0.26	r = 0.91

计划和跟踪

工作分解结构（Work Breakdown Structure，WBS）

1. WBS 定义：
   1. WBS 作用
   2. 范围基线
   3. 提供整体观
   4. 不遗漏可交付物
   5. 明确各个角色的责任
   6. 工作包定义
   7. 估算和计划的基础
   8. 理解工作，分析风险
2. WBS 示例：

创建 WBS 方法

1. 识别和分析可交付成果及相关工作；
2. 确定工作分解结构的结构与编排方法；
3. 自上而下逐层细化分解；
4. 为工作分解结构组成部分制定和分配标志编码；
5. 核实工作分解的程度是必要且充分的。

好的 WBS 检查标准

1. 最底层要素不能重复，即任何一个工作包应该在 WBS 中的一个地方且只应该在 WBS 中的一个地方出现。
2. 所有要素必须清晰完整定义，即相应的数据词典必须完整定义。
3. 最底层要素必须有定义清晰的责任人，可以支持成本估算和进度安排。
4. 最底层的要素是实现目标的成分必要条件，即项目的工作范围得到完整体现。

范围管理

1. 包括确保项目做且只做成功完成项目所需的全部工作的各过程；
2. WBS 为范围管理提供了基准；
   1. 收集需求
   2. 定义范围
   3. 创建 WBS
   4. 核实范围
   5. 控制范围变更

开发策略与计划

开发策略是在产品组件需求基础之上，明确每个产品组件的获得方式与顺序，从而在项目团队内部建立起大家都理解的产品开发策略。

注意事项：

1. WBS 的使用
2. 产品组件开发顺序的考虑
3. 产品组件获得方式的考虑

过程架构-生命周期模型

通用计划框架

1. 上述框架中，那些步骤必须人为的干预
   1. 定义需求
   2. 概要设计：划分由人为开始，规模划分好之后估算是自动产生的
   3. 日程计划
2. 这会带来什么的好处？比较容易扛住别人的质疑。
   1. 攻击点：资源和时间是否被高估了
   2. 解决：估算没有代码行 PROBE 只有功能点是大中小。

日程计划原理和方法

1. 任务计划和日程计划
2. 典型计划流程回顾
   1. 估算规模
   2. 估算资源
   3. 规划日程
3. 考虑假期的影响：时间计划和工作计划并存。

任务清单

任务	需要时间资源（小时）	累计时间资源（小时）
A	2	2
B	3	5
C	3	8
D	4	12
E	6	18
F	2	20
G	7	27

资料清单

日期（第 X 天）	时间资源（小时）	累计时间资源（小时）
1	4	4
2	4	8
3	4	12
4	4	16
5	4	20
6	4	24
7	4	28

日程计划

任务	需要时间资源（小时）	累计时间资源（小时）	完成时间（第 X 天）
A	2	2	1
B	3	5	2
C	3	8	2
D	4	12	3
E	6	18	5
F	2	20	5
G	7	27	7

质量计划原理和方法

1. 项目的质量计划中应当确定需要开展的质量保证活动。
2. 典型的质量保证活动包括个人评审、团队评审、单元测试、集成测试、系统测试以及验收测试等。
3. 在质量计划中需要解决的关键的问题是该开展哪些活动，以及这些活动开展的程度，如时间、人数和目标分别是什么。

风险计划

1. 风险管理的目的是在风险发生前，识别出潜在的问题，以便在产品或项目的生命周期中规划和实施风险管理活动，以消除潜在问题对项目产生的负面影响。
2. 风险管理大致分成两部分，即风险识别和风险应对。

风险识别

风险：没有发生，有一定概率发生，发生后有一定影响，才是风险。

问题：已经发生的，比如人员调动等

1. 识别与成本、进度及绩效相关的风险
2. 审查可能影响项目的环境因素
3. 审查工作分解结构的所有组件，作为风险识别的一部分，以协助确保所有的工作投入均已考虑
4. 审查项目计划的所有组件，作为风险识别的一部分，以确保项目在各方面均已考虑
5. 记录风险的内容、条件及可能的结果
6. 识别每一风险相关的干系人
7. 利用已定义的风险参数，评估已识别的风险
8. 依照定义的风险类别，将风险分类并分组
9. 排列降低风险的优先级
10. 可能性很低，但是发生影响程度很大：政策变化、领导层大规模变动、公司倒闭
11. [P（可能性）, I（影响程度）, T（阈值）]

【2014】风险应对

识别风险之后，就应当制定相应的风险管理策略，以应对各类风险。

典型的策略包括：

1. 风险转嫁
2. 风险解决
3. 风险缓解

计划评审和各方承诺

项目各项计划完成之后，需要与各类计划的相关干系人开展评审工作，解决计划中相互矛盾与不一致的地方，并获得参与项目的各方对项目计划的承诺。

1. 识别每一项计划所需支持，并与相关干系人协商承诺。
2. 记录所有的承诺，包括完整的承诺和临时的承诺，并确保由适当层次的人员签署。
3. 适时与资深管理人员一起审查承诺。

项目跟踪意义

1. 在项目进展过程中开展跟踪活动的目的在于了解项目进度，以便在项目实际进展与计划产生严重偏离时，可采取适当的纠正措施。
2. 项目进度滞后与否需要参照物，即项目计划。
3. 项目跟踪需要管理针对偏差而采取的纠偏措施。

挣值管理方法 EVM

项目的挣值管理方法（Earned Value Management，简称 EVM）是用来客观度量项目进度的一种项目管理方法。

1. 每项任务实现附以一定价值（credit）
2. 100% 完成该项任务，就获得相应价值

EVM 采用与进度计划、成本预算和实际成本相联系的三个独立的变量，进行项目绩效测量。

这套方法直接应用到软件项目中会存在问题。

在软件项目中，计划投入的时间作为挣值比较合适。

【2022Fall】EVM 的三种实现

• 简单实现：这种方式仅仅关注进度信息。在实现时，首先需要建立 WBS，定义工作范围；其次为 WBS 中每一项工作定义一个价值（PV）；最后按照一定的规则将某一数值赋给已经完成的工作或者正在进行的工作。常用规则分别为 0-100 规则和 50-50 规则，前者只有当某项任务完成时，该任务的 PV 值将转化成 EV 值；后者只需要开始某项任务，即可以赋原 PV 值的 50%作为 EV 值，完成时，再加上另外的 50%。而实际完成的工作所需成本 AC 不对 EV 值产生任何影响。
• 中级实现在简单实现的基础上，加入日程偏差的计算。典型计算方式有：
  • 日程偏差 SV = EV – PV；
  • 日程偏差指数 SPI = EV/PV；
• 高级实现在中级实现的基础上，还需要考察项目的实际成本。
• 共同要点：TODO

EVM 图示

1. 上面的线是为了获取这些挣值付出的实际代价，这个线和挣值之间的差异是成本差异。
2. 中间的线是预算（每天需要完成多少挣值）BAC，理想情况下是一条直线。
3. 下面的线是挣值（实际的进展情况）（EV），和 owner value 有关，对应 plan value
4. 实际获取挣值和预计获取挣值的差异是进度差异。
5. 例子：
   1. 一共 100 个值（计划投入时间），第一天需要完成 50 个值，第二天需要完成 20 个值，第三天需要完成 30 个值。
   2. BAC：第一天 50，第二天 70，第三天 100.
   3. 超期情况，EV：第二天 50 值，AC：第二天 100 值。
      1. 这就意味这这两天投入了 100 个值完成了原计划用 50 个值完成的工作，这就对应着进度落后，成本超支。
      2. CV = 50，SV = 20
   4. 有可能出现第二天用户说，任务 B 和任务 C 不做了（项目进度落后变为了项目进度正常）
6. 挣值管理会带来什么好处？可以很好的适应项目的动态变化。

常用 EVM 度量

1. BAC 表示按照 PV 值的曲线，当项目完成的时候所需预算或者时间
2. 成本差异 CV = EV-AC
3. 成本差异指数 CPI = EV/AC
4. 日程偏差 SV = EV–PV
5. 日程偏差指数 SPI = EV/PV
6. 预计完成成本 \(EAC = AC + \frac{BAC-EV}{CPI} = \frac{BAC}{CPI}\)

EVM 应用示例（讨论）

1. Plan（计划投入时间），Actual（实际投入时间）
2. 虽然现在没有落后，但是暴露了隐患

另外一种 EVM 的变形——燃尽图

1. 燃尽图是简单的挣值管理的变形。
2. 他是剩下的工作占的百分比。

EVM 的局限性

1. EVM 这种方式也有一定的局限性：
   1. EVM 一般不能应用软件项目的质量管理。
   2. EVM 需要定量化的管理机制，这就使其在一些探索型项目以及常用的敏捷开发方法中的应用受到限制
2. EVM 完全依赖项目的准确估算，然而在项目早期，很难对项目进行非常准确的估算。

里程碑评审

1. 软件项目的里程碑往往是指某个时间点，用以标记某项工作的完成或者阶段的结束。
2. 审查的内容包括：
   1. 项目相关的承诺，如日期、规格、质量等等；
   2. 项目各项计划的执行状况；
   3. 项目当前的状态讨论；
   4. 项目面临的风险讨论等

其他计划跟踪

1. 日程计划跟踪
2. 承诺计划跟踪
3. 风险计划跟踪
4. 数据收集计划跟踪
5. 沟通计划跟踪

纠偏活动的管理

1. 典型的纠偏活动包括
   1. 偏差原因分析
   2. 纠偏措施定义
   3. 纠偏措施管理
2. 0-100 原则：只要没有全部完成，就没有。
3. 50-50 原则：只要宣称开始做，就有 50

项目总结

项目总结的意义

1. 软件项目的特点决定了持续改善对于软件工程师的重要性。
2. Rita Mae Brown 在书中写到的那样“所谓的愚蠢（Insanity）就是反复做同样的事情，但是期望有不同的结果”
3. 提供一个系统化的方式来总结经验教训、防止犯同样的错误、评估项目团队绩效、积累过程数据等。提供给项目团队成员持续学习和改进的机会。

项目总结过程

1. 项目总结需要系统化有条理的进行，才能不遗漏重要的内容。因此往往需要事先定义总结过程，然后按部就班开展总结工作。
2. 一般情况下，项目总结都包括
   1. 准备阶段
   2. 总结阶段
   3. 报告阶段

基于 PMBOK 的总结

范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理和整合管理 9 大知识领域。

范围管理

项目范围包括产品范围和项目范围。对项目范围管理的总结应当主要关注项目的需求开发过程与变更管理中的得失，对需求管理实际执行情况的差距进行原因分析，找到改进的机会。典型的问题包括

1. 是否有未被识别的需求？
2. 是否有没有得到响应的需求变更？
3. 需求是否出现蔓延现象等。

时间管理

项目时间管理所关注的就是项目的日程计划以及对日程计划的跟踪和管理状况。因此主要考察计划的准确程度以及各个里程碑的偏差情况。

1. 估算偏差有多大？
2. 日程计划准确程度如何？
3. 里程碑偏差有多大？
4. 日程计划有什么变更？为什么？

成本管理

成本管理包括对成本进行估算、预算和控制的各个过程，从而确保项目在批准的预算内完工

1. 项目计划投入总时间是多少？实际是多少？
2. 各个阶段计划投入时间是多少？实际是多少？
3. 偏差的原因是什么？

质量管理

项目质量管理包括执行组织确定质量政策、目标与职责的各过程和活动，从而使项目满足其预定的需求。

1. 项目整体质量状况如何？
2. 验收测试缺陷率是多少？
3. 有没有办法在前期消除这些缺陷？

项目人力资源管理

项目人力资源管理包括组织、管理与领导项目团队的各个过程。

1. 项目的生产效率如何？
2. 每个人的生成效率如何？
3. 每个人对项目的满意程度如何？
4. 有没有提升的办法？

项目沟通

项目沟通管理包括为确保项目信息及时且恰当地生成、收集、发布、存储、调用最终处置所需的各个过程

1. 项目有没有因为沟通不够导致问题？
2. 各个项目干系人沟通手段有哪些？有没有需要总结的经验教训？
3. 什么样的沟通方法最为有效？

项目风险管理

项目风险管理包括风险管理规划、风险识别、风险分析、风险应对规划和风险监控等各个过程。

哪些问题在前期没有预料的相应的风险？为什么？

1. 哪些风险应对措施比较有效？
2. 就组织层面考察，哪些风险发生的频度较高？
3. 整个风险管理有哪些经验教训？

采购管理

项目采购管理包括从项目组织外部采购或获得所需产品、服务或成果的各个过程。

1. 项目方案是否合理？
2. 各类采购而得的工具是否合用？
3. 供应商服务的评价？
4. 采购相应的成本和风险考虑？
5. 项目合同管理的经验教训有哪些？

整合管理

项目整合管理包括为识别、定义、组合、统一与协调项目管理过程组的各过程及项目管理活动而进行的各种过程和活动

1. 各类计划之间是否协调一致？
2. 团队章程的执行状况怎样？
3. 项目变更的处理流程是否有效？
4. 项目完成之后相应的产物是否得到妥善保存？
5. 有没有对组织过程资产的更新？

TSP 项目总结介绍

1. TSP 也提供了一种项目总结的方式，在这种方式当中，团队成员结合自己的角色，总结自己角色相关工作的得失，提出下一个开发周期的改进建议。
2. 典型角色包括项目组长、计划经理、开发经理、质量经理、过程经理和支持经理等。

TSP 总结过程阶段

1. 准备阶段
2. 过程数据评审阶段
3. 人员角色评价阶段
4. 总结报告撰写阶段

过程数据评审阶段

1. 该阶段往往由过程经理或者质量经理带领整个团队分析过程数据，识别过程改进机会。
2. 可以结合典型 TSP 团队角色，逐个讨论改进领域。如团队领导力、计划准确性、过程优劣、质量管理能力、开发环境以及配置管理等。
3. 此外，也可以就 TSP 教练的作用进行评价。
4. 过程数据评审阶段还要求开发团队的所有成员都整理过程改进提案（PIP）。

人员角色评审-项目组长

1. 项目组长的角色评审应当从领导力角度开考察团队的表现。
2. 重点关注团队激励和团队承诺方面的问题。
3. 项目会议的组织情况也需要总结。比如，会议效果、讨论技巧等。
4. 此外，还应当就如何在下一周期做得更好提出改进建议。

人员角色评审-计划经理

计划经理主要关注项目进度，因此，在总结阶段需要就估算、生产效率、里程碑等话题进行总结。例如：

1. 项目产品规模的估算值和实际值有多大的偏差？为什么有这些偏差？
2. 项目的计划开发时间以实际开发时间有没有偏差？原因是什么？
3. 项目整体的生产效率是多少？
4. 人均资源水平有多少？
5. 项目的 PV 与 EV 趋势是什么？为什么有偏差？
6. 跟以前的开发周期相比，生产效率有没有提升？为什么？
7. 下一个开发周期需要如何提升？

人员角色评审-开发经理

开发经理进行总结的时候，应当从开发内容和开发策略角度出发，总结得失。例如：

1. 将实际开发结果与计划开发内容进行对比，看看是否完全实现需求？
2. 或者从开发策略角度考察，看看事先定义的开发策略是否有效?如何改进？

此外，开发经理也应当就质量话题提出见解。比如:

1. 现有的设计和实现步骤是否有助于质量目标的实现？
2. 对于可用性、性能以及兼容性等其他高层次质量要求，现有的设计方法和实现平台是否可以支持？
3. 现有的质量度量方式效果如何？未来怎样改进？

人员角色评审-质量经理

质量经理的总结则应该从项目整体质量状况出发，总结质量目标的实现过程，并找出改进机会。因此，可以就如下一些问题开展讨论：

1. 项目整体质量状况如何？质量目标实现了吗？为什么？
2. 是否所有预定的质量管理活动都开展了？如果没有，为什么
3. 项目进展过程中，质量趋势是什么？
4. 每个阶段的 yield 分别是什么？为什么有的过低？
5. 测试开始之后有多少缺陷？哪些缺陷可以通过什么样的方式在前期排除？
6. 现有的质量管理手段的效果如何？有哪些需要改进？

人员角色评审-过程经理

过程经理关注团队遵循过程的程度和过程改进方案。因此，在项目总结阶段，过程经理需要总结的问题为：

1. 是否所有人都如实记录数据？
2. 团队成员对过程遵循状况如何？为什么？
3. 记录的过程数据说明了什么？
4. 现有的过程有哪些不足？
5. 所有的 PIP 都提交了吗？
6. 哪些 PIP 值得在下个周期实现？如果要实现，对现有过程需要做什么样的调整？

人员角色评审-支持经理

支持经理主要关注配置管理状况、问题和风险跟踪机制以及复用策略的支持等话题。因此，在项目总结阶段，支持经理需要总结的问题为：

1. 项目团队开发环境是否合用？
2. 项目过程中，对于配置项出现了几次变更？原因分别是什么？未来如何改进？
3. 配置管理活动开展情况如何？是否有未经授权的配置项修改现象出现？
4. 风险和问题跟踪机制是否有效？是否所有问题都得到处理？
5. 风险有没有导致对项目的负面影响？
6. 哪些风险一开始没有被识别出来？
7. 复用策略是否有效？
8. 对比上一阶段，复用比例是否上升？为什么？怎么改进？

人员角色评审-工程师

此外，由于大部分角色经理同时充当着软件工程师的角色，因此，还需要就工程师角色的工作状况进行总结。工程师重点关注的就是个人的绩效（生产效率、质量水平等）。因此，需要总结的问题包括：

1. 个人计划的绩效与实际的绩效有没有差别？为什么有偏差？
2. 对比上个周期有没有进步？为什么？
3. 下个开发周期将如何改进？
4. 根据个人总结的 PIP，你觉得最值得改进的有哪些内容