思考Scrum大师的AI应用 - 实践篇：以AI为起点的每日Scrum

我是敏捷团队的石田。

在之前刊载的考虑Scrum大师的AI应用系列中，我们介绍了通过AI强化透明性、检视和适应三大支柱的做法。这次作为实践篇，我将介绍在当前项目中所实施的以AI发信为起点推进每日Scrum的尝试。

到目前为止介绍的AI应用，总是“人类去使用AI”。例如在有需要分析的数据时向AI咨询，或使用文字转录来评估回顾会议。这类用法的发信起点始终在人类一方。

但我所追求的，是颠倒这种关系的世界。让AI检视团队状态并主动发信，人类则以该结果为起点推进Scrum活动。本文将作为第一步，具体介绍我在每日Scrum中实践的做法。

在许多团队中，每日Scrum往往形同形式。仅依次共享“昨天做了什么、今天要做什么、遇到了什么困难”，然后草草消耗15分钟结束，这样的团队并不少见。

但每日Scrum本不应只是简单的作业报告场所。它应是检视我们对冲刺目标的进展，并在必要时对计划进行调整。

然而要每天都认真执行“对冲刺目标的检视与适应”并不容易。要让人类每天早上准确掌握从昨天到今天工单状态的变化，以及这些变化对冲刺目标的达成是好兆头还是坏兆头，负担非常重。

这正是AI的用武之地。AI会积累并分析工单的每日变化，客观评估其与冲刺目标的关系。

我所实践的机制大致由两个主要步骤构成。

1. 使用Google Apps Script (GAS) 每日获取当前冲刺中的Jira工单及其关联子任务状态，并按时间顺序记录到Google文档
2. 让Gemini分析积累的历史，输出对冲刺目标的检视结果
3. 以Gemini的分析结果为信息源进行每日Scrum

首先，准备一个通过Jira API将Jira数据记录到Google文档的GAS。GAS代码本身也借助了生成AI。文档内容在开头写入当前冲刺的冲刺目标，随后每天追加冲刺中包含的故事、任务等工单及其关联子任务的变更历史。尽管跟踪子任务的变化会增加数据量，但可以捕捉实际作业的进展与滞留情况。

实际从Jira获取的内容大致如下：

=== 2026-08-05 快照 ===
sprint_name: 冲刺 21
sprint_goal: 将用户通知功能准备到可发布状态

target_date: 2026-08-14

  id: prj-1421 - 通知设置的数据模型定义
  status: Done
  assignee: 田中
  story_points: 2
  change_log: 2026-08-13 15:23 status(InProgress -> Done)

  id: prj-1422 - 实现设置更新API端点
  status: In Progress
  assignee: 田中
  story_points: 1
  change_log: 2026-08-13 15:45 status(To Do -> InProgress)

在每日Scrum前，将积累的文档提交给Gemini进行分析。将系统提示作为自定义指令注册到Gem中，可每天早晨从相同视角获得稳定的分析结果，非常方便。

为了在每日Scrum中使用分析结果，下列内容尤为重要。

• 冲刺目标的当前状态：AI分析工单及子任务的变更历史与冲刺目标，为开发现状是否能达成目标进行检视。
• 按成员划分的当日更新及提问：根据各成员负责的工单近期作业情况进行整理，并基于此由AI具体提问，确认是否存在阻碍冲刺目标达成的因素。

在实际每日Scrum中，团队会基于这些信息核对各自的作业状态，并在确认AI对冲刺目标检视的合理性后，如有必要立即进行计划调整。这样，每日Scrum不仅是进度报告，更能让团队自然围绕冲刺目标凝聚合力。

下面展示部分Gem的提示内容。

# 角色
你是一位优秀的敏捷Scrum大师及每日Scrum的主持人。
请解读所提供的Jira日志，为团队达成冲刺目标整理本次每日Scrum需确认的要点，并生成作为会议起点的发言。

# 输入数据的特性·运用规则
（中略）

# 思考过程·指令
（中略）

# 输出格式
请按以下结构输出。
务必采用既专业又亲切的语调，确保在每日Scrum现场能够从上到下顺畅阅读。

大家早上好。现在开始今天的每日Scrum。
## 冲刺目标的当前状态
  [目标项]:（结合进度感、剩余任务量及作业类型，1～2行简洁描述分析结果）

## 按成员划分的当日更新及提问
  [成员名 / 若为结对编程则连名]
  最新状况:（在最近的工作日中，负责工单的变动及changelog概要）
  来自AI的提问:（基于状况及作业类型，提出是否存在阻碍因素的具体问题）

这个机制的本质在于，让每日Scrum的起点成为AI的发信。

传统情况下，成员们轮流报告状况，倾听后才有人发现问题。但在这一实践中，每日Scrum开始前Gemini已完成对冲刺目标的检视。

团队可以直接以AI所提示的“今日需讨论的议题”为出发点开始每日Scrum。例如，“首先讨论AI所提到的，田中先生负责的API实现中的阻塞点吧”，这样最重要的检视与适应便成为对话的起点。

这便是我所追求的“不是去使用AI，而是从AI的发信开始推动Scrum的世界”的开端。人类将免于主动向AI查询的繁琐，得以集中于针对AI提供的洞见进行“如何适应”这一只有人类才能完成的决策。

我构建了这一机制并向团队推广。最初约两周，我在调整数据与提示的同时亲自用Gemini运行分析，并通过Slack分享结果进行测试。当运行趋于稳定后，便将是否继续使用的决定权交给团队，目前团队已自主运用这一机制。

作为Scrum大师，我认为应向团队展示强化每日Scrum检视与适应的选项，但是否实际使用应由团队自主决定。

实际的每日Scrum流程如下。团队成员完全远程工作。

1. 当日的主持人在每日Scrum前运行Gemini，并将结果发布到Slack。
2. 基于分析结果，先把握冲刺目标的当前状态，然后查看AI提出的按成员划分的提问。
3. 使用Zoom反应功能，以“是”“否”“不确定”三种选项表示当前状态是否有望达成冲刺目标。
4. 若出现“否”或“不确定”，则确认具体内容，并在必要时调整作业计划。

作为每日Scrum实践中有一种称为“冲刺目标签到”（Sprint Goal Check-In）的做法。即在每日Scrum开头询问“照目前状况是否能达成冲刺目标？”，以强化对冲刺目标的检视。上述方法在此基础上加入了AI辅助，进一步强化了检视与适应。

以往团队在每日Scrum中能够共享各自的作业状况，但未能检视这些作业是否真正对准了冲刺目标。这一机制通过AI分析提高了作业状况的透明度，并由AI承担对冲刺目标的检视，使得基于结果的讨论与适应在团队内部自然发生。

虽说以AI发信为起点，但如果最后还是人类手动触发Gemini，起点是否仍属于人类？对此确实如此。理想情况下，应通过API等方式实现分析自动化，每日Scrum前将检视结果自动发布到Slack等。但在我所参与的项目中，受到无法使用AI相关API的限制，因此采用了本方法。若有兴趣参考本文实践，请务必挑战更高级的自动化。

Jira当前内置了名为Rovo的AI代理。使用它可无需如此繁琐便进行冲刺分析。然而就提示的灵活度和输出结果的稳定性而言，采用系统提示的方式依然非常有用。

Gemini的检视结果固然有用，但仅基于工单数据的可读信息进行分析。对于工单之外的上下文，例如“工单停留是因为有意降低了优先级”等背景信息，AI无法掌握。

以AI发信为出发点，同时由团队判断其指摘是否切中要点。这样的对话正是每日Scrum的价值所在，而非盲目信赖AI分析。

若每天写入包含Jira工单Changelog的数据，文档体量即AI输入量会持续膨胀。可通过每个冲刺切换新文档、仅写入前日发生变更的项目等手段控制数据量。

该机制是否对团队有帮助也应定期回顾。若AI发信偏离要点或反而误导讨论，应检视提示和积累数据的内容。作为Scrum大师，提供机制后便属职责范围；若结论显示对团队无意义或运维成本过高，也需判断是否停止使用。

本文作为“思考Scrum大师的AI应用”系列的实践篇，介绍了以AI为起点推进每日Scrum的做法。

• 使用GAS将Jira工单及子任务的每日历史积累到Google文档
• 通过Gemini的自定义指令（Gem）每日生成冲刺目标的当前状态及按成员划分的提问
• 以此分析结果为起点开展每日Scrum，并结合冲刺目标签到强化检视与适应

通过该机制，原本易于流于进度报告的每日Scrum，已转变为一个检视冲刺目标并讨论相应调整的场所。AI稳固强化了作业状况的透明度、对冲刺目标的检视以及朝目标达成的适应三个Scrum支柱。

这一实践尚在探索中，但期待AI持续检视团队状态，人类则专注于基于AI洞见的决策与适应。我将继续通过实践探索这一以AI为起点的Scrum世界。