上文中（ 《全生命周期的质量度量》）我们讨论了软件质量度量的现状、定性分析和定量分析、在设计度量时应关注什么，以及全生命周期的度量，可按时间跨度分为两类：一类是跨越全生命周期的质量度量，时间跨度较大，不便于我们聚焦某一具体的工作场景进行分析；另一种是迭代内的质量度量，时间短更便于聚焦，本文主要讨论的就是迭代内的定量分析。

基于交付目标确定度量指标

在迭代内的多个阶段，可以针对当下关心的交付目标，选择度量方式和指标。

• 需求阶段：更关心需求质量，迭代划分是否合理。
• 实现阶段：更关心实现方案的有效性和复杂度，对需求的工作量预估是否准确等。
• 测试阶段：更关心缺陷趋势、缺陷分布和引入时机。
• 上线和运维：更关心系统稳定性，重大缺陷的响应力。

具体到某个迭代内，可以选择的定量指标有很多，下图列举了部分典型指标：

三维四类定量建模

看上去指标很多，且有些重复，我们把这些指标归归类，不难发现大概可以归为四类指标：

• 通过率：统计通过或打回的比例，如构建通过率、缺陷逃逸率
• 数值：统计观察变量的绝对值，如千行代码缺陷数、发布回滚数
• 效率：统计状态的停留时长或观察变量的处理率，如需求研发时长、缺陷处理率
• 覆盖率：统计观察变量就某一方面的覆盖情况，如需求覆盖率、测试覆盖率

再分析一下，这四类指标的观察对象和观察时效也是不一致的，举几个例子来帮助理解：

• 通过率：代码评审通过率可用来衡量个人或代码库
• 数值：千行代码缺陷数衡量的是代码库；发布回滚数衡量的是服务
• 效率：需求前置时间衡量的是整个团队的需求准备效率
• 覆盖率：测试覆盖率衡量的是代码库

进一步抽象，我们可以从组织、实现、时间三个维度来进行定量分析的建模，下图简单描述了建模的框架：

下面我们从两个典型案例来演练一下。

场景一：需求和研发阶段问题

由于和业务方沟通成本高，经常面临已经进入迭代了，但迭代开发范围迟迟确定不了的窘境；在开始研发后，需求经常变动，带来大量返工；提交代码后CI跑测试时间过长；每日代码评审反馈代码提交质量不高；测试人员非常忙，经常没时间及时回归Bug。

针对问题选择度量指标：

需求前置时间：按冲刺、迭代的时间维度统计需求开发的效率 需求变更率：按小组或团队统计需求变更比例，也可按个人统计需求返工带来的工作量 评审通过率：按个人、代码库或服务统计评审通过率 测试：按冲刺、迭代的时间维度统计状态停留时长，或按小组统计测试效率

场景二：测试和上线阶段问题

上线前测试人员加班加点手动回归；之前迭代已经修复过的Bug反复出现；复杂场景的Bug修复不彻底，反复修改和复测；上线后经常由于缺陷造成回滚，运维团队反馈测试不充分。

针对问题选择度量指标：

测试覆盖率：按代码库或服务统计测试覆盖率 缺陷弹回率：按个人或小组来统计缺陷弹回率，度量修复效率 发布回滚数：按服务来统计由于缺陷导致的回滚数 缺陷逃逸率：按不同业务服务来度量缺陷的漏测比例

度量的动机

一般有两种动机：一是自有的，在项目一开始就已经达成共识的、需要持续度量的关键指标；二是问题驱动的度量，即我们在交付过程中遇到了问题，为了解决具体的问题而衍生的度量需求。明确度量动机有助于我们更有针对性的设计度量，可以有效避免盲目度量。

先选择指标再定维度

问题的暴露阶段和其对应的度量阶段往往不是完全匹配的，在设计度量时应针对痛点问题进行分析，找到确切对应的指标，再考虑可度量的时间或物理的维度。如场景二中在上线后反馈的测试不充分，需要度量测试用例的需求覆盖率，以及测试和上线整个过程的缺陷逃逸率。系统的整体的分析问题，可以避免头疼医头脚疼医脚的误区。

定量分析为效能提升提供依据

为什么要做这么麻烦的定量分析？毕竟整个过程需要选择指标、搭建基础设置、持续的收集和分析数据，这要耗费一定人力才能达成。这要从我们交付的三个目标层次说起：

• 第一层：交付项目，项目思维主导，一过性的应付上线就OK
• 第二层：交付价值，产品思维主导，从业务价值出发交付软件
• 第三层：轻松高效的高质量交付价值，既满足客户需求，又能给团队带来美好的体验

在精益思想里，如果过程中杜绝了浪费，每个人的状态都是稳定而轻松的，但整个团队的交付却有着从量到质的飞跃。这也是我们软件交付的目标。而定量分析能为提升团队效能提供数据依据，帮助我们找到真正的浪费点，从而提出真正有效的改进。

本文介绍的方法适用于大部分需要质量度量的场景。受限于笔者个人经验，针对不同的度量需求，还请大家具体问题具体分析，酌情设计符合团队上下文的度量模型。