敏捷研发工程效率度量

FYIRH

工程效率度量没有标准的定义，各个团队可依据自己的需要给出定义。一般来说，常用的工程效率度量有以下几种。

1.编译效率

编译效率一般用开发人员从启动个人构建，到获得构建结果反馈的时间来度量，包括的活动有代码提交、编译连接、静态检查、单元测试。

# {3 [$ y8 a; y4 c, O; W$ q

2.版本构建效率

- t8 [9 L2 I$ b- w' D6 X2 H

版本构建效率一般用从启动版本构建到获得可运行版本的时间来度量，包括的活动有版本编译、静态检查、冒烟测试。

3 q5 d. z8 T4 g* |9 S9 U

3.回归验证效率

回归验证效率一般用完成一轮产品回归验证所需的时间来度量，即在迭代周期内修改了旧代码后，重新进入测试程序以确认修改没有引入新的错误，或导致其他代码产生错误的一轮测试时间。回顾验证包括手工和自动化测试，但是应该尽量采用全自动化测试，因为手工的回归验证方法无法满足频繁发布的要求。

+ S1 J$ v- K) C1 w3 n& C

4.全量功能验证效率

一般用覆盖版本所有功能的一轮测试执行时间来度量全量功能验证效率，包括手工测试和自动化测试，自动化测试的程度越高越好。

/ M6 ?* w4 P! u* {" }

5.非功能性验证效率

依据产品的测试计划，有些版本需要开展性能测试、安全测试、压力测试等非功能性测试。这些测试需要用专业的工具完成，这些通常是模拟大数据量、模拟长时间运行的测试，因此，非功能性验证效率是测试效率的重要组成部分。

' u. j7 R" \6 n; g2 Z

表9-5是互联网企业Y定义的研发效率提升的度量项和提升

$ q" [) l: o& |+ o5 y; e8 r

表9-5研发效率目标示例

" [! z7 D, T1 }

该企业为每个指标设定了一个目标，并期望通过敏捷转型在两年内达到该目标。最后一项指标是缩短特性平均周期时间，这是最高的效率提升目标，前面效率提升的最终目的都是为了缩短特性平均周期时间。