使用 GitHub Copilot 实现公司工程目标

当你的公司推出一个新的工具时 GitHub Copilot，你需要衡量该工具对工程系统的影响，并评估该工具对公司目标的贡献。

GitHub的工程系统成功行动手册（ESSP）提供了相关策略和指标，以推动有意义且可衡量的改进。该 playbook 建议采用三步流程来解决工程挑战：

定义目标

在确定要跟踪的 Copilot 指标之前，请先选择工程目标。使用情况和采用信号仅显示用户是否使用该工具。工程系统和开发人员反馈的结果度量有助于评估你希望的更改是否真的正在发生。

从一个或两个目标开始，并将它们传达给你的团队。在更改发布之前记录基线。使用每个目标的现有指南来计划培训和选择结果度量值。

使用信号无法确定某次特定交互是否进行了测试、修复了漏洞或防止了一次事件发生。使用它们结合结果度量值来了解采用情况，而不是作为这些度量值的替代品。例如，生成的更多代码并不意味着更好的测试覆盖率，并且更高的验收率并不意味着代码质量或开发人员满意度。

如果测试中的缺口导致发布延迟或降低信心，请跟踪持续集成报告中的行覆盖率和分支覆盖率。还可以跟踪编写测试所花费的时间和开发人员的信心。将这些结果与参与团队中的聊天和代理使用趋势进行比较。请参阅“通过GitHub Copilot提高公司的测试覆盖率��。

如果评审延迟正在降低交付速度，请跟踪拉取请求的提前期和评审周期，同时在部署后检查缺陷。使用采用群组、每个用户合并的拉取请求以及合并耗时，在影响仪表板中探索采用与交付之间的关系。请参阅“使用 GitHub Copilot 加速您公司的拉取请求”。

如果未解决的漏洞正在累积，请在安全概述中跟踪安全警报积压工作和修复所需的时间。请考虑从事修复工作的团队中代理和代码评审的使用趋势，同时结合这些结果。请参阅“通过GitHub Copilot减少公司的安全债务”。

如果可维护性或可靠性问题不断增加，请查看组织级别的代码运行状况，以及一段时间内 Code Quality中的开放的发现项。将这些与处理这些问题的团队中的采用和功能使用趋势进行比较。请参阅“探索组织中的 GitHub 代码质量结果”。

使已分析存储库集保持一致。未结发现数量可能会在更多存储库上启用分析时或发现被忽略时发生变化，而不仅仅是在代码得到改进时。

如果重构和维护工作旨在提高稳定性，请使用事件记录跟踪与重构代码相关的生产事件。结合用于该工作的团队中的 Copilot 使用趋势，一并查看这些结果。请参阅“使用GitHub Copilot减少技术债务”。

如果你的目标是减少工作流摩擦，请通过调查或回顾收集有关有用性、信任和满意度的反馈。使用持续使用情况、功能采用和接受率趋势来识别与开发人员探讨的问题，而不是仅凭活动情况推断满意度。请参阅“衡量GitHub Copilot试用的成功”。

每次查看进度时，都使用相同的比较方法：

对齐范围和时间段。 比较同一团队在相同报告日期下的使用情况和结果。记录包含的存储库和工具，并使指标定义与基线保持一致。

影响仪表板比较不同采用群组中的用户，而不是采用前后的相同用户。队列之间的差异可以反映他们的工作或经验以及他们对 Copilot 的使用情况。请参阅“解释 GitHub Copilot 的使用情况和采用指标”。
查看还有哪些更改。 记录人员配备、项目复杂性、发布计划、培训或工程实践的变化。这些可能会独立于 Copilot影响结果。
兼顾质量与速度。 如果拉取请求合并得更快，还要查看缺陷、事故和开发人员反馈。单单增加的产出并不能证明工程成果有所改��。
在对结果进行归因之前进行调查。 查看多个时间段的趋势，并询问团队如何使用 Copilot。除非有支持因果结论的其他证据，否则将观察到的更改描述为关联。

使用综合结论选择下一步操作。例如，如果测试覆盖率保持不变，尽管使用量不断增加，请询问团队是否使用 Copilot 来编写测试。在扩展此方法之前解决任何训练或工作流障碍。