汽车软件研发管理的35个指标

wmwlove

指标，这是软件研发管理绕不过去的话题，这也是大家一直以来的管理惯例。
不过，在如今内卷至混乱的年代，没有太多数理逻辑的量化指标频频受到质疑，为什么是5%，不是6%；实际项目如此复杂，固定的指标合理吗？
质疑并非没有道理，但指标存在的意义不在于能够应对这些质疑。我们可以从另外两个角度理解：

此为无奈之举，简化至可以理解和管控的可量化指标，是认识的需要，也是管理的抓手。

指标既会作为具备相当一致性的成熟产品或团队的绩效表征，也是将不成熟推向成熟的手段，而且推动意义大于表征意义。

既然仍然需要指标，本文会汇总对汽车软件相对有价值的度量指标，以供大家选用。

1需求规模

需求规模=需求大小或颗粒度

该指标反映了单个需求交付及开发的复杂度，如果能对需求规模进行比较好的拆分与估算，十分有利于项目计划与工作量的合理规划。

按照不同的项目或产品类型，可以使用故事点、feature、功能点、对应代码当量等维度来评价。

2需求交付周期

需求交付周期=需求释放时间-需求创建时间

该指标反映了团队对新需求的评估及交付速率，这也体现了敏捷宣言中拥抱变化的力度。

算法里的需求释放时间可以按照系统里需求通过评审释放或变更经过CCB批准释放的时间来定义，而需求创建时间可以按照系统里需求打基线或者提交的时间来定义。

3需求变更率

需求变更率=发生过变更的需求数/已释放的需求总数

该指标反映了对变更控制的能力，在传统汽车瀑布式开发下，对变更控制的能力也会指向管理的水平，但敏捷时代下，低需求变更率甚至是负面的表征。

算法里的需求数可以按照需求管理系统里的条目数或者需求文本的数量来统计。

4开发交付周期
开发交付周期=软件发布时间-需求释放时间
该指标反映了开发团队的开发效率，算法里的软件发布时间可以按照软件打包发布的时间来定义，而需求释放时间可以按照系统里需求通过评审释放或变更经过CCB批准释放的时间来定义。
软件发布通常会区分内部发布和外部发布，可以根据实际业务需求来选择度量方式。

5需求吞吐量
需求吞吐量=统计周期内交付的需求规模
该指标与需求交付周期度量的目标接近，但交付周期侧重于单位需求的交付效率，吞吐量关注的则是整体产能。
算法里的统计周期可以按照月度或季度来统计。

6需求按时交付率
需求按时交付率=按时交付的需求数/计划交付需求数
该指标反映了需求按时交付的能力。
算法里的数量可以按照需求管理系统里的条目数或者变更管理系统里工作项数量来统计。

7需求评审通过率

需求评审通过率=通过评审释放的需求数/提交评审的需求数

该指标反映了需求提出者撰写需求的能力，也会反映出对需求上线进行整体规划的能力。

算法中的需求数可以按照需求管理系统里的条目或者变更管理系统里工作项的数量来统计。

8需求评审缺陷密度

需求评审缺陷密度=需求评审检出缺陷数/需求规模

该指标反映了需求评审的效果。

算法中的缺陷数可以按照评审finding或者开出的问题项的数量来统计，而需求规模可以使用故事点、feature、功能点、对应代码当量等维度来统计。

9设计评审通过率

设计评审通过率=通过评审的组件数/提交评审的组件数

该指标反映了组件及接口定义和设计的质量。

算法里的组件数可以按照软件架构的组件拆分来统计。

10设计评审缺陷密度

设计评审缺陷密度=设计评审检出缺陷数/设计规模

该指标反映了设计评审的效果。

算法中的缺陷数可以按照评审finding或者开出的问题项的数量来统计，而设计规模可以通过需求规模或者组件数来统计。

11组件按时交付率

组件按时交付率=按时交付的组件数/计划交付组件数

该指标反映了软件开发人员进行模块或组件开发的能力，软件需要多组件集成后才能进行下一步的测试和发布，各组件开发都要按节奏协调起来。

算法里的组件数可以按照软件架构的组件拆分来统计。

12组件复用率

组件复用率=复用的组件数/总组件数

该指标反映了架构设计、组件设计甚至需求沟通方面的能力，不重复造轮子、进行复用开发是我们所鼓励的。

算法里的组件数可以按照软件架构的组件拆分来统计。

13接口变更率

接口变更率=变更的接口数/总接口数

该指标与组件复用率关注的能力接近，但组件复用率提升的是单个组件开发的效率，接口变更率更会致力于跨组件、跨系统的协同开发效率。

算法里的接口数可以按照系统及软件架构中定义的软件接口与软硬件接口来统计。

14代码开发当量

代码开发当量=代码抽象语法树加权最小编辑距离

该指标反映了代码的逻辑量和修改代码的工作量，排除了编程风格、换行习惯、注释等干扰因素，准确性比传统的代码行数更好。

15代码提交频率

代码提交频率=单位时间代码提交次数

该指标反映了代码开发的活跃度，也是敏捷中鼓励的小步快跑提交，但有可能也会让开发进行表面化的频繁小提交，反而带来质量的下降。

算法中的代码提交次数可以按照代码配置管理系统中记录的代码变更次数来统计。

16代码重复率

代码重复率=重复代码的代码规模/总代码规模

该指标反映了代码的可维护性，即代码重复率越高，代码可维护性越差，因为多处修改所需的工作量越大。这个指标会驱动代码抽象，如用函数、类、库、服务来封装等。

算法中的代码规模可以用代码当量或代码行数来统计。

17代码评审缺陷密度

代码评审缺陷密度=代码评审检出的缺陷数/代码规模

该指标反映了代码评审的效果。

算法中的缺陷数可以按照评审finding或者开出的问题项的数量来统计，而代码规模可以用代码当量或代码行数来统计。

18静态扫描缺陷密度

静态扫描缺陷密度=静态扫描检出缺陷数/代码规模

该指标反映了编码规范程度，如MISRA C。

算法中的缺陷数按照工具扫出来的finding统计，而代码规模可以用代码当量或代码行数来统计。

19提测成功率

提测成功率=提测成功次数/提测总次数

该指标反映了开发满足测试准入条件的水平，除了软件质量本身，通常也会涉及一些过程规范性要求。

算法里的提测次数可以按照真实版本或者对应的releasenotes的数量来统计。

20测试一次通过率

测试一次通过率=一次性通过测试的版本数/总测试的版本数

该指标反映了开发的质量，会一定程度推进团队对代码评审或单元测试等开发测试的重视，但是，能否通过测试终归是来源于对测试准出条件的定义，如果发布压力大于质量压力，准出条件形同虚设，这个指标也就失去了意义。

算法里的版本数可以按照真实版本或者对应的releasenotes的数量来统计。

21测试覆盖率
测试覆盖率=测试覆盖的条目数量/需要测试条目的总数量

该指标反映了测试对需求或代码的覆盖程度，也细分为测试需求覆盖率或测试代码覆盖率。

算法中的条目数量，对于需求的覆盖，可以按照需求管理系统里的条目数来统计，而对于代码的覆盖，可参考《汽车软件单元测试的要点与意义》里的描述。

22测试缺陷密度
测试缺陷密度=测试检出缺陷数量/代码规模

该指标反映了测试的效果。

算法中的缺陷数可以按照开出的缺陷项的数量来统计，而代码规模可以用代码当量或代码行数来统计。

23缺陷重开率

缺陷重开率=重新打开缺陷数量/总缺陷数量

该指标反映了缺陷修复的效果，重开率高组件或团队应进行针对性的分析与改进。

算法中的重新打开缺陷可能需要缺陷管理工具配置对应的字段来统计。

24缺陷阶段移除率

缺陷阶段移除率=某一阶段引入中移除的缺陷数量/该阶段引入的总缺陷数

该指标反映了特定阶段的活动或团队对于缺陷的整体贡献，自己带来的缺陷最好自己带走。

算法中的阶段移除（这里的移除指在该阶段发现）和引入缺陷数都需要依赖缺陷管理工具配置的特定字段来统计。

25缺陷逃逸率

缺陷逃逸率=后期发现的缺陷数量/总缺陷数量

该指标反映了前期缺陷检出的效果，也直接反映了汽车软件质量的真实水平。

算法中后期发现的缺陷数量可以理解为售后、工厂、整车集成这些环节发现的缺陷数量。

26缺陷检出率
缺陷检出率=各阶段发现的缺陷数量/总缺陷数量

该指标反映了软件开发不同阶段的缺陷检出的效果，同缺陷逃逸率指向接近，但它对不同阶段的不同活动或团队的缺陷检出进行了细化，通常作为优化缺陷逃逸率的进一步指标。

算法中各阶段可以理解为需求评审、设计评审、代码评审、开发测试、集成测试、软件测试、系统测试、整车测试、工厂生产、售后这些不同环节。

27缺陷率
缺陷率=致命级别的问题个数*10+严重级别的问题个数*3+一般级别的问题个数*1+提示级别的问题个数*0.1

该指标反映了缺陷视角下的软件整体质量状态，其中的缺陷等级定义以及对应权重的划分是指标有效与否的关键。

28缺陷分布

缺陷分布=缺陷不同属性的交叉分析

该指标反映了缺陷属性交叉分析的结果，同其他分布一样，它更多作为整体对比、分析、决策的工具。

缺陷属性可以根据类型、严重度、根本原因、模块、优先级、测试环境和负责的测试人员等进行分类，这些属性之间可以进行二维或多维的交叉分析，比如，利用透视表、直方图、饼图或帕累托图等方式。

29测试自动化率

测试自动化率=自动化测试用例数/总测试用例数

该指标反映了自动化测试的能力，要想实现敏捷的频繁迭代发布，很重要一个前提就是快速的自动化测试，尤其要关注回归测试的测试自动化率。

30流负载

流负载=已开始但未交付的需求数分布

该指标反映了需求、设计、 开发、测试、发布各阶段的需求数分布状态，类似工作量分布，但关注的是在制品瓶颈和积压，控制在制品数量有助于提高交付效率。

算法里的需求数可以按照需求管理系统里的条目数或者需求文本的数量来统计。

31流效率

流效率=活跃工作时间（即无阻塞地工作）/总交付时间（包括活跃工作时间和等待时间）

该指标反映了软件开发过程的顺畅程度和资源利用效率，也能比较好地将软件开发工作透明化。

算法里的活跃工作时间指的是需求沟通、需求评审、架构设计、开发、测试、发布等实际工作的时间，而总交付时间则包括了活跃工作时间以及各种等待时间，如配置在ALM工具中的待评审、待开发、待测试、待发布之类的等待阶段的停留时间。

32工作量分布

工作量分布=不同维度下的工作量差异展示

该指标反映了软件开发过程中，不同阶段、不同团队下的工作量分布比例，通常用来支持项目管理的工作分配，也会与其他指标进行关联分析。

工作量可以通过工作项数量（缺陷、变更、任务等）或者工作时间或者代码规模或者需求规模等不同维度体现。

33售后问题响应时长
售后问题响应时长=售后问题响应时间-售后问题提出时间
该指标反映了响应售后客户问题的及时性，算是“态度”问题。
算法里的响应时间可以按照系统里分配或者给客户首次正式答复（有切实计划）的时间来定义，而提出时间可以按照接到客户投诉的时间来定义。

34售后问题解决时长

售后问题解决时长=售后问题解决时间-售后问题响应时间

该指标反映了解决售后客户问题的及时性，是“能力”问题。

算法里的解决时间可以按照系统里解决或者按照OTA或刷件解决实车问题的时间来定义，而响应时间可以按照系统里分配或者给客户首次正式答复（有切实计划）的时间来定义。

35净推荐值NPS

净推荐值NPS=客户愿意向其他人推荐某功能或场景的意愿

该指标反映了客户的主观感受，而不聚焦在工程或软件质量本身。这在场景体验评价里，是一个有价值的指标，它也可以用于客户满意度的整体评价。

净推荐值以0-10的数字范围表示，得分为0到6的客户是负面评价者；7和8的分数是中立者；9和10是推荐者。

5写在最后
软件的高质量必然指向可指标化，而指标也是高质量的重要推手。

完