Scrum开发人员……还是我吗？

Question

3

我在一个SCRUM团队工作，刚刚我们进行了一次扑克会议。我对“如何扑克”有一个想法，但我的团队有另一个想法。我今天来问你，我应该改变我看待扑克的方式，还是环境（团队）不够“SCRUM-enaugh”...

我们有这个故事...我打了50个storypoints（数字不重要，想法是），2个同事打了10个，其余的团队平均打了25个。我们稍微讨论了一下，决定重新扑克。

由于在谈话过程中我的经验并没有得到改善，需求也没有改变，我决定仍然打50分，而其他团队则“同意”对其进行了25个storyPoints的估计。

25 remained.

我的观点是：经过讨论，我认为对故事的了解程度保持不变，需求也保持不变，因此我的估算也不变。

团队的观点是：经过讨论，我们发现有两个人完全知道这个故事是关于什么的，并且他们估计为25，所以我们要扑克牌打25分，因为“团队需要付出25的努力”。

我应该改变我看待扑克牌的方式，还是环境（团队）不够“SCRUM”？谢谢你们。

- tartak

这个问题更适合在programmers.stackexchange.com上讨论。 - Michael Berkowski

3

我投票关闭此问题，因为它与编程无关。 - Vadim Kotov

3个回答

1

这就是我们团队所谓的“冲突解决”。每次我们在项目上组建一个团队时，我们的团队章程的一部分就是让每个人都同意一个“冲突解决模型”。我们使用这个模型来确保在没有100%共识的情况下，我们有一个所有人都同意的模型来解决分歧。

在你们的情况下，你们的模型从讨论和重新评估开始，试图让大家达成相同的数字。当这种方法失败时，你们团队中的大多数人似乎认为将平均值/最多投票作为估计是正确的。根据你的问题，我倾向于认为你不同意那种方法。

在我们的一些团队中，我们使用“竞争”模型，比如石头剪刀布，来确定胜者。有时它总是“最高得分者获胜”，这样如果抓住故事的人需要更多时间，他们就有了完成任务的积分。有时它是“多数规则”，就像你们团队的情况一样。

我建议你的Scrum Master或产品负责人让团队达成一致的模型，以便每个人都知道他们正在做什么。以下是一个示例模型：

显然，这可能不是您将要使用的模型，但它是如何让团队达成一致且始终有结果的示例，并仍允许首先进行讨论的基本原则。最重要的是，每个人都知道模型是什么，每个人都同意它。

- Jay S

你的想法非常有趣，我认为这完全可行。感谢你的回答。 - tartak

1

如果你能够证明，那么你就不必改变你的估算。但如果你能够证明，那么团队就不够“SCRUM”。然后，团队需要经过估算程序并检查改进的空间 :-)

- Bharath Krishnamurthy

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Bernard Notarianni · Accepted Answer

我觉得情况还不错。当讨论后人们仍未趋于相同的估计时，通常会采用平均值（在您的情况下约为25）。

团队中的不同成员可能有不同的“偏差”：有些人倾向于高估所有故事，另一些人则倾向于低估。这就是为什么平均值是一个好的估计。

无论如何，在经过一些迭代之后，您和团队将更加了解这种类型故事的难度。估计应该变得更容易，因为所有团队成员都能参考以往的经验，而不是复杂度的最佳猜测。