时间估计是否等于Scrum中的承诺？

如果估算不是一个保证，那么作为产品所有者，我如何在不知道需要多长时间的情况下交付项目？

如果我们将时间估算视为诺言，Scrum团队会更有效地工作吗？

故事中需要进行多少研究（准备工作，理解问题的努力）才能得出正确的估计？

估算工作后出现的意外技术问题（可能会严重干扰您的初始估算）会如何？

估计并不是一成不变的承诺。他们是团队可以就完成任务/故事所需的工作做出的最佳猜测。

在回答您的问题“作为产品所有者，我如何能在没有时间作为参考的情况下交付我的项目？”的答案是，您可以并且应该有时间作为参考（即，您将在某个日期发布）。您所没有的是交货中的确切范围。

请注意，我所说的对您用于驱动开发的每种方法都是正确的。Scrum与其他方法（例如Waterfall）之间的区别在于，在Scrum中，这一事实得到了承认并得到了解释。作为采购订单，您要做的是确定范围的优先级，并确保团队在任何给定的时刻是：

1. 处理最重要的（已读：有价值的）未交付功能（任务，需求，用户故事）
2. 已经成功完成了比当前正在处理的功能更重要的所有功能（这是指完成的定义：每个完成的故事都经过测试，接受，没有错误，并且功能完整）。

有了它，您现在可以放心地运输或交付，只要知道在任何给定的时刻，最新版本就是可以运输的最佳产品。这意味着在您最初的发布承诺之日，您将交付最好的产品。

当然，这并不保证它将包含您要求团队开发的每个故事，但是您知道其余不完整的故事当然是最不重要的，可以在以后轻松地发布。

此外，团队所做的估算将越来越好，使您可以早日确定发行版本结束时的范围。您将能够准时交付优质的固体产品，并在几周后提供一些其他较不重要的功能（当然，您将能够估计何时发布）。

至于所需的研究量，这里有一条收益递减规律。如果您将故事分解得足够小，那么进行一些研究就可以得出足够接近的估计。如果您弄错了它们，那么您将在下一个冲刺中进行修改，并且估计会更好。平均而言，在3-4个Sprint中，您应该对截止日期之前可以交付多少范围（或完成范围所需的时间）有所了解。

在Scrum中估算故事点时，您应该了解足够多的知识，才能真正开始编写该功能。估计并不会完全准确，因为敏捷开发方法论的重点是他们认识到您无法准确预测开发将花费多长时间。

您承诺交付的阶段是您将产品积压的故事接受到Sprint中。您有望在sprint中传递这些故事。

如果您确实做出了承诺，这意味着如果您似乎无法兑现诺言，您将愿意多花一些时间。实际上，某些故事所花费的时间比您想象的要长，而其他故事所花费的时间却比您想象的要少。

当团队进行足够的估算时，他们会做得更好。

您可能还想看看...

清洁编码器（书） -本书中有一章名为“承诺的语言”，也有一章是关于估算的，这确实令人大开眼界。

看板 -看板更像是运行开发的拉式风格-Scrum和看板的组合也称为“ Scrumban”，这两种思想都来自于此。

没有。

对sprint中每个已完成任务的所有估计的总和称为“ 速度”。速度定义为“每个冲刺的完成点数”，其中“点”是团队估算的单位。

因此，如果他们使用相同的方法进行估算并且团队稳定等，那么速度可以让您知道您的团队在下一个冲刺中可以产生多少。

这就是您可以完全确定团队可以交付的内容而不必做出任何随机承诺的方式。

估计工作量是进行预测的工具。预测既不是承诺也不是保证。不断对预测进行重新评估以考虑新知识，并应包括可能的替代方案，例如乐观和悲观的变化。

我们期待着敏捷。承诺给组织计划增加的价值不比预测多。

强烈推荐Mike Cohn的敏捷评估和规划

如果估算不是一个保证，那么作为产品所有者，我如何在不知道需要多长时间的情况下交付项目？

您没有一个大的估计值，而是在故事级别上有许多小的估计值。故事级别的许多估计误差平均起来。您不能同时承诺内容和日期。但是，您可以相当有把握地认为积压的清单将被发布（或者，有一个相当准确的日期（但不是固定的），该日期可以交付整个积压的日期）。

如果我们将时间估算视为诺言，Scrum团队会更有效地工作吗？

否。这导致估算值沙袋化，并将速度/燃尽图转换为无用的数据-这妨碍了团队的改进。

故事中需要进行多少研究（准备工作，理解问题的努力）才能得出正确的估计？

取决于您对精度的关注程度。您可以花费数周的时间精心准备每个估算，也可以快速给出真诚的估算，并希望误差会平均。第一种方法是为失败做好准备，因为估计以前从未做过的事情确实很困难，而软件工程则是关于从未做过的事情。

就个人而言，我认为尝试获得非常准确的估计并没有太大好处。我要做的是确保估算值足够准确-即，我没有错过任何可能导致故事偏离其估算值一个数量级的内容。（请参阅下一点）。

估算工作后出现的意外技术问题（可能会严重干扰您的初始估算）会如何？

小迭代。订购积压。小故事。危险的东西是您不知道的东西。缺乏对问题的专业知识会导致较低的估计值，但是您可以通过获取专业知识（更多详细说明）或进行“足够好”的估计来进行调整-所有这些都与风险管理有关。

如果估算不是一个保证，那么作为产品所有者，我如何在不知道需要多长时间的情况下交付项目？

这是对Scrum的最大误解之一。“我的项目需要多长时间？”的问题 假设您可以在某个时间点准确定义项目完成所需的内容。但是，关于Scrum的整个想法是，它承认您在从事项目工作时从项目中学到的东西将会改变项目的定义。

定义项目的最常见方法是列出其将具有的功能。通常，当所有功能都实现后，项目就完成了。但是，如果在进行项目时发现不需要一开始就确定的5个功能，但是人们在最初的6个月中想到的7个功能确实应该包括在内，该怎么办？这对需要多长时间的问题有什么影响？

另一个因素是，您学到的东西将改变您对如何实现某些功能的理解，并且随着您越来越接近实现每个功能，您的估计值也将发生变化。就我个人而言，我不愿将数字估算值放在不接近实现范围的任何事物上，例如使用“微小”，“小”，“中”，“大”，“巨大”或“史诗”之类的描述性估算值。那么，您所暗示的准确性并不比您估计的能力高。

说实话，“要花多长时间？”比“完成后会是什么？”更难被回答。会计师和传统商务人士对此表示讨厌，这就是为什么在某些组织中很难摆脱Waterfall的原因。

这也是为什么您需要大量谈论速度和指标的原因。软件项目中内置了一种海森堡的不确定性原理，如果您花费太多时间对测量进行微调，那么最终将导致极其精确的废话。

因此，不，估计不是一个承诺。这是一个估计。“承诺”是团队做出的在特定Sprint中完成某些功能或故事的承诺。

估算值必须足够准确，才能让团队确定他们可以紧密地适合Sprint的功能（或故事）。估计的准确性甚至比准确性更为重要，因为即使实际工作量通常是估计值的两倍，团队也将了解他们可以在Sprint中进行多少估计值工作。只要它始终处于关闭状态，他们就可以进行计划。