‍

阅读本文你将收获：

1、什么样的程序员是靠谱的？

2、合理量化评估程序员工作量指标：代码当量

3、研发效能度量中的三个应用场景

‍

前言：本文内容节录于思码逸Merico CEO 任晶磊在51CTO 与腾讯云TVP 精心打造的 LeaTech 全球CTO领导力峰会进行的主题分享。基于对研发效能领域的全面认知，他分享了深度代码分析在研发效能度量中的落地场景，本文结合演讲内容对研发效能度量总结了三点重要内容

以下为任晶磊演讲实录:

‍

管理学大师Peter Drucker曾说：“无法度量，就无法管理与改进。”作为技术管理者，提升研发效能是永恒的追求。因此，研发效能度量是必不可少的工具或能力，而代码分析在其中扮演了重要的核心角色。这篇文章将介绍深度代码分析在研发效能度量中的三个应用场景。

‍

什么样的程序员是靠谱的程序员

‍

先思考一个问题：什么样的程序员是靠谱的程序员？你希望你的团队成员是怎样的？关于这个问题，个人很认同ThoughtWorks徐昊的一个观点：“估点是靠谱的，那么这个人就是靠谱的。”用大白话讲，你说你用一天半时间能完成一个任务，届时如果可以保质保量交付，那么你就是靠谱的。

‍

从管理的角度来讲，如果团队的所有成员都能精准地预测工作时长，产品的交付和团队运转一定是行云流水。当然这只是美好的设想，现实中无法做到这么理想的状况。

‍

那么怎样让估点靠谱、让程序员靠谱？估点的具体技术很重要，但从技术管理者的角度说，更重要的任务是建立机制，让度量能够真正作用于研发流程的改善。而优秀的机制应当是鼓励正反馈、自进化的闭环。

我们知道，研发中迭代始于计划，迭代的末尾则需要回顾研发过程的好和坏。进行有效回顾，将改进反馈纳入下一迭代的规划中，才能形成闭环，让团队的水平不断提高。

‍

然而现实情况下我们怎么做回顾呢？通常的做法是召集研发团队一起开会，每个人轮流总结迭代中的表现。这些讨论大多是根据主观感受来进行描述，天然地限制了回顾的有效性，也难以归纳出有效的反馈意见。此外，随着团队规模扩大，对彼此的工作了解不足，回顾的效果会进一步弱化。

‍

如何产出有效的反馈，形成闭环？工时和代码行数等侧重“活动”的指标，在侧重“成果”的会议上明显是不适用的，准确性上会出现明显的偏差。（关于指标间的差异，请参见我们之前梳理出的一文揭秘研发团队的自驱力密码:绩效考核指标。）

‍

如何合理量化评估程序员工作量

‍

思码逸希望用技术来解决这个问题。我们的做法是引入一个新的指标『代码当量』（DevEquivalent），来度量大家的产出代码的复杂度。代码当量与故事点形成了前后呼应——故事点是在开始干活前评估任务的复杂度；而代码当量是活干完以后，从代码层面进行的回顾。

在技术上如何实现这个指标？这里涉及到两个概念，一是『复杂度』，有点类似于算法的时间复杂度；二是『抽象语法树』，编译就是对源代码进行解析-构建抽象语法树-生成字节码的过程。所谓代码当量，简单来说，就是代码在抽象语法树这个数据结构上的复杂度。

代码当量的优势在于：

排除源代码级别的噪音，比如空格、死代码等；
大部分程序分析和语义理解技术都是构建在抽象语法树这一数据结构上，相比于解析更靠后阶段的字节码、机器码，抽象语法树更能反映出程序员本身的表达；
可应用编译优化技术，使评估更加准确。

综合起来，基于代码分析的代码当量能够达到一些简单统计所达不到的效果。那么如何将其应用于研发效能回顾的具体场景呢？

‍

研发效能度量中的三个应用场景

‍

场景一：估点回顾，对研发计划进行校准

在迭代回顾会议上，研发团队需要将实际开发工作量与前期估点比对，看看是否有显著差异。这个时候，代码当量指标就可以清晰反映出已完成工作的复杂度。

以下的产品截图是根据开发者来进行估点和代码当量的对照，这是角度之一；另一个角度是根据事务或 issue 来进行对照。

这个数据具体怎么看？一般有两种方式：

如果研发团队成熟度较高，可以计算该迭代或近几个迭代内，平均每个故事对应多少代码当量，乘以每个人在计划时提报的故事点数，再与实际代码当量进行对比

如果研发团队的成熟度没有那么高，则可以对故事点数量进行排序，找出明显的代码当量偏差（图中标红的几项），再对偏差进行具体分析。

通过这种方式，研发团队能快速发现计划与实际开发中的偏差，分析原因并校准，不断提升开发团队预估和计划的有效性。

‍

场景二：建立简单基准，提升研发稳定性

谈到研发成熟度就不得不提到CMMI，这个模型虽然传统，但其推崇的理念还是很有参考价值。CMMI第四级（量化管理级）的要求中就包括“数据驱动的组织目标”与“用基线控制项目过程”。

在实践中，CMMI落实的难度较高，但这些理念可以以低门槛的方式落地：根据过往的研发数据，用简单的统计手段找到简单清晰的基准（比如拟合线、上下限等、离散系数等），进而检验研发过程进行稳定性。比如，在下面的例子中，我们很容易就能看出右图团队的整体研发稳定性更优，但也需要对其可能存在超负荷工作的情况进行分析。

在很多时候，研发稳定性的重要程度高于产出量的绝对值。基于这个简单的基准，研发团队可以化繁为简，及时复盘分析波动异常情况，并给出相应的指导、建议或要求。

场景三：横向对比，为度量结果找到参照系

组织内部有多个团队/项目，很自然就会希望将相近的团队/项目对比，分析变化趋势的差异。从下图来看，折线靠上的三个项目的开发进度、阶段大体是相似的，那么就可以拿来进行更细致的比对。除了代码当量本身，还有其他指标是可以拿来对比的，比如代码复用度。提高代码复用度是软件工程的关键目标之一，不仅能减少重复造轮子的浪费，也有助于提高软件制品的可维护性。

除了内部对比，研发团队可能也希望与同行业相近项目/团队对比。我们的产品中也提供了与近似开源项目对比的功能，研发管理者可以迅速了解团队当前的研发水平是怎样的。

内部与外部的横向对比，是将度量结果放进参照系中，进而转化为更有针对性、更加明确的改进建议，帮助研发团队获得整体的成长。