【译者注】AI编程助手正席卷全球，如Github Copilot，其甚至能提升编程效率高达55%。你是否对如何评估它的效能感到好奇？本文就详细介绍了一种评测方式。如果你已经迫不及待想要拥有这样一个帮手，是时候拿着这篇文章找你的老板谈谈了。
原文: Best of 2023: Measuring GitHub Copilot's Impact on Engineering Productivity - DevOps.com
原文标题：2023年最佳：评测GitHub Copilot对提升工程生产力的贡献
作为2023年的结束，我们DevOps.com希望精选这一年最受欢迎的文章。以下是我们2023年最佳系列的最新文章。
大多数软件交付团队都正在考虑以某种形式采用AI来帮助工程师加快他们的价值交付和提高交付效率。GitHub Copilot就是首批利用AI工程辅助的例子之一。它自称为"你的 AI 编程搭档"，并且可以自动完成代码。
一些早期尝试GitHub Copilot的用户表示，使用这款工具能够有效提升生产力，高至20%的提升率。虽然每位用户每月需要支付10美元的费用，可能会让一些人觉得成本较高，但如何为购买GitHub Copilot构建有力的商业论证呢?
大多数组织围绕 GitHub Copilot 能够带来的生产力提升和相关的价值交付来构建商业论证。然而，要准确评估像 GitHub Copilot 这样的工具对生产力和价值交付的影响，你应该采用什么方法（和指标）呢？
GitHub Copilot：程序员的第一代AI助手
Copilot 无疑标志着人工智能在软件交付生命周期（SDLC）各个领域的漫长而加速的旅程的开始。它利用 OpenAI Codex 在你的编辑器中实时提供代码建议和整个函数。
几乎每天都会涌现出新的AI工具，它们能够帮助软件工程师节省大量时间并提高效率。以下只是一些例子：
- Grit.io 将帮助管理技术债务
- Mintlify 为开发者提供自动化的文档
- Code AI 帮助翻译(一些)语言，调试，导航代码并作为一个配对程序员
- 像AdrenalineAI这样的工具，使用AI来提高你对你的代码库的理解。
因此，在进行成本控制时，你可能会想知道如何准确地衡量这些工具的效益，以便能够为这些额外的开销提供合理的解释。
一个衡量像GitHub Copilot这样的工具的影响的方法论
为了精确衡量GitHub Copilot（以及类似的AI工程增强工具）的影响，衡量方法必须是：
- 定量的--基于硬性、可测量的数据；
- 整体的--考虑整个端到端软件交付生命周期（SDLC）中的所有收益和可能的影响；
- 平衡的--包括主观调查数据和软件交付数据。
这需要一个全面的度量分数卡，以充分捕捉到 GitHub Copilot 的好处和可能成本。这些指标反映了测量开发者生产力的 SPACE 框架，重点强调 GitHub Copilot 可能会影响的关键领域。
对于代表性的 GitHub 用户群体，可以跟踪这些指标以查看“前后效果”。我们建议代表性样本应包括不同级别和活跃度的工程师，分析的时间期限应至少为三个冲刺周期（例如六周或更长时间）。
衡量GitHub Copilot影响的关键指标
一个端到端的软件交付分析平台为衡量像GitHub Copilot这样的工具的实际影响提供了一个全景视窗。它集合了一系列的工程和软件交付度量，以捕捉GitHub Copilot对“生产力”决定的五个关键变量的影响：
- 速度和吞吐量--团队"产出"的测量
- 价值实现时间--交付一次软件增量所需的时间
- 质量
- 可靠性--如果团队更可靠地按照他们的计划交付，这就是一个关键的好处
- 开发者满意度--加速重复/不太有趣的任务的影响
这些指标可以在一段时间内被跟踪，以GitHub Copilot控制组和非用户进行对比。
1. 速度和吞吐量指标（Velocity and Throughput Metrics）
吞吐量（Throughput） 是对 Scrum 和 Kanban 团队在一段时间内的核心"产出"进行测量的指标，可以以票据、故事点、PR、构建或价值点计算。交付分析工具应该计算 GitHub Copilot 用户和非用户的每位工程师的吞吐量。这可以表示为百分比增长。
冲刺速度（Sprint Velocity） 考虑了在一个冲刺中完成的工作速度以及它随时间的变化。它可以用票证或故事点计算。高级的数据分析工具还可以显示每个冲刺承担的工作量，从而让你更好地了解底层的交付度量。这将是衡量 GitHub Copilot 影响的关键指标。
2. 价值实现时间（Time to Value ）
周期时间（Cycle Time） 是跟踪组织早期和经常交付软件能力的一个核心敏捷软件交付度量。它计算从开发开始到部署交付一个软件增量所需的时间。周期时间越短，反馈环路越短，组织将更快地获得新特性并响应客户需求。这是在评估技术交付效率时的一个关键 KPI。
代码周期时间（Code Cycle Time） 通常占据整体周期时间的20-30%。它计算从打开一个拉取请求（PR）到合并/关闭的平均时间。这个时间的大部分通常是在审查过程中花费的。
理论上，GitHub Copilot使得开发更快、更容易。因此，开发人员应该有更多的时间来审查彼此的拉取请求（PR）。如果代码质量得到提高，那么请求更改的频率应该会更少，且批准时间更短。
3. 质量（Quality ）
遗漏的缺陷（Escaped Defects） 是一个简单但有效的衡量整体软件交付质量的指标。它可以通过多种方式进行追踪，但大部分涉及按照重要性/优先级追踪缺陷。
在对GitHub Copilot实施前后的交付效率进行任何分析时，都应考虑遗漏的缺陷率。因为以牺牲质量为代价来提高速度和“生产力”，将是一个糟糕的选择。
构建失败率（Build Failure Rate） 指示了失败构建的百分比以及这对一个团队有效工作所构成的整体风险。在实施 GitHub Copilot 后，失败率的显著变化表明代码质量可能会受到影响。
4. 可靠性（Dependability）
冲刺目标完成度（Sprint Target Completion） 追踪了每个周期内达成冲刺目标的百分比。"敏捷团队"和"冲刺"，这两者构成了Scrum敏捷软件交付的基础元素。只有当敏捷团队能够如期完成他们设立的冲刺目标时，我们所交付的敏捷软件才堪称可靠，使得我们能够预测跨团队和更长时间维度上的交付结果。
因此，敏捷团队的预测性就显得尤为重要，这也是衡量敏捷软件交付成败的关键指标。假设GitHub Copilot可以帮助团队更高效、更准确地完成任务，那么它无疑将成为提升我们整体工作效能的重要工具。
5. 开发者满意度 （Developer Satisfaction ）
eNPS被视作衡量团队和组织内部员工满意度以及忠诚度的重要指标。口头报告揭示，开发者普遍认为 GitHub Copilot 能够让编程中的繁复环节变得更易于应对，因此对他们的幸福感产生了积极的推动效果。而员工NPS则使得这一结论得以量化，从而便于进行验证。
虽然这是评估生产力的关键要素，但在量化开发者的整体生产力时，我们不应片面考虑，需将其与其他度量指标相结合。
以上列举的是在研究 GitHub Copilot 对交付生产力影响时，值得参考的一些度量指标例子。核心的观点在于选用一套平衡的度量方法，全方位地审视软件交付这一过程的复杂性。
应用“平衡计分卡”度量方式，构建GitHub Copilot的商业模型
为了构建GitHub Copilot的整体生产力影响评估（PIA），我们常常采用简易的权重加总法，将前述的“平衡计分卡”度量数据进行整合。详见以下表格：
GitHub Copilot生产力影响评估 - 样例模板
在进行产品效益分析（PIA）时，通过计算出的加权平均生产效率的增长，我们可以将其应用于预测交付能力的成本计算中（员工人数乘以全额员工成本）。这为我们提供了一种基于资源费用来衡量生产力提升的货币计量方法。它排除了更早地为客户提供更多价值这一潜在的（并且可能更大的）收益，这不是一项容易或必须量化的优势。
使用GitHub Copilot提高生产力 - 实证数据
关于这方面的独立数据明显不足。
GitHub自有的对2000名开发者的调查显示，有88%的开发者声称在使用这款工具时‘更有生产力’，同时由95名开发者进行的一项任务测试显示，使用GitHub Copilot的组比起其他组快了55%，且完成任务的成功率比别的高出7%（见下文）。
GitHub自己的调查数据 - GitHub Copilot对用户影响（2022）
我们的分析显示，使用PIA（如上图所示）可以提升大约5%的生产力。然而，随着AI技术的迅速提高，这个数字肯定会进一步提升。
