深度解读《E³CI软件研发效能度量规范》标准

点击上方蓝字，关注VSM

《E³CI软件研发效能度量规范》（以下称E³CI）是由中关村智联软件服务业质量创新联盟、中国软件行业协会系统与软件过程改进分会发起的一款团体标准。依托于国内企业在研发效能领域的先进实践，通过对研发效能进行体系化梳理及定义，制定研发效能度量的原则、框架、方法和指标集，帮助企业的软件组织、团队及个人通过有效的度量和指标支持构建、执行、评估、提升软件研发效能，实现质效双增。

云加速是软件研发效能领域的深入践行者，作为E³CI《软件研发效能度量规范》参编单位参与了该规范的编写，为帮助更多企业学习、了解及运用该团体标准，做本篇解读，欢迎广大读者传阅、交流！

如何理解软件研发效能？

E³CI以价值导向，规定了软件研发效能度量的基本构成以及相关关系。以认知域（Cognition）与改进域（Improvement）组成，E³指的是：效率（Efficiency）、效果（Effectiveness）以及卓越（Excellence）。

E³CI中对软件研发效能进行了定义：“软件研发效能是持续快速交付高质量有价值的软件产品和服务的能力。”这句话中主要的词为“交付”，交付代表着有人买单，有人愿意为软件产品和服务付钱，如果不进行交付，那么等同于价值为0，所以交付就是判断是否有价值的关键点。

再将该能力分为三个方面，分别为：效率（Efficiency）、效果（Effectiveness）以及卓越能力（Excellence），以此形成了E³。

E	原文描述	简单描述
效率	效率要求软件研发过程能够多、快、好、省地交付产品和服务，即价值高、速度快、质量好、成本低。	交付要够快
效果	效果要求软件研发过程交付的产品和服务能够达成用户和业务的目标。	交付的内容能够满足对方需求，解决对方痛点。
卓越能力	卓越能力要求软件研发过程以健康的、可持续的方式交付产品和服务。	健康：精益原则可持续：持续交付

那么如何达成E³的能力呢？E³CI中将为达成此能力所涉及的要点分为两部分：认知域（Cognition）与改进域（Improvement）。

认知域（Cognition）分为五个部分，分别为：交付价值、交付速率、交付质量、交付成本、交付能力。

为什么叫认知域？因为要提升部分管理者的认知，这样才会实施改进，逐步提升。

认知域	原文描述	简单描述
交付价值	反映软件研发过程满足用户或业务目标的程度。	交付的内容是否能够让用户满意或自身获得业务的增长（得到了多少钱）。
交付速率	反映软件研发过程交付产品和服务的快慢程度。	交付是否够快。
交付质量	反映软件研发过程交付的产品和服务满足用户和业务需求的程度。	交付的内容是否够满足对方需求，解决对方痛点。
交付成本	反映软件研发过程交付产品和服务的开销。	交付过程中花了多少钱。
交付能力	反映软件研发过程交付产品和服务的可持续性。	交付过程是否健康（过程是否有不必要的浪费、是否有阻塞）、是否能够持续交付

当企业对认知域都进行了学习，有了一定的认知时，就会将当前情况进行度量展现，此时企业就会提出一系列的改进要求对某些点进行改进，如何管理改进的过程？此时就需要改进域来进行度量。

改进域	原文描述	简单描述
改进域	反映在认知的基础上进行研发效能改进过程的成效。改进过程宜针对交付价值、交付速率、交付质量、交付成本、交付能力等领域进行系统或专项提升，以达成效率、效果和卓越能力等效能目标。	度量某个认知域是否在进行改进

E3CI模型图👆

度量软件研发效能

度量方法

E³CI认为软件研发效能应按照三个步骤执行：

确立目标和范围
选取度量指标
实施度量和改进

前两步为GQM的方法，确立目标就是G（Goal），确立范围就是Q（Question），选取度量指标为M（Metric），主要以找到目标，提出问题并选取合适的指标。第三步是根据选取的指标来进行度量与改进，度量就是展现我们的当前状态，改进是对未来的一种期望。

确定目标和范围（C&Q）

E³CI中认为，如果想要对研发效能进行度量，那么就要先提出目标，并根据目标提出问题，对问题进行优先级排序，找到我们当前最迫切的问题并对其进行范围的限定。度量并不是团队或个人的事情，要与研发组织的主要管理者、领导达成共识，获得管理者与领导的认可，以便能够在后续改进时获取支持。

选取度量指标（M）

E³CI中列出了认知域指标（63个）以及改进域指标（5个）共68个指标，将软件研发过程纵向分为：需求、设计、开发、测试、发布、运营六个阶段；横向分为：交付价值、交付质量、交付效率、交付质量、交付成本、交付能力五个认知域，如下图所示：

软件开发过程

首先最顶层的内容从左向后为软件开发过程，对于软件开发来讲，也可以称之为价值流。该过程可能是项目、产品、产品版本以及产品组件的研发过程。

认知域

左侧认知域就是E3CI中的“C”。

指标

横向的认知域与纵向的软件研发过程相交，形成一个矩阵，矩阵中的内容为每一项指标。指标又分为结果指标与过程指标，E3CI建议企业重点关注结果指标，而非过程指标，但过程指标会对结果指标造成一定的影响。

结果指标

战略性指标，影响产品、服务的最终结果。通常用于做最终的结果评价。

过程指标

战术性指标，影响结果指标的某些因素。通常用于实时追踪监控。（虚线标识的也为过程指标）

改进域

右侧改进域为E³CI中的“I”，监控是否在执行改进。

实施度量与改进

1、度量

E³CI定义了指标度量模型，如下图所示：

以模型所示，度量的步骤为：

找到研发组织的研发过程（价值流）
分析研发过程，以业务目标为核心，说清楚需要了解什么（分析与决策、视图）
业务目标拆解为具体的指标，划分到每个研发过程，并且多指标结合反应业务目标（指标、度量）
如果想要看这些指标，都需要哪些数据来支撑（数据集/数据湖）；
所需的数据都来自哪些系统（数据源）。

2、改进

根据当前研发状态，找到最紧迫的改进点进行改进，并使用改进域中的相关指标来监控并管理改进过程。针对不同行业、不同成熟度的研发组织，因改进的方式不同，所以E3CI中并未给出具体的改进方法。

E³CI对指标及视图定义

指标定义

指标名称	指标概念的简要名称。起名应遵从言简意赅、避免歧义、尊重习惯等原则。
概念描述	对指标含义、目的和作用的描述。
计算方法	指标度量值如何进行计算。
计量单位	指标度量值计算时需要的计量。
分类	度量主要反映的认知域或改进域，包括交付价值、交付速率、交付质量、交付成本、交付能力和持续改进；以及指标涉及的典型生命周期阶段，包括需求、设计、开发、测试、发布、运营中的一个或多个等。
补充说明	需要补充说明部分，利于对指标的深入理解和应用，可包含数据展现图表示例，以及在实施中应注意或考虑的问题等。

视图定义

意图

目的陈述

指标

度量指标1

度量指标2

…

聚焦

关注的问题1

关注的问题2

…

图表

图表1

图表2

…

分析方法

针对关注的问题，进行多图表、多因子关联分析。建议采取多方案以供选取，目的在于降低风险，实现业务目标。

使用如下图所示：

价值流视角

首先，E³CI是以价值为出发点的，而“钱”是价值最有效的衡量点，客户愿意付钱，那么产品才有价值。同时，客户为什么愿意付钱？除了能够解决客户的痛点，满足客户的需求外，我们还要将产品交付给客户，客户才会给付钱，这就是为什么所有的认知域均以“交付”为开头，就是为了表明：“不交付，价值为0”这样的概念。

其次，E³CI的价值是以组件为交付的，在术语和定义（原标准3.1章节）中，首先就是对组件进行了定义：“在一个特定的分析层次上考虑的系统中带有分立结构的实体。诸如一个组合或软件模块（引用了GB/T 18492—2001，定义 3.1）”，并且在指标中增加了市面上不太常见的三个指标：“组件按时交付率、组件复用率以及接口变更率”，并且在大部分的指标中都说明了以组件为度量维度。价值是可以按照组件来进行交付的，虽然交付的组件无法满足客户所有的需求，但是却可以在满足客户部分需求的同时，快速获取客户的反馈，同时让客户有“满意”的想法：“我的部分需求已经被满足了，这个产品对我还是有价值的”。

然后，E³CI没有明确定义具体的角色应该看什么，是因为各行各业的关注点不同，但E³CI的指标模型是可以以角色来进行划分的，如下图所示：

所以，企业即使所度量的指标不一样，但是也可以使用E³CI的模型设计出适合企业本身的度量模型，这就是E³CI的价值所在。

E³CI制定及推广应用，对研发数字化转型中的研发效率、工程效能提升起到推动作用，帮助企业的软件组织、团队及个人通过有效的度量和指标支持构建、执行、评估，切实提升软件研发效能，实现质效双增。

点个在看少个 bug 👇