解释 Scrum 故事点

多年使用 Scrum 并服务过众多公司后，我发现人们常常会给故事点分配时间，比如 3 个故事点 = 8 小时工作时间。这不利于计划，也让你无法发挥 Scrum 的一项重要特性。

首先，让我们快速回顾一下故事要点的意义，以及我们希望通过使用它们来达到什么目的。

软件开发团队的成员通常并非拥有相同的专业知识和经验，有些人更擅长后端开发，有些人经验更丰富，等等。这些差异导致他们认为可以在 X 小时内解决某个特定问题，但 X 对团队每个成员而言价值巨大，再加上我们软件开发人员在预估时间方面往往过于乐观。我们该如何解决这些问题呢？

幸运的是，软件开发人员非常擅长评估问题的复杂性，高级开发人员和初级开发人员在复杂性评估方面的差异，与时间方面的差异相比，并不算大。

因此，通过将故事点与复杂性联系起来，我们可以对给定问题的工作量达成更普遍的共识，从而使团队能够预测他们在给定的时间段内可以处理多少复杂性。

需要考虑的重要事项：

• 请始终记住，这是一个迭代过程，迭代次数越多，结果就越好，所以不要指望第一次迭代就能完美完成所有要点。

• 永远不要更改用户故事的分值。你期望获得的一项重要收益是可预测性，而要做到这一点，你需要保持团队现有的错误模式不变。如果在迭代周期结束后更改用户故事的分值，这种模式就会变得模糊不清，甚至完全消失。

• 产品负责人的职责是将团队能够处理的复杂程度转化为高层管理人员需要了解的时间安排，而这绝不应该是开发人员需要考虑的问题。

• 如果为了在迭代周期内实现更高的复杂度而减少故事点数，那只会让自己吃亏。