用于估算Scrum工具的小时数的单位

Question

我一直在学习Scrum并尝试使用一种名为Acunote的工具。我的问题是关于每个任务我在那里的两个领域。他们是“估计”和“剩下的”。我应该用哪些单位？我使用故事点吗？剩下的呢？例如，我有一个任务需要10个单位，比方说。我在一天结束时填写剩下的剩余部分，我认为有多少“单位”需要我完成？

谢谢！

Answer 1

我有几点建议：

• 如果你是scrum的新手;使用白板，不要陷入特定工具的语义中;它会妨碍你的学习和收养。
• 将您的故事打破得足够小，这样您就不必创建和估算任务。
• 不要做几个小时的事情，估计那个级别是浪费时间。
• 烧掉故事点。

团队“思考”他们正在走上正轨，因为任务正在完成并被烧毁，这太容易和普遍了。然后他们到达sprint的末尾，发现5个故事都完成了90％而且没有完成。如果你烧毁故事，你实际上是在跟踪可交付的商业价值，而不仅仅是任意数量的开发者垃圾。

Answer 2

与往常一样，我的第一个建议是不在采用/学习Scrum时使用工具（我开始厌倦一遍又一遍地重复同样的事情:)。相反，从最简单的事情开始（产品Backlog的电子表格，Sprint Backlog的白板和便利贴）。这背后的基本原理是你想要学习和掌握Scrum，而不是工具。所以不要让工具告诉你如何做Scrum并推动这个过程。

然后，关于这个问题，有两种思想流派：1。Scrum在理论上说的是什么，2。有些人在实践中做了什么。

理论上，Scrum具有两个级别的估计：一个用于工作（任务）在当前Sprint中完成，一个用于更远的产品积压项目（PBI）。在产品Backlog级别，应该在具有低精度的Story / T-Shirt / Unit-less点估计项目（正在构建的“内容”）。这种方法避免了“分析瘫痪”的陷阱，并准确地反映了有关工作的一般不确定性。在Sprint Backlog级别，项目被划分为以小时为单位估算的任务（“如何”实现PBI）。单独的估算方案是合适的，因为任务描述了粒度工作（通常大约几个小时，从不超过16小时）。事实上，Scrum建议使用“理想的工程时间”来完成任务级别的估算。

在实践中，有些人不会在几个小时内估算，因为烧毁时间并不显示“真实”进度，这不是假的，他们更喜欢烧毁故事点（这实际上意味着物品已完成或不，它更二元）。

虽然我理解后一种方法的“精神”，但我并不适用它并坚持理论。实际上，由于前面提到的原因，以小时为单位估算对我来说确实有意义，而且我实际上发现它在Sprint期间更好地“控制”Scrum经验过程（在每天结束时，你应该更新估计的剩余工作量无论花费多少实际时间，这都会比较容易。

此外，我不喜欢只有小故事（这也可以被视为浪费）的缺点，但是当团队清楚地确定Sprint中需要做什么时（这有利于透明度并有助于产品负责人也要了解真正的工作量，尤其是“质量导向”任务。

最后，我认为你可以避免DancesWithBamboo提到的陷阱数小时。保持警惕并且：

• 首先关注最重要的PBI（及相关任务）。
• 特别注意未完成的任务，他们应继续在白板上移动（如果您使用列来表示例如“待办事项”，“正在进行中”，“待验证”，“已完成”等步骤“）;不动的任务是气味。
• 在完成上一项之前不要开始新项目。

因此，在我看来， 可以使用小时数，并避免在Sprint综合症结束时“没有做”。只是使用你的大脑（Scrum和/或任何工具都不会取代它，幸运的是我们）。

说完了，如果你不把你的工具扔掉，那么要回答的问题是：你想在燃尽时显示什么（点或小时取决于你是否将工作分解成任务，我给了我我的观点）和Acunote用来绘制燃尽的字段（即我应该在哪里更新剩余工作的估算）。如果您选择积分并且不使用任务，那么更新剩余的工作是没有意义的，除非它完全完成IMO（PBI完成或不完成）。

Answer 3

恕我直言，你不应该使用剩余的SCRUM积分，因为积分应该是主观的，你可能不知道你走了多远。 我建议您将任务分解为较小的任务（这些将是您实现这些功能所需的步骤），然后将它们估计为几小时。这样，您可以轻松跟踪功能的进度

Answer 4

初始估算和剩余时间均使用小时数。任务通常以小时计算。

您可以使用Scrum点 - 或任何其他单位 - 来估算积压项目。

Answer 5

我不会为剩下而烦恼。故事或任务是布尔值（已完成或未完成）。 在我们的团队中，我们开始只接受预计不到一天的任务。这样，没有任何团队成员应该在连续两天的每日scrums上完成相同的任务。第三天肯定响起警钟！ 在任务中分解也很简单快速，因为它不需要太多估算。是不到一天：好的，否则将其分解。