agile - 如何在 Scrum 中更改为使用故事点进行估算

Question

在 Scrum 中使用“天”作为估计任务的单位后，我发现很难改用故事点。我认为应该使用故事点，因为它们彼此之间更具可比性 - 更少依赖于完成任务的任何人的资格等。但是，当团队习惯于使用故事点时，要让他们开始使用故事点并不容易估计天数。

那么，如何对故事点进行团队更改？什么应该激励团队成员这样做，我们应该如何应用转换？

Answer 1

当我切换到积分时，我决定只有满足以下两点；1）找到并论证证明转换的合理性并说服团队2）找到一个简单的方法来使用它。

令人信服

我花了很多时间阅读这个主题，但最终找到了让我和我的团队信服的论点：几乎不可能找到两个程序员会同意一项任务所需的时间，但同样的两个程序员几乎总是会同意当显示两个不同的任务时，哪个任务最大。

这是您“估计”积压工作所需的唯一技能。在这里我使用了“估计”这个词，但在这个早期阶段，它更像是把积压工作从难到容易排序。

在积压工作中加分

这一步是在整个 Scrum 团队的参与下完成的。

开始在新的电子表格中一一删除故事，同时保持以下顺序：顶部最大的故事和底部的最小故事。这样做直到所有故事都在列表中。

现在是时候为这些故事加分了。我个人使用扑克计划量表 (1/2,1,2,3,5,8,13,20,40,100)，所以这就是我将用于此示例的内容。在该列表的底部，您可能会有微任务（需要 4 小时或更短时间完成的事情）。给每个微任务 1/2 的值。然后通过将值 1（在比例中的下一个）赋予故事继续列表，直到很明显故事更大（2 而不是 1，所以大两倍）。现在使用值“2”，继续往上看，直到找到一个显然应该是 3 而不是 2 的故事。继续这个过程直到列表的顶部。

注意：尽量将绝大多数分数保持在 1 到 13 之间。第一次你可能有一堆大故事（20、40 和 100），你必须将它们分解成小于或等于 13 的块.

这就是积分和原始积压。如果您有一个新故事，请将其与该列表进行比较，以查看它适合的位置（更大/更小的过程）并赋予其邻居的价值。

速度与估计

要估计完成该积压工作需要多长时间，请进行第一个 sprint 计划。将附加到团队选择的故事和VOILA！的总点数相加，这是您的第一个速度度量。然后，您可以将积压中的总点数除以该速度，以了解需要多少 sprint。

该速度将在前 2-3 个 sprint 中发生变化并稳定下来，因此密切关注该值总是好的

Answer 2

如果您想更改为使用故事点而不是持续时间，您只需开始在故事点中进行估算。（我在这里假设您有权为您的团队做出该决定。）

选择一个比例，可以是小、中、大，可以是斐波那契数列，可以是 1 到 5，无论选择一个并将它用于几个冲刺，这都会给你你的速度。如果您开始将比例从一个更改为另一个，则比例之间的速度将无法比较（即不要这样做）。这些估算应该涉及您所有的 Scrum 团队。

话虽如此，您仍然需要了解这将花费您多少钱。没有多少会计师会接受“我会告诉你这在 6 个月内要花多少钱”的答案。所以你仍然需要估计项目的持续时间，这会给你成本。这个估计可能会由团队中的高级人员完成

然后每个月你的速度都会告诉你和会计师第一次成本估算有多准确，你可以相应地进行调整。

Answer 3

首先让一天等于一个点（或一些严格的比例）。这是开始的好方法。经过几次冲刺后，您可以开始鼓励他们使用更多的相对点（即，这与那件事相比有多大）。

Answer 4

问题是故事点定义了努力。

天数是持续时间。

两人的关系几乎是随机的。 duration = f ( effort ). 该功能基于实际工作人员的技能。

一个人知道他们需要多长时间才能完成这项工作。那就是持续时间。日内。

他们不知道这种抽象的“努力”。他们不知道一个假设的平均技能的人需要多长时间才能做到这一点。

你能做的最好的就是——故事点（努力）和天数（持续时间）。

你不能用另一个替换一个。如果您尝试仅使用努力，那么您最终将需要花费几天的时间进行计划。您必须将一个人应用于故事点并计算工作的持续时间。