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

Question

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

谢谢！

Answer 1

我有几个建议供您参考：

• 如果你是新来的Scrum;使用白板，不要陷入特定工具的语义中;它会妨碍你的学习和采用。
• 把你的故事打破得足够小，这样你就不必创建和估计任务。
• 不要用几个小时做任何事情，估计这个水平是浪费时间。
• 烧毁故事点。

对于团队来说，由于任务正在完成并被烧毁，“思考”他们正在进行，这对于团队来说太容易和常见了。然后他们到达冲刺的最后，发现5个故事都完成了90％，并没有完成任何事情。如果你烧毁故事，你实际上追踪可交付的业务价值，而不是任意数量的开发者垃圾。

Answer 2

恕我直言，你不应该使用剩余的SCRUM点，因为点应该是真正的主观，你可能不会说你走了多远。 我建议您将任务分解为较小的任务（这些将是实现这些功能所需的步骤），然后将其估计为几小时。通过这种方式，您可以轻松跟踪功能的进度

Answer 3

对初始估计值和剩余时间都使用小时数。任务通常以小时为单位进行估算。

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

Answer 4

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

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

从理论上讲，Scrum有两个层次的估计：一个工作（任务）在当前Sprint内完成，一个用于更远距离的产品待办事项项目（PBIs）。在产品待办列表级别中，应该在故事/ T恤/无单位点中估计项目（“正在构建的项目”），这些点的精确度较低。这种方法避免了“分析瘫痪”陷阱，并准确反映了所涉工作的总体不确定性。在Sprint Backlog级别，项目被简化为任务（PBI将实现的“如何”），并以小时为单位进行估计。一个单独的估算方案是合适的，因为任务描述细粒度的工作（通常大约几个小时，从不超过16小时）。事实上，Scrum建议使用“理想的工程小时”来完成任务级别的估算。

在实践中，有些人不估计小时，因为烧毁小时不显示“真实”的进步，这是不是假的，他们宁愿烧毁故事点（这实际上意味着一个项目完成或者不是，它更加二元化）。

虽然我明白了后一种方法的“精神”，我不应用它，并坚持理论。实际上，由于前面提到的原因，以小时为单位的估计对我来说确实有意义，而且我发现它在Sprint期间更好地“控制”了Scrum经验过程（在每天结束时，您应该更新估计的剩余工作不管实际花费的时间如何，而且在几小时内更容易）。此外，我不喜欢只有小故事（这可以被看作是浪费）的缺点，但是就像一个团队清楚地明确Sprint内部要做什么一样（这对透明度有好处并且有帮助产品负责人了解真正的工作量，特别是“质量导向”任务）。

最后，我认为你能避免受DancesWithBamboo与时间提到过的陷阱。请保持警惕：

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

所以，在我看来，这是可能使用小时，以避免在冲刺综合征的最后的“做什么”。只需使用你的大脑（Scrum和/或任何工具都不会取代它，幸运的是我们）。

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

Answer 5

我不会打扰剩下的。一个故事或任务是布尔（完成或未完成）。 在我们的团队中，我们开始只接受预计不到一天的任务。这样，任何团队成员都不应该在两次连续的每日混乱中进行同样的任务。第三天肯定响起警钟！ 在任务中分手也很容易和快速，因为它不需要太多估计。不到一天：好，否则分解。