在Scrum工具中估计小时数的单位

Question

我一直在学习Scrum，并尝试使用一个名为Acunote的工具来使用它。我的问题是关于每个任务的两个字段。它们是“估计”和“剩余”。我应该使用什么单位来处理这些问题？我要使用故事点吗？剩下的呢？例如，假设我有一个任务需要10个单元。在一天结束的时候，我会用我认为需要完成的“单元”来填充剩余的部分。

谢谢!

Answer 1

我有几个建议给你：

如果你是scrum的新手，那就使用白板，不要被某个特定工具的语义所困扰；它会阻碍你的学习，让你的故事变得足够小，这样你就不必创建和估计任务了。

• 不要花时间做任何事情，在那个水平上进行估计是浪费时间。

• 烧掉故事点。

对于团队来说，“认为”他们走上了正轨，这太容易了，也太常见了，因为任务正在完成并被烧毁。然后，他们到达冲刺的末尾，发现5个故事都完成了90%，但什么都没有完成。如果你烧掉了故事，你实际上是在跟踪可交付的业务价值，而不仅仅是任意数量的开发人员垃圾。

Answer 2

像往常一样，我的第一个建议是在采用/学习Scrum时使用而不是工具(我开始厌倦一遍又一遍地重复同样的事情:)。取而代之的是，从可能工作的最简单的事情开始(产品积压的电子表格，冲刺积压的白板和便利贴)。这背后的理由是，你想要学习和掌握Scrum，而不是一个工具。所以，不要让工具告诉你如何做Scrum和驱动过程。

然后，关于这个问题，有两个学派: 1. Scrum在理论上说什么，2.一些人在实践中做什么。

从理论上讲，Scrum有两个级别的评估：一个是在当前冲刺内完成的工作(任务)，另一个是更远的产品待办事项(PBI)。在产品待办事项( Product Backlog )级别，项目(正在构建的“什么”)应该在Story/T恤/Unit-less点中进行估计，这些点的精确度较低。这种方法避免了“分析瘫痪”的陷阱，并准确地反映了围绕所讨论的工作的一般不确定性。在Sprint Backlog级别，项目被分解成任务( PBI将如何实现)，这些任务以小时为单位进行估计。单独的估计方案是合适的，因为任务描述了细粒度的工作(通常在几个小时的量级上，永远不会超过16小时)。事实上，Scrum建议使用“理想工程小时数”进行任务级估计。

在实践中，有些人不会以小时为单位进行估算，因为耗费的时间不会显示“真正的”进度，这不是错误的，他们更喜欢烧毁Story Points (这实际上意味着一个项目是否完成了，它更像是二进制的)。

虽然我理解后一种方法的“精神”，但我不会应用它并坚持理论。实际上，由于前面提到的原因，以小时为单位进行估计对我来说是有意义的，而且我发现它可以更好地“控制”Sprint期间的Scrum经验过程(在每天结束时，您应该更新估计的剩余工作，而不考虑实际花费的时间，使用小时会更容易)。

此外，我不喜欢只有小故事的缺点(这也可以被视为浪费)，但喜欢当团队清楚地确定Sprint中必须完成的工作时(这有助于提高透明度，并帮助产品负责人了解真实的工作量，特别是“面向质量”的任务)。

最后，我认为你也可以用几个小时来避免DancesWithBamboo提到的陷阱。只需保持警惕：

• 总是首先关注最重要的PBI(和相关任务)。
• 要特别注意未完成的任务，它们应该继续在白板上移动(如果您使用列来表示步骤，例如"todo“、"in progress”、"to be verified“、"done")；不移动的任务是 steps 。
• 在完成上一个项目之前，不要启动新项目。

因此，在我看来，使用小时和避免在冲刺综合症结束时“什么也不做”()是可能的。动动脑筋吧(幸运的是，Scrum和/或任何工具都不会取代它)。

话虽如此，如果你没有扔掉你的工具，那么要回答的问题是:你想在工作耗尽时显示什么(点或小时取决于你是否将工作分解为任务，我给了你我的观点)，以及Acunote使用什么字段来绘制耗尽的工作(即，我应该在哪里更新剩余工作的估计)。如果你选择了点而不使用任务，那么更新剩余的工作是没有意义的，除非它完全完成了IMO (一个PBI已经完成，或者没有完成)。

Answer 3

我想你不应该使用剩余的SCRUM分数，因为这些分数应该是非常主观的，而且你可能不能说你已经走了多远。我建议您将任务分解为较小的步骤(这些步骤将是实现功能所需的步骤)，然后以小时为单位进行估计。通过这种方式，您可以轻松跟踪要素的进度