数据驱动研发效能：指标、系统与实践

本文内容节选自12月15日，由msup主办的第十一届全球软件案例研究峰会，思码逸 CEO任晶磊分享的《数据驱动研发效能：指标、系统与实践》案例实录。

分享者任晶磊，

• 清华⼤学计算机系博⼠，前微软亚洲研究院研究员，斯坦福⼤学、卡内基梅隆⼤学访问学者

•《软件研发效能度量规范》标准核⼼起草专家

• 在 FSE、OSDI 等顶级国际学术会议上发表多篇论⽂

• 参与过微软下⼀代服务器架构的设计与实施，获得 4 项美国发明专利

• Apache DevLake、CNCF DevStream 开源核⼼贡献者

目录

• “低增长”新常态，对程序员意味着什么？

• 研发效能的驱动力

• 数据驱动研发效能的四个阶段

• 数据驱动研发效能的实现和案例

演讲全文

01

“低增长”新常态意味着什么

今年刘润在年度演讲当中总结了四个关键词，“意外、周期、趋势、规划”，这四个词对于当下这个不确定性的世界是非常重要的。

我们正处在一个经济下行的周期，软件行业大小厂都在做降本增效的动作，同时，我们已经开始进入了一个低增长的新常态。这里的所谓的“低”主要意味着更低的速度或者增量比较小，但很多时候它也意味着更高的质量，至少从商业的角度来看，盈利性的增长本身其实是更加健康的一个状态。工程侧其实也是一样，现在大家更加关注精细化的运营、最佳的软件工程实践。

总体而言，当前周期增长放缓，保证软件工程高质量和健康状态成为关键，研发效能升级、研发管理精细化是大势所趋。要实现效能提升与管理精细，数据是必不可少的一环，没有数据的话就无法度量，无法客观地评估现状、发现并解决问题。因此，数据是研发效能建设的重要基础。

02

研发效能的驱动力

流程、工具、数据是软件研发效能的三个主要驱动力。

03

数据驱动研发效能的四个阶段

第一个阶段是数据积累，这个阶段的特征是大家有意识积累研发数据，将其视为资产和信息源。在这个阶段容易出现的错误做法是追求指标多而全，执着于个别指标的高低。这个阶段的最佳实践，一方面是避免刚才提及的陷阱，另外一方面推荐大家拿来主义，利用开源工具和业界沉淀的指标模型，快速跨越数据治理的鸿沟。

第二个阶段是数据夯实，这个阶段的特征是维护数据健康度，建立高质量数据源。在这个阶段，面临的挑战是缺乏可靠的数据基座，在指标上虚假繁荣。我们推荐的最佳实践是采用代码分析数据，并与其他领域数据交叉关联，保障研发数据的可信度。

第三个阶段是自主分析，这个阶段的特征是利用BI或可视化工具，从数据中解读信息。在这个阶段，容易出现的错误或者陷阱是围绕数据而非目标；缺乏适合研发模型的下钻，只能满足浅层信息需要。我们推荐的最佳实践是采用GQM（目标-问题-指标）方法，通过合理下探推动 MARI（度量-分析-回顾-改进）循环。

第四个阶段是系统洞察，这个阶段进入了一个相对大家期待和理想的状态了。这个阶段的特征是以目标为导向，基于健康的数据，合理分析和洞察。在这个阶段，面临的挑战是分析需求多种多样且存在特异性，而分析师资源有限，无法在组织中规模化应用。这个阶段的最佳实践，是参考规范化 GQM 模板，自主实现洞察和 MARI 循环；在此基础上结合组织的个性化需求丰富洞察模板，沉淀为组织内可复用的知识。

接下来我们用一些例子来说明以上四个阶段的具体实践。

数据驱动研发效能的实践和案例Ⅰ

第一个阶段开始进入数据驱动研发效能的状态，左边是实际的微信对话截图，这是很典型的场景。大家有研发数据的信息需要，就开始找工具进行构建，所以前面提到的最佳实践推荐给大家可以直接构建系统。Apache拥有丰富的数据生态，其中目前唯一的垂直于研发数据治理的领域就是Apache DevLake，开源的研发大数据平台，主要功能是通过各种插件接口，将DevOps工具链里各种各样的数据集中到数据湖当中，这个数据汇集进来后有一个建模的过程，不同的工具有些是需求域（JIRA等项目管理工具）、有些代码域（GitHub等代码托管工具），不同的领域都有相应的建模数据。汇集数据之后，先将数据映射到标准实体上，就可以借助平台生成相应的分析和洞察。

上图是成熟社区ClickHouse的指标。两个链接是其完整的看板。我们截取了其中的一部分，左上角截屏是围绕质量的，可以看到bug在不同版本之间的分布，还计算了每个版本当中bug fix所占的比例。这是很多开发团队所关注的点，希望在每个版本中花一些精力在bug fix上，但又不希望占用精力过多，bug fix过多可能意味着出现了较严重的质量问题，或者团队过多关注bug而相对忽略了新特性开发。左下角是一个工作的分配，是对项目管理同学很好用的一个看板，也是按照ClickHouse的要求做的，可以看出团队中的每位开发者承担了多少不同类型的任务，以及任务完成的情况。

数据驱动研发效能的实践和案例Ⅱ

第二个阶段，我们先找到相对可信的内核，基于它去校验其他的数据，然后再去校验更多的数据，构造一个分层的结构，中间这个核是可靠数据基。

将代码相关的指标作为可靠数据基呢？我们采用了是最左边的图所展示的算法，将源代码抽象成一棵树，求代码修改前后两棵树之间的最小步长，这样来算它的复杂度，作为更加可靠客观的代码量统计，我们称之为代码当量。

在此基础上，它就可以进一步的校准其他的指标。最右边的图举了一些例子，比如说需求这侧，我们常用的指标是需求吞吐量和需求交付时长，这两个是评价需求响应快慢的最基本指标，就像评价网络快慢会看带宽和延迟一样的道理。数据如果不做校准，大家难免有一个倾向，即把需求颗粒度拆得非常小，拆得越小自然吞吐量上去了，延迟也下来了，但这样做显然是一个虚荣的做法。有了代码当量之后，可以拿当量和需求做交叉分析，从而控制好需求颗粒度，校准后的需求指标会比较可靠。

右边缺陷与需求颗粒度类似，在合理的前提下希望它比较小，但也不能过于小，需要做统计上的控制。

上图我们可以看到，一个是中国领先的新居住服务平台，他们拿需求和代码当量进行关联分析，同时看需求吞吐量和需求颗粒度两个数据。左边的图是他们建立了需求颗粒度均值和上下合理范围的基线，如果超过基线范围会告警。右边是TiDB的数据，显示千当量 bug 率比千行 bug 率更稳定（离散系数低），更适用于评估版本质量。

数据驱动研发效能的实践和案例Ⅲ

我们推荐GQM（目标-问题-指标）方法来建立研发效能度量。这套方法在欧美已经应用多年，被称为“事实标准”，它强调先自上而下，后自下而上:定义目标、拆解问题、拆解指标，得到一套服务于目标的度量体系；度量得到数据后，这些数据可以用于分析，回答一些问题，进而达成目标。更详细的介绍，大家可以去右下角的链接《GQM从入门到精通》查看。

GQM更多支持了效能的度量（Measure）和分析（Analyze）。要让整个研效跑起来，后面还有两个步骤，即回顾（Review）和改进（Improve）。这四个环节加起来形成了一个MARI循环。

做完分析之后，大家坐在一起回顾分析的结果，结合实际的判断，找到真正的根因，挖到合理的信息，我们也非常强调回顾人+数据这一步。

没有数据是可怕的，但只相信或者只通过数据解决问题这是更加可怕的。最后有了判断之后可以小步实施一些改进，采用精益MVP方式探索改进措施。最后，推荐大家去右下角阅读字节跳动的实践，他们在实践中运用了GQM方法来构建度量，也有将MARI用于设计持续改进的闭环。

数据驱动研发效能的实践和案例Ⅳ

最后就是进入系统化洞察，比较高阶的状态了，这一部分我们也沉淀了一些标准化的经验。举个例子，我们要认知各团队/项目的交付速率，针对这样一个目标，我们列了三个最顶层的问题，很显然要看需求交付的情况、代码交付的情况、同时从制衡保障数据可靠的角度考虑，第三个问题是需求颗粒度，所以结构非常简单，两个关键的角度，再加上他们之间的关联关系，三个问题共同支撑了“了解交付速率”这个目标。

左边是需求交付速率的图表，前面也提到需求交付速率可以包含两个角度，一个是前置时间，另一个是吞吐量。通过二维图表，看出不同项目在两个维度下各自表现怎么样。

右边就是通过代码当量去看交付速率，可以各个项目间横向对比，也可以拆分看多少代码工作量是花在需求/缺陷/其他类型的任务上，并且可以配合贡献人数来呈现。

大家看到了这些指标，很自然会想看到更细粒度的情况，这时候就需要下探分析。下探的角度包括具体看它的子对象，或者过去某段时间的表现。最终的落脚点是到需要关注的具体对象，比如某几个需求或某几个提交。

以上内容来自任晶磊老师的分享。