您做错了：迭代计划，第2部分

在本系列中，我们将研究我们的工作方式以及原因。 更重要的是，为什么我们应该做事情，以及预期的结果是什么。 如果没有得到这些结果，也许您应该尝试做其他事情，或者重新调整您的期望。

现在，我知道根据标题，您会期待一些#NoEstimates东西，但今天不会。 您可以在此处找到#NoEstimates帖子 。

上一次 ，我们开始讨论迭代计划，尤其是为什么我们要计划迭代的长度。 让我们继续我们如何计划迭代的内容，并讨论故事点，相对估计计划扑克。

通常我们在这一点上开始计划仪式：

• 产品负责人的故事优先级高。 （这是修饰过程的结果，我们将在以后讨论）。
• 编写故事以供呈现和审阅。
• 尽管Scrum假定团队以前没有有关故事的知识，但通常不是这种情况。 至少有一些团队成员已经掌握了有关构建和测试内容的知识。 这些讨论可能已经影响了故事及其优先级。
• 计划会议的预期 结果是团队在迭代中“承诺”（ugh！）完成的故事列表，以便最终将它们演示给利益相关者。

接下来发生什么？

让我们从目的开始。 还记得迭代计划的承诺吗？ 短期内的可预测性，可以在团队和业务之间建立信任。 我们商定的计划是基础。

当履行“承诺”时便建立了信任。 但是在迭代的开始，我们只有故事列表。 我们如何批准计划？

我们需要在有限的时间内回答故事是否可以在迭代中完成。 我们的计划基于以下假设：

• 每个人都以相同的方式理解“完成”。
• 我们知道如何构建它。
• 将会浪费。
• 将会有改变。

我们做的计划的一部分是能力计划。 我们删除了所有不支持故事的已知团队可用性活动。 （刚刚意识到这需要一个自己的职位）。

虽然我们可以减少后两者的生产能力（吉姆将待几天，但琼的需求将在传统的粘糊糊中游泳，所以我们需要提高一点），但前两点并不是那么容易。 即使对“完成”进行了详尽的解释，也可能不是您所获得的（没关系），并且当我们学习如何进行构建时（我们也可以），我们如何改变它。

但是，假设我们考虑了可能出错的所有内容，这意味着我们知道我们可以在迭代中进行多少实际工作。 我们仍然需要回答我们适合的故事。 现在我们开始估算技术。

你的故事是什么？

故事点是一种通过使用组合单元来抽象实时估计的机制。 它是为在低信任度的环境中工作而设计的，在该环境中，企业总是询问“需要多长时间？” 团队说：“只要需要”。 抽象将消除讨论（至少那是希望）。 您可以了解到这里的情况 。 可以这么说，罗恩·杰弗里斯（Ron Jeffries）说：“我不确定我是否是故事点的发明者，但是如果我是，我很抱歉”。

通常用于故事点的斐波那契数，就像T恤衫的大小一样，是基于这样的想法：虽然我们精于精确地估计某些东西，但我们可以将两个或多个项目相互比较，例如“这至少是商品的三倍。我们最后一次冲刺了”。 斐波那契数以相同的方式散布，因此我们可以相对比较故事。 从来没有打算辩论某个东西是3分还是5分。 精度不是这里的重点，如果您要实现精度，那就错了。

最后，我们计划扑克。 其背后的想法不是估计“更好”，而是中和支配性意见，缩短达成协议的讨论，并根据分歧开放讨论。 将所有卡片放在桌子上时，我们消除了“不会超过三张，对吗？” 管理自我解答问题。 如果您很安静，则不喜欢争论，而只想回到工作上–您会说是三点。

如果投票中有离群值，则有些人不会以相同的方式看待这个故事。 这可能与理解，复杂性或经验有关。 需要讨论。 同样，3比5并不是离群值，需要进行大量讨论。 为了安全起见，请选择5。

这些机制可以帮助我们提出一些代表我们对工作理解的数字。 仍然是一个估计。 有了这个数字，我们感觉到了在迭代时间内可以做什么。 这不是承诺。 不应该这样对待它。

因此，当您以自己的方式进行估算时，请确保它对您的目的有所帮助。 否则更改它。

顺便说一句，故事点或我们估计的任何单位的问题之一是，我们记录估计的数字，以便基于它们进行未来的估计。 我们将在谈论速度时看到为什么这是错误的。

翻译自: https://www.javacodegeeks.com/2016/06/youre-wrong-iteration-planning-part-2.html