思码逸

「代码当量」指标解读看这一篇就够了

阅读本文你将收获： 什么是代码当量，原理是什么？ 代码当量的计算公式是什么？ 相比代码行数，代码当量好在哪？ 前言 代码当量，即开发当量（ELOC，Equivalent Line of Code，下文称”代码当量”），是一种由思码逸原创，对开发者代码工作量进行合理量化和度量的指标。与代码行数、提交数等浅层工作量指标相比，代码当量的优势体现在两个方面：不易受到编程习惯或特定代码行为的干扰（如换行、空行、注释、括号等），且能更好地反映代码开发所涉及的逻辑量。 看到这里你可能还是一头雾水：代码当量的原理是什么？它如何排除噪音的干扰？它的科学性到底如何？希望这篇文章能够帮助你初步了解代码当量和它背后的故事 代码当量从哪来，计算原理是什么？ 软件开发是一个动态的过程，代码随着提交发生变化，相应的抽象语法树也会演变。代码当量指标正是基于抽象语法树复杂度的计算。这一指标的原型来自思码逸创始团队2018年在软件工程顶级会议 FSE 上发布的论文《关于量化代码贡献的开发价值》。 计算代码当量时，我们既可以计算绝对值，也可以计算累积值： 代码当量的绝对值，可以理解为对代码在一个提交切面上的抽象语法树进行计算，会考虑抽象语法树的节点数、不同节点的权重等。 代码当量的累积值，则是计算代码在每一次提交前后的变化，并累加。针对某一次提交而言，其代码当量的计算是基于提交前后的抽象语法树之间的最小编辑距离。在思码逸的算法设计中，代码删减也被视为贡献，只是权重会显著低于代码增加。 代码当量的绝对值随着开发过程而上下浮动，通常呈现“持续增加—小幅回落”的模式并不断重复；而代码当量的累积值单调递增，主要用于反映团队或项目的产出和进度。 如何计算某个提交的代码当量？ 计算原理算法图示 下图简单演示了这个过程如何从代码的修改计算出代码当量的数值。 代码当量计算原理算法图示 首先，将源代码解析为抽象语法树(AST)，AST是源代码抽象语法结构的树型表示。它的抽象性质有助于消除代码中不重要的噪音，如代码风格、换行习惯等。后面我们会举例说明这一特性的好处。 其次，计算新旧树之间的树的差异（树diff）。树diff步骤的输出是一个编辑脚本，由一系列编辑操作组成，正是这些操作一步步将旧AST转换成新AST。编辑操作分为四种类型：插入、删除、移动和更新。例如，插入操作可以将新节点作为AST中现有节点的子节点插入；更新操作可以更新现有节点的值。 最后，我们计算所有编辑操作的加权总和，根据编辑操作的类型和此编辑操作的AST节点的类型为每个操作分配权重，最终得到代码当量的数值。 总结一下，从源码到代码当量的基础计算过程一共分三步：将旧/新源代码解析为ASTs + 通过在旧/新ASTs之间进行树状转换来生成编辑脚本 + 从编辑脚本加权计算代码当量。 相比代码行数，代码当量好在哪？ 担心一个例子不过瘾，我们一口气举了四个例子。 例1 代码行数指标（LOC，Line of Code）很容易被简单的代码习惯差异所影响。 在下图中，我们删除红色代码，新增绿色代码，实质上只是简单的代码格式变动，并不实际改变基本逻辑和代码质量，却表现为1行添加和4行删除(总共5行更改)。 相比之下，由于纯句法变化对AST没有影响，此段代码的新旧ASTs是相同的，所以这个操作的代码当量为0。 例2 代码行数不擅长检测代码块的移动。 比如下面的代码变动，简单地交换类中函数的顺序会产生4行添加和4行删除。 但是从抽象语法树的角度，这次修改只是改变了myMethod()函数对应节点在其父节点下的顺序，该节点本身未发生任何修改。因此修改myMethod()的代码当量为0。 例3 代码行数无法区分不同性质的代码的工作量。 考察以下Python代码，它的功能是在给定的字典中找到对称对。测试数据test_dict和实际功能函数find_sym_pairs()贡献了相等数量的行数（7行），这当然不能反映编写这两段代码所付出的不同的工作量。 但是通过为每个AST节点类型分配不同的权重，我们可以对不同类型AST节点的编辑操作进行更合理的评估，更合理的量化开发过程中的工作量。 例4 一个真实的案例：Bitcoin 项目中一个名为 Fix CRLF 的提交，修改了62个文件，删除了32876行代码，又将这32876行加了回去。 从代码行数的角度看，这是一个体量相当巨大的修改，但实际上对代码没有任何改动。这个提交的代码当量为0。 想试试代码当量计算？ 我们近期上线了代码当量游乐场，一款交互式的简版代码当量体验工具。你可以在游乐场中任意选择语言、调整加权设置、亲手修改代码，体验不同的代码编辑行为所产生的代码当量(开发当量)。 代码当量游乐场界面 在实际产品中，代码当量算法包含了更复杂的加权设计，更丰富的系统性机制，从而在整体分析的视角下进行工作量的计算。 参考文献 Towards quantifying the development value of code contributions 思码逸文档：技术原理&术语解释

研发效能度量体系构建的根本方法—— GQM 从入门到精通

阅读本文你将收获 1、GQM概念、起源步骤设计和参考意义； 2、GQM整体框架详解：目标-问题-指标； 3、构建研发效能度量体系的方法：现代GQM实践指南； ‍ 作者简介 任晶磊，思码逸 创始人兼CEO，清华大学计算机系博士，前微软亚洲研究院研究员，斯坦福大学、卡内基梅隆大学访问学者；《软件研发效能度量规范》标准专家组核心专家。在软件系统、软件工程领域从事前沿研究多年，具备丰富经验。曾在FSE、OSDI 等顶级国际学术会议上发表论文多篇，亦参与过微软下一代服务器系统架构设计与实现。同时，也是一位积极的开源贡献者。 现任思码逸CEO，通过打造先进的深度代码分析技术和研发大数据平台，以数据驱动软件工程，助力企业和团队提升研发效能。 ‍ 前言 目标-问题-指标（GQM）是软件工程领域的一套系统方法，被称为研发效能度量方法的“事实标准”。 通过系统化的数据度量和分析，我们可以更好地认知软件研发过程和产物，为研发团队提供及时反馈，优化研发流程，提升研发效能，为开发者带来卓越的软件工程实践。 但目前产业界对 GQM 的应用存在两方面的误区： 一是简单从字面理解“目标”、“问题”和“指标”的概念，没有进一步理解它们的具体定义和背后的模型等精髓； 二是尚未充分意识到 GQM 是构建研发效能度量体系的一种根本性方法。 今天我们看到很多关于研发效能度量的文章、演讲、案例和书籍。 它们分享了实践中宝贵的第一手经验，但各家指标纷繁、模式各异，研发效能实践者难免会感到无所适从。 GQM 为我们提供了抓住本质、化繁为简的有效路径。 本文将分享我们对早期和经典 GQM 模式的评论，并为读者提供一套现代 GQM 实践指南。 GQM 概念与起源 GQM 最早由 Basili 提出(Basili(1984))，发表在软件工程领域权威期刊 IEEE Transactions on Software Engineering 上。 GQM 当初是为软件工程研究中的数据收集和分析而设计的，基本思想是： 数据的收集和分析一定要聚焦于清晰具体的目标，每个目标划归为一组可量化回答的问题，每个问题通过若干特定的指标来回答。 依据指标收集到的数据，通过分析产生对问题的回答，进而达成定义的目标。 实际上，我们今天所讨论的研发效能度量，可以看作软件工程研究领域数据收集和分析的“低配版”。 软件工程研究通常需要生产环境中的数据来评价软件开发方法和认知软件开发过程，会采用 GQM 这样系统的方法，保证具体实施的科学性和严谨性。 实用目的下的研发效能度量，不必过度追求科学性和严谨性，但现实中往往因为一些随意乃至混乱的做法，获得无效的数据或误导的结论。 采用 GQM 方法，可以帮助我们实行真正有意义的研发效能度量。 我们先追本溯源，概览早期 GQM 的实施步骤。 早期步骤设计和参考意义 效率是“以正确的方式做事”，而效能是“做正确的事”。——彼得·德鲁克《有效的管理者》 GQM 包含如下六个基本步骤，其中最费时费力的一些步骤（标记了“*”）在今天已经因为流程工具的普及而变得非常便利。 正是因为这样数据收集成本的极大降低，让研发效能度量变得普遍可行和实用。 与此同时，其他 GQM 步骤侧重概念层面的思考和梳理，并不会给团队带来很大成本，却至关重要，能够保证整个过程在“做正确的事”。 它们在今天的研发效能度量实践中经常被忽视，得不偿失。 确立数据收集的目标。 目标通常分为两类，一类用于评价特定的软件开发方法，另一类独立于特定软件开发方法，用于认知软件研发过程或产出。 在研发效能度量实践中，评价改进措施的有效性即为前者，如 MARI 方法(OpenMARI)中实施改进后的再次度量验证。 后者并不以评价为目的，而是对研发过程或产出在某些维度上进行刻画。 目标更完备的定义方法参见经典模型或最新的实践。 列出感兴趣的问题。 问题是主观设立的目标和量化度量之间的桥梁。 例如，对于“评价软件进行修改的难易程度”这个目标，问题可以包含“多少代码修改只限于单一模块”。 这些问题通常会决定最终数据的分类或参数。 例如，“代码修改在各个系统模块的分布如何”意味着代码提交的数据应按照系统模块进行分类。 确立数据的分类。 通常每个问题可以引出对数据的一种具体分类。 分类应不重不漏，作为下一步设计数据收集表格的依据。 在今天的研发效能度量实践中，这些分类可作为研发数据治理或数据规范的依据。 *设计和测试数据收集表格。 需要开发者在提交代码修改时手动填写数据收集表格。 这是早期时代的产物。 今天业界已经广泛使用研发流程工具（最具代表性的就是 Jira），大部分数据可以在流程运转过程中方便地存留或填入，如事物或缺陷的分类，不再需要单独的数据收集表格和额外步骤。 所以流程工具的普及和自然的信息存留，为研发效能向数据驱动的方向发展提供了现实基础。 *收集和验证数据。 数据表格如果发现问题，需要与填表人进行访谈， 这种安排在今天或许也可借鉴，比如事务填写预估的故事点，如果通过代码当量等进行校准时发现较大偏差，就值得在迭代回顾会上讨论偏差的原因，逐步提升团队预估故事点的准确性。 分析数据。 当时所说的数据分析局限在根据问题计算数据的参数和分布。 今天可以采用的分析方法更加多样，比如同比、环比对比，依赖比当时更多更丰富的可用数据。 理解经典 GQM GQM 方法提出后，经过了不断的丰富和发展，早期即应用在 NASA、惠普、普华永道、斯伦贝谢、西门子、爱立信、飞利浦、博世、戴姆勒-克莱斯勒、安联、宝洁等各行业先进企业，相关文献和引用比较丰富。 其中，Basili 在马里兰大学的技术报告(Basili(1992))和 2002 年与其他人合作的文章(vanSolingen(2002))是对经典 GQM 较为成熟和完整的阐述，推荐读者参考。 前者适合有研究背景的读者，但其表达和格式上存在一些不足之处，可能影响阅读和理解；后者适合行业中更广泛的读者，但其某些裁剪和简化容易误导实践，下面会逐一指出。 本文综合这两篇和其他文献的主要内容，将经典 GQM 的精华进行了提炼和总结。 整体框架 通过 GQM 雏形的主要实操步骤，我们对该方法已经建立了初步的认知。图 1 展示了方法的整体框架。 图 1 - GQM 框架(vanSolingen(2002)) 这里面需要特别提出的关键概念是模型。 问题本质上是一种定义模型的方法。 这个模型可以是显式的数学模型，也可以是通过问题反映出的在专家头脑中的隐式模型。 GQM 强调有效的研发效能度量必须： 以自上而下的方式定义，聚焦于特定目标； 应用于研发产物、过程和资源的全周期； 基于数据刻画，面向目标，自下而上进行解读。 概念层：目标 目标以通用术语表达组织的信息需要。其定义包括如下部分： 对象（objective）：通常为研发的产物（如代码、文档、测试用例、制品等）、过程（如需求分析、设计、测试等）或资源（如人员、硬件等）。 目的（purpose）：刻画、了解、评价、预测、改进等。 维度（perspective）：成本、缺陷、及时性、准确性、可靠性、性能、用户满意度等。 视角（viewpoint）：用户、开发者、管理者、公司等。 环境（environment）：度量的上下文，包括人员构成、研发模式、编程语言等，用于判断度量间的可比性。 GQM 面向度量目标，与改进目标有所区分(vanSolingen(2002))。 度量为改进行动提供所需信息，即哪里需要改进和如何进行改进。 但实际上，组织最终关心的还是改进目标，度量目标应为改进目标服务。 所以，我们更赞成将改进视作目标的一种目的(Basili(1992))，而改进目标到度量目标的转化可包含在问题和模型中。 视角有一层含义在于区分数据范围，例如项目经理需要及时的进度反馈，而公司可以接受更长时间范围的评价(vanSolingen(2002))。 今天数据极大丰富，又支持快速自动分析，这种区分对后续度量的影响不大，所以视角的主要含义还是不同角色关注不同的目标。 另外，环境这个参数在相关文献中较少展开论述，通常只是由目标项目或团队指代。 它在今天研发效能度量中的主要意义是支持对比，不论组织内部，还是同行之间，多用于以评价为目的的目标。 我们推荐在实践中简化目标定义，不必每一个目标都包含环境要素，只在需要度量间对比时进行定义。 下面我们给出一个目标实例，其自然表述可以拆分出如上各个参数。 ‍ 表 1 - 目标定义实例   操作层：问题 根据目标提出的一系列问题，主要用于刻画目标(vanSolingen(2002))，其中隐含着一个在目标维度上刻画目标对象的模型。 我们通过一个实例来具体理解“刻画”的含义和常见方式。 表 2 - 关于可靠性的问题列表实例   表 2 中的问题并不一定是完备的，可以扩充或裁剪，取决于研发团队实际的信息需要。 这体现出 GQM 方法及其通过问题表达隐式模型的灵活性，从实际应用出发，根据实际情况判断。 通过这些问题，我们可以看到分布和关系是两种典型的刻画方式。 并且，它们都可以通过度量数据采用统计方法计算。 另一方面，这些问题隐含了对“可靠性”的定义。 我们并没有显式描述该定义，但隐含的理解是，可靠性主要反映在已交付系统发生的失败和导致失败背后的软件缺陷上，所以问题才会围绕两者展开。 这种定义是隐式模型的重要组成部分。 ‍我们再举一个更为完备的隐式模型的例子(Basili(1992))。 ‍ 表 3 - 关于缺陷逃逸的问题列表实例 这些问题隐含了对“测试过程”和“缺陷逃逸”的定义，即该公司各项目均经历系统测试和验收测试，我们关注的缺陷逃逸指系统测试这一步。 进而上述问题列表可以转化为如下数学模型： Es = 该项目在系统测试发现的千行缺陷数； Ea = 该项目在验收测试发现的千行缺陷数； Eo = 该项目在发布后发现的千行缺陷数。 令 {Pi} 表示用于对比的同类项目集合，有： PEs = {Pi} 平均在系统测试发现的千行缺陷数； PEa = {Pi} 平均在验收测试发现的千行缺陷数； PEo = {Pi} 平均在发布后发现的千行缺陷数。 进而，令： Fc = 该项目在系统测试发现的千行缺陷数与发现的总千行总缺陷数的比值， 即Fc=Es/(Es+Ea+Eo)； Fs = 同类项目在系统测试发现的千行缺陷数与发现的千行总缺陷数的平均比值， 即Fs=PEs/(PEs+PEa+PEo)。 最终，我们有： QF=Fc/Fs，即该项目系统测试水平与同类项目间的关系。 显而易见，上述各定义与表 3 中的问题是分别对应的。 数学定义更加清晰准确，比如多个项目的“平均比值”有公式就不必担心歧义。 在 GQM 的实际应用中，这种精确性通常依赖问题对应的指标，所以指标的规范化非常重要(OpenMARI)。 ‍ 全面的问题 全面来说，问题包含的几个主要方面如下(Basili(1992))： 定义目标对象： 当目标对象是研发产物：产物所有方面的属性、特征或构成。 当目标对象是研发过程：过程所有方面的属性、特征或构成，以及两种符合性。 过程符合性，刻画过程的模型多大程度上与实际相符合。 领域符合性，过程执行者对所需知识或信息的了解程度。 定义目标维度：应确保该定义的模型适用于目标环境且可收集有效数据。可考虑多个模型，最终度量结果相互印证。 定义目标对象在目标维度上的改进。 对上述符合性的刻画有助于保证度量结论的可靠性，防止忽略过程执行不到位或者执行者偏差等的影响。 在实践中，符合性调研值得推荐，例如询问每位开发者对缺陷标签和判别标准的熟悉程度。 量化层：指标 回答问题所需的指标既可以是客观的，也可以是主观的，但都应当是可量化的。 客观数据通常从研发产物或研发过程中的活动记录乃至上下游业务系统中获得。 今天日益扩展的 DevOps 工具链产生大量的数据可供分析和挖掘。 主观数据可来自对研发团队或用户的问卷调查。 下表给出了表 1 目标下一个问题对应的指标集。 表 4 - 指标回答问题的实例   我们可以看到，这样的指标集中包含了数据分析，如均值、标准差、上下限等统计。 另一种做法是将围绕一个指标的统计学计算都归入指标自身的定义，不再逐一列出。 考虑到统计学方法的通用性，我们更推荐后者。 与问题列表类似，指标集可根据实际信息需要增减。 但有一个重要的理念(Basili(1992))是，如果一个问题的指标集设计包含某指标但实际中该指标无法被度量（可能因为所需数据难以获得等原因），那么该指标同样应该被列出，因为它可能代表了缺失的信息和问题答案的局限性。 现代 GQM 实践指南 今天我们正在进入数据驱动研发效能的时代。 这里提供一份在今天应用 GQM 的最佳实践指南。 它在以往文献和实践的基础上做出的贡献主要有两个方面：一是兼顾本质性和实操性，给出 GQM 的现代化理解，修正了以往认知和实践中的问题；二是从研发组织构建效能度量体系的现实需求出发，对 GQM 的形式进行规范和统一，亦有利于方法论的沉淀和共享。 你想要知道的关于 GQM 的一切都在这里。 基本原理 GQM 本质上是一种因果分析，通过追问合理的问题和进行统计分析实现。 例如，通过回答“缺陷有哪些可判定的类型”、“各类型的缺陷数量的怎样分布”等问题找到导致缺陷的主要原因。 与其他市场或产品等数据分析领域不同，在复杂的生产环境和软件开发过程中，利用对照实验判断影响因素或评价具体实践措施是不现实的。 GQM 的核心思想是通过问题来建立和表达有关研发的模型，解决了显式（数学）模型难以定义的困难，在严谨性和实用性之间找到了合理的平衡。 可以说，GQM 的精髓是一种提问的艺术。 目标 我们将目标定义标准化为如下四个要素。 对象：研发的过程（process）、产物（product）或资源（resource）中的一种。每种对象都可能存在层级结构。 研发的交付过程，由需求、设计、开发、测试、发布、运营等组成；每个过程还可以进一步下钻。 产物包括软件、文档、制品等。以软件为例，它可以下钻到组件、函数；同时，它的组成还包括缺陷、变更等研发过程中的产物。 资源包括人员、设备等。人员组成团队，形成层级结构。 维度：目标聚焦的角度或对象的属性。 参考认知域的划分，速度、质量、价值、成本、能力都可作为一种维度。 这是一个开放的集合，实际中目标可以有更细的维度。 目的：了解（understanding）、评价（evaluation）、改进（improvement）、控制（control）和预测（prediction）中的一种。 了解是认知研发效能的第一步，也是评价、改进、控制和预测的基础。 在了解的基础上，通过与历史、同类或基准的对比产生评价，评价中定位的差距需要改进。 改进最终体现为指标的提升或降低。 除了改进，有些目标是为了控制指标在合理的范围内。 了解、评价、改进和控制都是针对现状，预测则是面向未来，帮助我们提前实施改进和控制。 角色：组织中谁会关注该目标，通常为开发者（developer）、项目经理（project manager）、技术经理（tech lead）、高层管理者（executive）中的一个或多个。 组织中的目标体系，核心是按照对象、维度和目的三个要素组织，它们直接影响目标的定义。 而角色可以作为目标的一种标签，主要标记谁会关注该目标。 问题 ‍ 问题是对模型的定义，该模型一方面是对目标及其各要素的拆解和刻画，另一方面为数据解读为目标提供框架和途径。 问题的设立会帮助我们根据数据分析目标进行数据收集，而不是先收集数据才发现遗漏或者无用功。 例如，开发者需要给事务打哪些标签，应考虑后续数据分析要回答的问题来进行设计。 缺失标签会降低数据质量，多余或混乱的标签会浪费研发团队的时间。 完备的参考问题列表，一方面方便实践者选择或裁剪，另一方面提供多种模型，可支持度量结果的交叉验证。 为了规范和简洁，参考问题可包含参数。 这些参数通常反映隐式模型的定义，实践中根据具体应用环境设定。 例如，需求多长时间交付的问题，可把需求交付的阶段划分（即交付过程的组成部分）作为参数。 实际应用时，当前项目采用的具体阶段划分，即是对该项目交付过程模型的一种具体定义。 当目标包含层级结构时，每一层目标都有与之对应的问题。问题可针对当前目标对象（即其整体和现状）提出，也可深入其组成部分、历史周期，或者与其他同类对象进行对比。 几种目的下，对应这几类范围的问题有一些典型的提问方式，可总结为表 5。 不同目的和范围下的典型问题 指标 指标的明确定义和规范化是解决问题描述可能存在的模糊和歧义的关键。 完备的参考指标列表，一方面方便实践者选择或裁剪，另一方面提供相关指标，可支持对问题更全面的理解。 为了规范和简洁，以指标为基础的各类统计，归入对应指标的分析方法，而不单列为另外的指标。 常见的分析方法有： 数值分布：指标数值作为随机变量，计算其分布或分布的统计量（如均值、方差、上下限等）。 多用于回答了解对象现状的问题。 时序分布：按时间顺序分析指标数值，即时间维度上的分布。 回答面向历史数据的问题通常以此为基础。 分类分布：将对象的组成部分分类后，进行统计分析。 如缺陷按所在模块分类，统计各模块缺陷的数量。 该方法在了解对象组成部分的场景下应用广泛。 对比分析：通过指标数值间的比较量化差距，多用于回答评价类问题。 帕累托分析：将组成部分或影响因素的指标排序，定位影响最大或最主要的部分，常用于改进或控制。 相关分析：运用各类统计方法找到指标间的正负相关性，常用于改进或控制。 拟合建模：运用各类统计方法找到有效预测指标的数学模型。 参考文献 V. R. Basili and D. M. Weiss, "A Methodology for Collecting Valid Software Engineering Data," in IEEE Transactions on Software Engineering, vol. SE-10, no. 6, pp. 728-738, Nov. 1984. https://doi.org/10.1109/TSE.1984.5010301 OpenMARI项目．开源指标体系和效能提升指南．网站：https://www.openmari.dev V. Basili, "Software Modeling and Measurement: The Goal/Question/Metric Paradigm," University of Maryland, CS-TR-2956, UMIACS-TR-92-96, September 1992. https://hdl.handle.net/1903/7538 van Solingen, R., (Revision), Basili, V., (Original article, 1994 ed.), Caldiera, G., (Original article, 1994 ed.) and Rombach, H.D., (Original article, 1994 ed.) (2002). Goal Question Metric (GQM) Approach. In Encyclopedia of Software Engineering, J.J. Marciniak (Ed.). https://doi.org/10.1002/0471028959.sof142

如何在 15 分钟内度量 DORA 指标？

在这篇文章中，我们将介绍 DevOps 四个关键指标——DORA 指标，DORA 指标的度量难点，以及如何基于开源工具快速实现 DORA 指标的度量和持续追踪。如果你熟悉 DORA 指标，可以直接跳到本文第二部分。 1. 什么是 DORA 指标？ DORA 的全称是  DevOps Research and Assessment，是一个致力于 DevOps 调研与研究的组织，2018 年加入 Google Cloud。自 2014 年起，DORA 每年会发布一份行业报告，基于对数千名从业者的调研，分析高效能团队与低效能团队在 DevOps 实践上的差异。 高效能团队如何定义？可能每个人、每个组织都有不同见解。DORA 的做法是将研发团队表现分为三个方面：软件交付表现、运行稳定性表现和组织业绩表现。在软件交付表现方面，提炼出四个关键的结果性指标进行概括，这就是著名的 DORA 指标。DORA 指标包括 部署频率（Deployment Frequency）：一段时间内应用程序部署到生产中的次数，代表研发团队交付价值的频率 变更交付周期（Lead Time for Changes）：从代码提交到将代码部署到生产中的时长，代表团队进行代码评审、测试和部署的速度，也部分反映了团队响应用户需求的速度 变更失败率（Change Failure Rate）：变更部署到生产后发生故障、导致服务降级的比例，代表团队交付稳定服务的能力 服务恢复时间（Time to Restore Service）：生产环境中发生故障到服务恢复的时间，代表团队快速监测、定位、诊断故障，并从故障中快速恢复的能力 在以上四个指标中，部署频率和变更交付周期指标主要度量的是 DevOps 交付表现中的产能维度（Throughput），而变更失败率和服务恢复时间指标主要度量的是稳定性维度（Stablity）。 同时度量产能与稳定性，一方面能使二者相互制衡，避免大量低质量变更损害用户体验，或避免严守质量拖累交付效率；另一方面，验证优秀的实践能够同时改善产能与稳定性，而不需要研发团队做出取舍，例如小批次的发布策略不仅直接提高部署频率，一旦故障发生也能快速定位，有利于缩短服务恢复时间。 DORA 指标如何指导具体的实践改进？DORA 调研报告贴心地提供了一系列基准值，分为精英团队（Elite）、高效能团队（High）、中等效能团队（Medium）和低效能团队（Low）。研发团队可以参考业界水平对号入座，从而找到最关键的改进项，并在改进的同时持续度量 DORA 指标，验证改进措施的有效性。 2. 度量 DORA 指标，难在哪？ DORA 指标并不是什么新鲜事物，指标只有四个，公式也非常简单明了。但对于许多研发团队来说，要在日常工作中持续自动化地度量 DORA 指标，依然难度不小。 困难在于，DORA 指标度量依赖于变更、部署、故障等研发数据，而许多研发团队并没有获取研发数据的可靠基础设施： 首先，研发过程本身是复杂的，通常涉及多个流程、活动和工具，研发过程数据也常常散落在复杂的工具链中（包括代码托管、事务管理、CI/CD 工具等），导致数据难以提取，耗时费力。如果研发团队同时使用同类型的多个研发工具，可能还需要处理不一致的数据概念，比如同一公司内部分团队使用 GitHub 部分团队使用 GitLab，就需要统一 Pull Request 和 Merge Request 两个概念。 其次，不同的组织和项目的研发和交付过程不同，可能会采用不同的数据定义和计算方法。比如，有的团队使用Git Tag 或某特定分支的合并来识别一次部署，有的团队使用 CI/CD 工具中的事件来识别一次部署。这样非标准化的定义与计算方法，也使得研发数据难以治理，进而给数据的可靠性打了一个问号。 市面上 DORA 指标工具之多，也从侧面印证了这仅仅四个指标的度量并非易事。如果某个团队考虑度量 DORA 指标，他们可能需要对比市面上的数十个工具，眼花缭乱中找到恰好能接入当前研发工具链，恰好变更、部署、故障的定义均符合团队实践的那一个 不同工具所支持的数据源和指标计算方式各有差异 而这也正是我们建设并开源了研发数据平台 Apache DevLake 的原因。我们认为，无论是研发工具链的接入以及研发数据的定义，都应当保留一定程度的开放和灵活性。团队根据实际需求收集并治理研发数据，保障数据可靠，在此基础上度量 DORA 指标，并获得有价值的改进洞见。 开源的模式降低了研发数据的治理成本，同时也吸引更多团队参与建设，不断丰富可接入的数据源和数据计算方法，让平台越用越好用。 3. 基于 Apache DevLake 快速度量 DORA 指标 正如上文所说，度量 DORA 指标前，你需要先拿到三个研发数据： 变更：大多数团队是通过 Pull Requet 来识别一次变更，因此变更的数据将来自代码托管工具，DevLake目前已支持 GitHub、GitLab 和 BitBucket 部署：部署的数据来自 CI/CD工具。DevLake 目前已支持 Jenkins、GitHub Actions 和 GitLab CI，CircleCI 正在开发中 故障：故障的数据可以来自事务管理工具中的某类型事务，例如 Crash或 Incident；也可以直接来自监控工具，DevLake 将很快支持 PagerDuty 和 Sentry。 除了手动触发数据收集，DevLake 也支持自动定时拉取研发数据，方便研发团队低门槛地使用 DORA 指标，持续追踪效能表现。 如果 DevLake 尚未支持你的研发工具，你依然可以使用 webhook 将事件数据推送到 DevLake。 接下来，只需四步，就可以在 DevLake 中看到 DORA 指标和数据看板： 配置 DevLake：使用 Docker Compose、Kubernetes、Helm 或 Temporal 收集数据：借助 DevLake 插件接入研发工具链，不需要复杂的集成与适配，就可以把需求、开发、测试、交付各个环节研发数据归于一处 数据看板开箱即用：DevLake 预置了许多指标和数据看板并通过 Grafana 来呈现，其中包括 DORA 指标和相应看板 自定义：如果你还需要进一步分析，例如探查某个 DORA 指标异常的原因，只需要几行 SQL 查询就可以创建新的指标或数据看板

4.0 功能抢先看 | 读懂一个项目的研发效能 之 项目交付效率

思码逸企业版 4.0 的部分功能已进入内测阶段✨近期我们会用几篇文章，浅剧透一下 4.0 的新鲜功能。 最近几篇的主题将是 4.0 版本中的 GQM 看板——GQM 代表 Goal-Question-Metric（目标-问题-指标），是一套构建软件研发效能度量的系统方法。简单来说，GQM 方法强调面向清晰具体的目标，自上而下拆解，通过问题建立研发的度量模型 + 基于量化数据分析来回答问题，自下而上解读并达成目标。更多解读可以查看《研发效能度量体系构建的根本方法——GQM 从入门到精通》。 相比大多数所谓『数据看板』，GQM 看板的进化在于数据不再是简单罗列、看得人一头雾水，而是用来回答具体场景、具体度量目标下的某个具体问题。 我们相信，优秀的效能度量，一定不会是难懂的。我们希望即使是不太了解研发效能领域知识的一线研发管理者，也能低成本理解每个指标的含义和指标给出的信息，实实在在将度量用起来，解决他们在研发管理中的遇到的各类“看不清”“说不明”。 接下来的内容，我们将介绍 GQM 看板中的『项目交付效率看板』。 0. 研发效率，为什么总被抱怨？ 工程师们有时可能不理解：明明研发团队已经像开足的马达全速运转，每个人都在认真积极地工作，为什么业务侧还在抱怨研发效率低？ 其实，就和大多数消费者更关注车速，而非马达转速同理。从业务同事到最终用户，他们可能没那么关心研发团队是否全情投入、工程实践如何先进高效、技术层面的指标有了多少提升，而更关心他们的需求能多快被满足。 如果各方在对“效率”的定义上未达成共识，沟通障碍当然在所难免。 阿里的何勉老师曾分享过研发效率的两个视角：资源效率与流动效率。前者着眼于资源的利用率，后者则更关注端到端的价值交付。项目本就是为了给用户交付价值，当我们度量“项目效率”时，很有可能会优先关注后者。 何勉《阿里如何定义团队的研发效能？》 可以说，交付效率数据是串联起研发与业务部门间理解和沟通的桥梁。它将研发产出翻译为业务侧可理解的语言——研发团队是否能按预期交付功能？交付需要多长时间？研发团队近期的工作重心是什么？ 基于对这些关键信息的共识，业务与产研可以打出默契配合，在对的时间把对的产品推向对的市场。而对于研发团队自身来说，不仅能够对“前线炮火声”更敏捷地做出响应，也是让合作方看到研发团队价值的好机会。 接下来我们回到看板，详细聊聊“认知各项目的交付速率”这一目标下的几个具体问题。首先，我们会从事务交付出发，度量端到端的交付情况；其次，我们会回到代码交付的视角，尝试分析研发团队的改进方向，以支持更高效的交付。 1. 项目的事务交付速率如何？ 从交付视角看效率，事务（issue）自然是最重要的度量单位之一。事务可以是一个需求/一个待修复的缺陷/一个任务，比代码行数更具有业务意义，能够更好地反映项目的交付工作量和进度。 为了回答“事务交付速率”问题，我们选取了三个指标：事务吞吐量、事务前置时间（P85）和事务颗粒度。 事务吞吐量：即单位时间事务交付的数量，在图中表现为纵轴坐标。 事务前置时间（P85）：即使产量不低，如果每个事务都得等上几个月时间，业务方依然会叫苦不迭。事务前置时间即事务从提出到交付上线的总时长，在图中表现为横轴坐标。P85 表示项目中前 85%事务能在该时间段内完成交付，相比中位数，85%分位值更能反映事务交付速率的普遍情况。 事务颗粒度：事务颗粒度即事务平均代码当量，在图中表现为圆点的大小，在第二节会有更详细的介绍。 这个指标，一是起到交叉验证、辅助说明的作用：如果某个项目（例如图中右下角的场景团队）事务拆分不够细，可能会导致任务高度耦合、测试成本高、修改难度大，不仅事务交付数量下降，前置时间也会显著拉长；二是起到保障度量可信的围栏指标的作用：如果事务本身大小不一，那么基于事务数度量的交付效率是否可靠都要打个问号。 将三个指标放在象限图中，能够帮助研发团队横向对比阶段/业务属性/规模相似的项目，并快速找到交付偏慢、需要重点关注的项目。 点击项目圆点，即可下钻了解该时间段内该项目的迭代表现，包括研发各环节时长、迭代计划达成情况等，再进一步下钻找到卡点。 研发各环节的流转时长分布 2. 项目的事务颗粒度是否控制在合理区间？ 前面提到了用事务数来评估交付速率。实际上，很多项目管理工具也能直接统计事务数。你可能要问，那思码逸的交付效率看板有什么区别呢？ 关键在于，对于许多团队而言，“事务”这个工作量单位本身就不稳定，基于事务的度量也就不那么可信。如果需求颗粒度上下波动大，有些事务的交付周期长达几个月，另一些只需几小时，用简单一个事务数来概括显然是不合理的。 只关注事务数不顾颗粒度，开发者们当然首选轻松愉快的小任务 如果您的团队正属于这种情况，可以先选用事务与代码脱钩版本的交付效率看板，同时开始度量事务的颗粒度，并逐步控制到合理区间内。 思码逸使用代码当量指标（如果您不太了解代码当量，可以查看【代码当量的链接】）来度量事务的颗粒度大小。您可以在看板中看到： 不同项目的事务颗粒度分布是否合理。 箱体过宽代表颗粒度忽大忽小，箱体位置过高代表颗粒度普遍偏大 某项目的事务颗粒度的历史变化趋势 某项目的事务颗粒度在不同区间内的分布 某项目中哪些事务的颗粒度偏大，以及这些事务在代码工作总量中的占比 通过层层下钻，研发团队可以快速找到需求颗粒度欠佳的项目>找到这些项目中具体待改进的事务>对这些事务进行针对性的复盘分析>得出具体的改进措施。 合理控制需求颗粒度，是得到项目交付效率度量的前提。不仅管理者可以看到更有参考价值的度量结果，一线的开发者们也将受益于更准确的交付带宽估算。 3. 研发资源是否能支持更快交付？ 有时会出现这样的情况：事务吞吐量挺高，前置时间也短，这下交付效率总该过关了吧？正准备美美表扬下自己和研发同事们，业务同事又友好地出现了： Surprise！还有这么多用户需求已经等了半年啦！ 为什么研发团队交付又快又多，但业务方还在抱怨慢？ 可能性一，受客观因素影响，研发交付物不得不频繁偏离预期。本来迭代计划了五个新功能，事实上事故一个接一个，工程师们忙着救火都来不及，新功能只能在喘气的间隙穿插着做。到了迭代结束，只能交付一个功能。对于期待着新功能的用户和业务方来说，体感上交付效率就是慢了几倍。 可能性二，产研重心和业务战略重心没能对齐。比如，当前阶段业务重心在于改进用户体验，提高留存率，而产研侧忙着埋头开发新功能。劲没往一处使，可能就会事倍功半。 以上两种情况，研发资源是足以支持更快交付的，但宝贵的研发资源或多或少被临时挤占或错配，才导致效率不如人意。 思码逸以代码当量为基础数据，关联分析事务交付与代码产能，分析研发团队在新功能、缺陷、线上事故等不同事务上的工作量分布。如果是经常忙着救火，也许可以考虑留出一段时间做质量专项改进，帮助团队在后续工作中轻装上阵；如果是重心出现了偏差，那么可以及时转舵，帮助团队集中精力于最关键的交付。 可能性三，研发团队自身的交付效率是没问题的，是任务频繁变更导致研发的许多辛勤工作都成了无用功。这种情况，卡点主要是在研发以外环节，就需要与业务和产品部门一起坐下来聊聊需求质量如何优化，调动上下游协同提效。 可能性四，对比历史数据，当前产能已经处于较高水平，交付也符合预期，那么交付效率方面的提升空间已经不大了。要满足业务侧的需求，则需要结合人效再进一步分析，想办法提高产能。 以上两种情况，研发团队可以使用代码产能趋势图，来佐证代码交付处于健康状态。 需要提醒的是，数据分析更多起到的是客观度量、提供建议、排除部分可能性、并引导层层下钻的作用，其本身往往难以直接得出行动项。不管交付效率的具体阻碍项是什么，在排查的过程中，由开发者参与的复盘和讨论是必不可少的。 总结 项目交付效率度量的是业务侧和终端用户可理解的研发产出，其端到端的全局视角能够协助研发团队制订出真正有效的改进目标，这也是许多高层管理者最关心的部分。但改进目标如何实现呢？这也是交付效率的局限所在： 交付效率只能在产能不变的前提下，帮助研发团队调整重心，交付更有价值的产物。但效率提升，很多时候还是离不开产能，也就是人效/资源效率方面的提升。在寻找具体的改进方向时，研发团队需要将综合分析交付效率与人效，下钻分析找到关键症结，进而找到最适合自己的提效路径。

4.0 功能抢先看 | 读懂一个项目的研发效能 之 项目人效

思码逸企业版 4.0 的部分功能已进入内测阶段✨近期我们会用几篇文章，浅剧透一下 4.0 的新鲜功能。 最近几篇的主题将是 4.0 版本中的 GQM 看板——GQM 代表 Goal-Question-Metric（目标-问题-指标），是一套构建软件研发效能度量的系统方法。简单来说，GQM 方法强调面向清晰具体的目标，自上而下拆解，通过问题建立研发的度量模型 + 基于量化数据分析来回答问题，自下而上解读并达成目标。 相比大多数所谓『数据看板』，GQM 看板的进化在于数据不再是简单罗列、看得人一头雾水；而是先将具体场景下的具体度量目标拆解成问题，再由问题引出指标图表，以递进的方式传递信息，并引导用户适时下钻探索。 我们认为，优秀的效能度量一定不会是难懂的。我们希望即使是不太了解研发效能领域知识的一线研发管理者，也能低成本理解每个指标的含义和指标给出的信息，实实在在将度量用起来，解决他们在研发管理中的遇到的各类“看不清”“说不明”。 上一篇文章中，我们介绍了我们将介绍 GQM 看板中的『项目交付效率看板』，这一篇将继续介绍『项目人效看板』。 0. 研发人效度量，为什么如此尴尬？ 上一篇文章我们提到过，研发效率最终应当体现在交付效率（或者叫流动效率）上，让价值接收方感到交付物更多、响应更及时、研发目标更快速达成。 而与交付效率相对的人效，或者叫资源效率，虽然常备诟病，但依然是研发效效率中的绕不开的话题。 何勉《阿里如何定义团队的研发效能？》 一方面，人效的度量与改进确实有存在的必要。 仅在交付效率上下功夫的改进，例如加强跨部门沟通协调、减少等待，确实能使交付更快；例如调整研发投入重心与业务方向匹配，确实能使交付的软件功能更符合市场期望。但本质上，这些措施都是在产能不变情况下优化产能分配。如果产能本身处于偏低水平，不论如何优化分配，改进效果可能都是有限的。因此人效的提升是交付效率提升的重要手段之一。 另一方面，人效度量又因常常跑偏到强管理导向和“反人性”，而饱受争议。 对于管理者，尤其是没那么懂技术的管理者来说，工时、工作饱和度（执行任务的时长/总工时）、代码行数这样的指标更容易理解，因此常常被用来度量研发的人效。这些指标似乎给管理者提供了一种“监督员工们没摸鱼没划水，工资才算没白给”的安全感。 但软件研发毕竟是脑力劳动，开发者们不是生产代码的机器，不可能每天从早到晚精神抖擞全速运转。这就导致开发者和管理者之间痛苦且双输的博弈：开发者或想尽办法来绕过度量，或在高压下忙忙碌碌，变得疲惫、麻木和缺乏创造力，部分成员因此离开；管理者们可能如愿以偿看到人效指标上升，最后才发现这个数字和真正的效率提升并没有必然联系，可能还是负相关的。 再热爱工作，连轴转太久也只能交付bullshit 研发人效度量如此尴尬，背后是常常跑偏的度量设计和使用。这也是思码逸希望提供加可靠、有正向引导作用的人效看板的原因。 1. 人效度量，先选对指标 交付效率侧重于刻画端到端的交付表现，业务、产品、研发、测试各环节内部和它们之间的流转协调都会造成影响。而人效度量侧重于内部评估研发团队的交付能力，研发 Leader 们需要的是仅与研发环节相关的指标。 前面提到，常见的工时、工作饱和度指标多把开发者作为需要时时刻刻运转的资源，而非有创造力的人，因此广受诟病；而代码行数指标，则很可能错误地引导开发者们多敲空行、多写不必要的复杂函数来造数据，进而导致代码可读性和可维护性急剧下降，本质上使研发效率更加恶化。 思码逸选择人均代码当量和人均事务吞吐量作为北极星指标，来表示项目组的人效水平。 代码当量和代码行数一样是基于代码的工作量指标，但排除了代码风格、换行习惯等噪音干扰，且调整了移动、粘贴、数据修改等修改的权重，因此更鼓励重要且有创造性的工作。 事务吞吐量则是基于任务的工作量指标，能够更好地与项目交付进度相关联，但可能会受到事务颗粒度大小不一的影响。 因此，两个指标同时使用，能够可靠简洁地说明各项目的人均开发效率，及时挖掘内部最佳实践，或及时发现状态不佳的项目，再到其他图表进一步了解问题的原因。 如果需要深入了解某一项目人效的具体信息，思码逸支持下钻分析，呈现项目人效趋势，并自动识别偏高或偏低的潜在异常点。如果贡献者人数频繁波动，则可能需要重点关注开发者专注度，我们会在第三部分介绍。 在此基础上，思码逸也将工时指标纳入分析。但工时不代表任何产出或工作量，而是研发团队和开发者的资源投入。将代码当量和事务吞吐量与工时交叉分析，则可以量化研发团队内部的投产比。这样的度量也有助于开发者们更专注于交付结果，而非磨洋工凑时长。需要留意的是，不同职能团队、不同类型项目的工时投产比可能相差很大，不经筛选的横向比较可能是欠妥的。 2. 参考行业基线，客观评估人效水平 代码当量和事务吞吐量两个指标量化了项目人效，但对于研发团队而言，数字的理解是有门槛的：这些数字代表了什么？四象限图表明，某个项目的人效在公司内处于上游，那么与行业对比如何？ 根据项目语言和团队规模属性，思码逸能够自动匹配行业近似项目，为人效数据的解读提供参考基线，帮助团队客观认知当前人效水平，合理制定提效目标。 但这里提醒一句，项目的发展阶段、业务属性等也会对人效造成影响。例如，成熟期的项目，其人效可能会低于起步期的项目，一方面是任务比后者少，另一方面是“历史包袱”也更重，改动需更小心谨慎。因此，在判断项目人效时，还是结合项目的实际需求进行分析。 3. 深入分析贡献分布与人力专注度 接着前面的例子，项目到了成熟期，人效下降，Leader 们开始考虑：本项目是不是不需要那么多人参与了？是否可以把部分研发人力分到别的项目上？毕竟，研发人力成本如此昂贵，自然不希望空转导致浪费。 今日分工：90%项目成员等着10%成员完成任务 这时候，就需要更精细的项目人效分析登场了。 首先，可以先通过项目贡献均衡度图表，判断有多少开发者是作为项目主力军工作。贡献均衡度的定义是贡献80%工作量的开发者比例。如果均衡度较低，则项目大部分人力可能都是辅助角色，如果转移到新项目上，需要交接的工作也不会太多。 接着，我们可以下钻到某一项目内，继续验证均衡度是否走低，并通过产出分布帕累托图来判断工作是否逐渐集中在少数几位核心开发者，谁是核心开发者 那么，非核心开发者们是还参与着其他项目，还是处于空转状态呢？人力专注度图表可以帮助我们直观了解。 如果许多非核心开发者仅专注于此项目，但代码产出和事务吞吐数又不高，则可能正处于空转状态。如果许多非核心开发者同时在开发其他项目，则需要结合新旧项目之间的关联，来判断开发者同时参与多个项目是否合理；若新旧项目之间关系不大，则可以考虑帮助开发者交接剩余工作，并完全转移到新项目上，减少上下文频繁切换造成的浪费。 另一种情形是，项目加班严重却频频延期，贡献高度集中于几位核心开发者。这种情况则可以结合产出分布的详情和专注度数据，辨别是项目人手确实不足，需要频繁抽调其他项目人员支持；或是任务太过耦合，核心开发者超负荷工作，而其他成员帮不上忙；亦或是项目人员结构不恰当，导致部分人员没有任务可做。 需要提醒的是，数据分析更多起到的是客观度量、提供建议、排除部分可能性、并引导层层下钻的作用，其本身往往难以直接得出行动项。排查项目人效问题的过程中，由开发者参与的复盘和讨论是必不可少的。 我们可以将贡献均衡度和人力专注度理解为人效的健康指标：持续超负荷工作、贡献过于集中、成员同时投入在多个不相关项目都是不健康的。不健康的情况下，人效可能依然很高，但大概率是不可持续（例如团队加班累垮）或风险巨大（例如核心成员离职）的。 总结 项目人效度量的是研发内部的研发产出。尽管这些产出不直接等同于业务侧和终端用户感受到的价值，但它代表了研发部门支持价值交付的带宽。在以提升交付效率为最终目的的改进中，提升研发人效是必不可少的路径之一。而人效度量的尴尬，大多数情况下正是由于混淆了路径和目的。 在厘清概念的基础上，谨慎选用具有正向引导作用的度量指标，在合适的参考系下进行解读，在关注人效数字的同时重视健康度，并适时下钻到关键单点内，通过案例复盘来排查人效的影响因素。这样的度量和解读的方法，能够帮助研发团队避免掉进数字的陷阱，而是去发现和追问真正的效率问题。