Scrum Master的AI应用思考 - 透明性

我是敏捷团队的石田。

思考Scrum Master的AI应用 - 引言 的续篇。上次参考了Scrum指南扩展包，触及了AI强化Scrum的可能性之一——强化“经验式过程控制”。

作为Scrum Master，通过在Scrum流程中利用AI，可以进一步强化团队实践的Scrum三大支柱：“透明性·检验·适应”。

在本文中，我们聚焦于三大支柱的第一步——“透明性”。此处所说的透明性，不仅仅是让一切可视化，而是为团队做出正确判断（检验·适应）准备必要的素材。

这次介绍的做法不是将数据分析本身交给AI，而是让AI来编写“用于可视化的工具（编码）”。具体来说，将Jira的数据通过Google Apps Script (GAS)获取、加工，并实现可视化的过程案例与大家分享。

为了让Scrum Master能够正确地观察团队状态，以及让团队成员客观地审视自己，定量化的数据是必不可少的。

虽然Jira等项目管理工具都配备了标准的报告功能，但在实际场景中，常常会出现“想以这个维度再看一下”“想要与外部电子表格的信息进行比对”等标准功能无法覆盖的需求。Jira提供了强大的API，可以自由地处理数据，但对于不是专职开发的Scrum Master而言，从零开始开发工具在学习成本和时间上都有很高的门槛。

因此，我们想要利用生成式AI来编写代码，并让其扮演“Scrum Master专属工程师”的角色。通过这种方式，可以打破技术壁垒，显著提升Scrum Master的机动性。虽然在实际产品代码中直接使用AI生成的代码需要从可维护性角度进行审慎讨论，但对于在团队内部使用的临时工具或仪表盘，从积极利用的角度来看，这恰恰是能发挥价值的领域。

接下来，将介绍在实际业务中利用生成式AI进行团队可视化的示例。

首先，简单介绍一下本次可视化的对象“Four Keys”。Four Keys 是由Google的DevOps Research and Assessment（DORA）团队提出的，用于衡量软件开发团队性能（交付能力）的四个指标。

1. 部署频率 (Deployment Frequency): 发布到生产环境的频率。
2. 变更前置时间 (Lead Time for Changes): 代码从提交到生产环境运行所需的时间。
3. 变更失败率 (Change Failure Rate): 因部署导致故障发生的比例。
4. 服务恢复时间 (Time to Restore Service): 从故障发生到恢复所需的时间。

这些指标分别反映了开发的“速度（1和2）”与“稳定性（3和4）”。通过测量这些指标，可以客观地把握团队是否能够快速且稳定地交付价值。指标定义虽然明确，但在实际环境中进行测量时，会遇到一些障碍。

首先，变更前置时间（从开始开发到发布所需的时间）可以从Jira的状态迁移历史中计算得出，但仅靠标准的报告功能难以实现，需要通过API获取数据并进行计算处理。另外，关于变更失败率，由于本次项目将生产故障记录在Google电子表格中，需要将该数据与Jira的发布信息进行比对后再进行计算。

为汇总这些分散的数据并构建 Four Keys 仪表盘，我们采用了 Google Apps Script (GAS)。如前所述，代码的编写交给了生成式AI完成。

1. 从 Jira 提取“速度”

首先，让AI编写通过 Jira API 获取工单数据的脚本。在提示词中，关键点是让AI关注“状态迁移历史”。

提示词示例:
"我想从 Jira 的特定项目中获取已完成的工单信息。提取每个工单变为 'In Progress' 的时间，以及包含该工单的 发布完成时间，然后将它们的差值计算为前置时间，请编写对应的 GAS 函数。"

这样就可以自动汇总每张工单的前置时间，以及按月的发布次数（部署频率）了。

2. 从电子表格计算“稳定性”

接下来，访问用于故障管理的电子表格。这里统计每月的故障发生次数，再与前面计算出的部署次数进行比对，从而计算“变更失败率”。

最终将这些数据以图表形式绘制在同一个电子表格上，团队的 “Four Keys” 日度更新仪表盘就完成了。

这样一来，团队成员可以随时查看最新的 Four Keys，一目了然地了解自己的发布频率及其对质量的影响（故障），团队的“速度”和“稳定性”也因此透明化。

第二个示例，讲一下有点超出 Scrum 范畴的应对措施。由于项目的特殊性，有一个发布日固定的“必达项目”，团队一直在忙于应对。本来按照原生 Scrum，应基于 Velocity 的实际情况调整范围，但该项目的范围也是固定的，按照原有的 Velocity 根本无法赶上发布。

因此，作为现实应对，决定暂时增加开发人员的投入（人数和时间），以加快进度。

但是，单纯地增加投入后，开发速度到底提升了多少？以当前进度是否真的能在截止日完成？仅凭传统的燃尽图并不直观。“虽然在努力，但不知道能否赶上”的不安状态会降低团队士气。

于是，这里也借助了 AI。让 AI 编写脚本，根据从 Jira API 获取的“每日完成的点数（实际值）”，计算剩余工作消化还需要多少天，并绘制“预测完成日”的变化趋势。

这样一来，当增加投入后，图表斜率明显变陡（消耗节奏加快），预测完成日也逐渐逼近发布日（下图为示意）。团队和利益相关者得以明确看到“当前加速状态将于○日完成”的预测，消除了模糊的不安，帮助开发成员更有信心地推进工作。

迄今为止，哪怕想“要是有这样的数据就好了”，因为技术技能不足或时间限制而不得不放弃的可视化，现在通过 AI 配对编程可在数小时内实现。

透明性讲究时效性。当感觉问题可能出现时，能够立即亲手制作可视化工具，对于保护团队的 Scrum Master 是一件强有力的武器。能够将“看不见的不安”立刻转化为“可见的问题”的机动性，或许正是 AI 利用的最大优势。

本文介绍了利用 AI 编写 GAS，挖掘 Jira 和电子表格中沉睡的数据，快速、低成本地实现团队所需透明性的案例。这是实践 Scrum指南扩展包中所暗示的“通过 AI 强化经验式过程控制”的第一步。

然而，透明性并非终点，基于可见的数据如何进行判断并改变行动才是关键。下次第三回“检验·适应”将介绍与透明性不同的视角，以及在可视化信息基础上的 AI 在决策场景中的应用。