Help us learn about your current experience with the documentation. Take the survey.

站会、回顾会和速度

除了冲刺规划（sprint planning）和评审（reviews）等核心 Scrum 仪式外，团队还可以使用 GitLab 来促进以下常见的 Scrum 仪式，无论是在同地办公还是分布式环境中：

  • 每日站会
  • 回顾会
  • 故事点
  • 速度和波动性

本页面建立在入门 Scrum 教程中的概念和工作流程基础上。 如果您还没有完成该教程，建议在继续阅读前先完成。

每日站会

通用指南：

  • 将站会限制在 15 分钟以内。
  • 如果任何话题需要超出状态更新的进一步讨论，推迟讨论，以便相关人员在站会后进行深入讨论。

同步站会

如果您是同地办公，请在同一房间聚集，通过查看当前冲刺（Current Sprint）板来讨论各个问题的更新。

如果您是分布式团队，请加入视频通话，让一个人共享屏幕来查看当前冲刺板。

除了一起查看当前冲刺板，您也可以使用以下格式。 每个团队成员应回答这三个问题：

  • “我昨天完成了什么？”
  • “我今天要做什么？”
  • “我是否被任何事项阻塞了，或者即将被阻塞？”

异步站会

要在 GitLab 中促进异步站会，您有以下几种选择：

  • 在团队的聊天工具中：使用自动化来报告每个团队成员的站会内容。 我们在 GitLab 内部使用 Geekbot。

  • 在 GitLab 中：

    1. 创建一个标题为站会（Stand-up）的 issue，并将其添加到当前迭代中。
    2. 在冲刺的每一天，第一个报告站会的人应创建一个包含日期的新评论，然后添加包含其更新的评论。
    3. 每个团队成员将各自的更新作为线程添加到讨论中。 查看示例（来自演示项目）。

冲刺回顾会

回顾会是团队识别流程改进和庆祝进度的无指责机会。 您可以从多种回顾会格式中选择。

James Shore 在他的《敏捷的艺术》（The Art of Agile）一书中提供了关于如何进行回顾会的优秀大纲。

同步回顾会

在回顾会期间查看迭代报告可能会有所帮助。

要查看已完成迭代的迭代报告：

  1. 在左侧边栏，选择搜索或跳转至（Search or go to）并找到您的群组。
  2. 选择计划 > 迭代（Plan > Iterations）。
  3. 在顶部，选择已完成（Done）并选择您的迭代周期。
  4. 选择最近完成的迭代。

异步回顾会

您可以使用 GitLab issue 进行异步回顾会。

  1. 在当前迭代中，创建一个标题为回顾会（Retrospective）的新 issue。

    您可以应用许多与同步回顾会相同的格式。 查看示例 issue，该示例应用了 James Shore 提出的回顾会大纲。

  2. 如果有很多行动项，考虑创建单独的 issue 来独立跟踪它们，而不是放在回顾会 issue 中。

  3. 团队完成行动项分类后，关闭回顾会 issue。

故事点

要识别完成一个故事所需的相对复杂性和工作量，您可以使用故事点。 故事点还可以帮助您在规划过程中识别和讨论范围与实现之间的权衡。

在 GitLab 中，团队使用 issue 或任务中的权重（weight）字段来记录故事点。 根据您的估算策略，您可以在故事（issues）或任务上设置权重。

确定故事点的价值

您应该使用修改后的斐波那契序列作为故事点刻度：0、1、2、3、5、8、13、20 和 40。 正如 Mike Cohn 在阐述韦伯定律时所指出的那样， “过于接近的数字无法作为估算值区分”。

在确定单个故事点的价值时，设定一个基准定义很有帮助：一个故事点等于开发人员的"理想"一天。 在这样的日子里，开发人员效率很高，不被任何事项阻塞，并且整天保持专注状态。

您可以与团队合作，就单个故事点的不同价值达成一致。 重要的是，一旦您确定了定义，就不要更改它。 如果确实需要更改，请注意，在接下来的几个冲刺中，您的速度和波动性可能会不准确。

例如，如果您设定的目标是每个迭代交付四到十个用户故事，请将任何点值大于三的故事拆分为两个或更小的故事。 理想情况下，您的团队应该努力拆分或合并故事，直到它们的权重为一或二。

利益相关者绝不应该使用故事点来衡量团队的表现或比较不同团队。

速度和波动性

随着时间的推移，团队可以使用故事点来理解他们的速度。 理解速度有助于您调整冲刺范围的大小，并与团队外部的利益相关者设定更可靠的期望。

您可以通过计算过去几个冲刺中交付的故事点数量的平均值来计算速度（velocity）。

波动性（volatility）表示过去冲刺中交付的故事点数量的标准差除以您当前的速度。

了解团队的波动性对于帮助您理解在不同迭代之间完成故事的可预测性非常重要。 需要重点改进的关键领域之一是降低团队的波动性。

在以下部分中，我们将研究两个团队，他们在九个迭代中完成了相同数量的故事点。 您将看到较低的波动性如何在预测未来团队绩效方面提供更高的可预测性，最终使团队能够与利益相关者设定更好的期望。

创建速度和波动性跟踪电子表格

在速度和波动性被原生集成到 GitLab 中之前（请参阅 epic 435），您可以在电子表格中跟踪团队的速度和波动性，如下所示：

显示 Scrum 团队速度和波动性跟踪器的电子表格。

在此示例中，我们使用 Google Sheets。 您可能需要根据您偏好的电子表格软件调整公式。

要创建这样的电子表格，请创建并填充以下列。

要计算当前速度和波动性：

  • 迭代（Iteration）：过去迭代的编号或标题。
  • 已完成故事点（Story Points Completed）
  • 速度（Velocity）：
    • 第一个单元格中的数字与已完成故事点列中的相同。
    • 所有其他单元格显示过去几个冲刺中交付的故事点数量的平均值。 在此示例中，我们使用最多四个。
    • 例如，C10 单元格具有以下公式：=AVERAGE(B7:B10)。
  • 波动性（Volatility）：
    • 计算过去冲刺中交付的故事点数量的标准差除以您当前的速度。
    • 例如，D10 单元格具有以下公式：=(STDEV(B7:B10)/C10)。

要预测未来完成的故事点数量：

  • 一个用于剩余待办事项点数的单元格。 在此示例中，它是 F4。
  • 未来迭代（Future Iteration）：未来迭代的编号或标题。
  • 最坏情况（Worst Case）：每次迭代后剩余故事点的最坏情况预测。
    • 计算参考最新完成迭代的速度和波动性。 这里：
      • 波动性：C10
      • 速度：D10
    • 第一个单元格中的公式从 F4 单元格中的数字减去。 例如：=F4-(C10*(1-D10))。
    • 所有其他单元格从上方的单元格减去。 例如，H10 单元格具有以下公式：=H9-($C$10*(1-$D$10))。
  • 预期情况（Expected）：每次迭代后剩余故事点的现实预测，从剩余故事点中减去最新计算的速度。
    • 第一个单元格中的公式从 F4 单元格中的数字减去。 例如：=F4-$C$10。
    • 所有其他单元格从上方的单元格减去。 例如，I10 单元格具有以下公式：=I9-$C$10。
  • 最好情况（Best Case）：每次迭代后剩余故事点的最好情况预测。
    • 与最坏情况类似，计算参考最新完成迭代的速度和波动性。
    • 第一个单元格中的公式从 F4 单元格中的数字减去。 例如：=F4-(C10*(1+D10))。
    • 所有其他单元格从上方的单元格减去。 例如，J10 单元格具有以下公式：=J9-($C$10*(1+$D$10))。
  • 用于说明预测的折线图：
    • 将图表标题设为"最坏情况、预期情况和最好情况"（Worst Case, Expected and Best Case）
    • 设置范围为上述四列。
    • 将未来迭代列设为 X 轴。
    • 为剩余的每一列添加一个系列。
    • 选择以下复选框：使用第 1 行作为标题（Use row 1 as headers）、使用 G 列作为标签（Use column G as labels）、将标签视为文本（Treat labels as text）。

要维护跟踪器，在每个冲刺结束时，用团队已完成的故事点数量更新它。

高波动性降低可预测性

第一个例子是一个在过去九个冲刺中波动性较高的团队：

迭代 已完成故事点 速度 波动性
1 8 8 0%
2 15 11.5 43%
3 11 11.33 40%
4 7 10.25 35%
5 6 9.75 42%
6 15 9.75 42%
7 10 9.5 43%
8 6 9.25 46%
9 8 9.75 40%

假设团队待办事项中还有 200 个点，我们可以使用他们当前的速度和波动性来预测完成待办事项还需要多少个冲刺的最坏、预期和最好情况。

高波动性图表

团队将交付待办事项：

  • 在最好情况下，需要 24 个冲刺。
  • 在预期情况下，需要 30 个冲刺。
  • 在最坏情况下，需要 43 个冲刺。

如果每个冲刺持续两周，并且其他业务职能依赖预计的交付日期来协调他们的工作，那么最好、预期和最坏情况之间的 38 周差异不太可行。 这种广泛的变异性会削弱 Scrum 团队与组织其他部分之间的信任。

低波动性提高可预测性

第二个例子看的是一个在过去九个冲刺中波动性较低的团队：

迭代 已完成故事点 速度 波动性
1 9 9 0%
2 10 9.5 8%
3 11 10 10%
4 9 9.75 10%
5 8 9.5 14%
6 10 9.5 14%
7 9 9 9%
8 11 9.5 14%
9 9 9.75 10%

与之前的团队一样，这个团队有相同的最终速度，但波动性指标低得多。 在相同 200 个故事点的待办事项规模下，这个团队在沟通完成待办事项的更现实和可预测的时间表时更有信心：

低波动性图表

两个团队都完成了相同数量的故事点。 然而，波动性较低的团队可以传达 28 到 32 个冲刺的交付窗口（与 24 到 43 个相比），时间表上的变异性只有八周。 这种可预测性水平促进了 Scrum 团队与组织其他部分之间的信任。

降低波动性

如果您遇到高波动性问题，可以探索以下方法：

  1. 保持稳定、专注的产品团队。

    假设团队成员的时间分散在多个工作流中，并且没有一致地分配到同一个团队和工作流中。 在这种情况下，这可能导致速度波动。

  2. 将故事分解为更小的垂直切片。

    查看您最近完成的故事，并评估故事点的范围。 一个五点的故事比一个单点的故事有更多的复杂性和未知因素。 团队应该有意识地只将权重为一或二的故事拉入迭代。 如果您无法找出如何减少大故事的大小，考虑进行 工程 spike。 了解实现路径，并确定您的团队如何更增量化和迭代地处理这个故事。

  3. 了解流程瓶颈所在。

    您可以创建一个 自定义价值流分析报告， 该报告反映故事在冲刺中经过的工作流阶段。 该报告可以帮助在您的回顾会中集中讨论在冲刺周期中耗时最长的特定工作流阶段。

相关主题