Scrum 中的时间跟踪 [关闭]答案

【问题标题】：Time Tracking in Scrum [closed]Scrum 中的时间跟踪 [关闭]
【发布时间】：2009-10-22 13:30:48
【问题描述】：

注意：在问这个问题之前，我做了详尽的搜索，并在其他各种问题中找到了一些答案，例如：

但是，我觉得这个问题没有得到直接解决（如果有，请告诉我）。

您在 Scrum 中是否根据在某项任务上花费的小时数/天数来跟踪时间，或者仅仅是该任务是否完成？你能调整这些任务和估计吗？

背景：我们新的开发副总裁来自 Scrum 环境，所以我们都在学习这个过程，但他带来的东西之一是非常谨慎的概念引用每个任务需要完成的实际小时数的估计值，以便随着时间的推移更准确地估计我们的估计值：因此，一旦项目开始，我们就无法添加新任务或调整这些任务的每小时估计值。

但我的理解是，敏捷实践，特别是 Scrum，基于任务是存储单个可交付目标的桶的概念，您可以在每次冲刺后随着客户需求的变化添加/删除/调整它们。

我意识到这可能会引起争论，但我认为将 Scrum 视为一个过程，其中只有一个概念是该系统的“正确”哲学。

【问题讨论】：

我投票结束这个问题，因为它与编程无关。
哇！ 8年后！我认为softwareengineering.stackexchange.com 成为 6 年前的事情了？所以这是在没有其他地方之前。
我们只是在清理旧问题。
不，这完全有道理：应该迁移到那里吗？
老题不能迁移，迁移有时间窗口

标签： project-management agile scrum time-tracking

【解决方案1】：

您是否根据在某项任务上花费的小时数/天数来跟踪 Scrum 中的时间，或者仅仅是该任务是否完成？

我跟踪预计剩余工作。这是一个必须有的信息。没有这个，你就无法绘制燃尽图。没有燃尽图，你不知道你在“哪里”，你不知道你的 Sprint 是否还在正轨上。这将使这个决策工具变得毫无用处。是的，燃尽图不是一个跟踪工具，它是一个决策工具。

你能调整这些任务和估计吗？

当然！

实际上，团队拥有估算，没有其他人拥有，ScrumMaster 的工作就是保证这个原则得到应用。这应该已经回答了这个问题。但还有其他原因。

正如我所说，Sprint Backlog 和 Burndown 图表是决策工具，因此应该代表您的实际情况。如果你隐藏现实，如果你不透明，这些工具将无法帮助你做出任何有价值的决定，它们将毫无用处。想一想，如果数字没用，那么好看的数字又有什么意义呢？如果它不能反映现实，那么“漂亮的燃尽”又有什么意义呢。

因此，在 Sprint 期间，团队成员显然应该尽快更新对剩余工作的估计（向上或向下）。如果任务估计最初是 6 小时，但团队发现需要完成更多工作并且任务实际上需要 8 小时，则团队应相应地更新 Sprint Backlog。如果有人在最初估计需要 4 小时但仍需要 2 小时工作的任务上花费了 4 小时，则应在 Sprint Backlog 中报告这 2 小时。如果团队发现必须完成但未确定的任务，则团队必须将此任务及其估计添加到 Sprint Backlog。只要您使用随着时间的推移收集的知识更新积压工作，一开始就不准确也不是问题。越早进行这些更新，您就能越早适应并做出决定。

也就是说，保留“初始估计”并将其与“实际完成所花费的时间”进行比较会很有用。但不是为了跟踪目的，只是为了帮助团队做出更好的估计。实际上，如果您正在过渡到 Scrum，我建议不要这样做。当您学习 Scrum 价值观和原则时，通常还有许多其他障碍需要解决，还有很多其他事情需要首先改进。如果您这样做，请注意瀑布守护进程。准备好与他们战斗，他们可能会很快回来。

【讨论】：

我选择了这个答案，因为它完全符合问题的所有标准，并且提供了大量友好的信息。谢谢帕斯卡！

【解决方案2】：

我在这里看到的答案没有错，但我认为它们并没有真正解决您的问题。

我想你是在问，“应该我跟踪在某项任务上实际花费的总小时数吗？”答案是，“如果你需要，你可以，但它不是 Scrum 的一部分。”

Scrum 是一个非常轻量级的过程。它只定义/需要使 Scrum 工作所需的内容。您可以（并且在许多情况下可能应该）在 Scrum 之上覆盖其他流程，以满足您的组织需求。例如，如果跟踪实际花费在某项任务上的总小时数使您能够更好地估计未来的类似任务（正如您的副总裁所希望的那样），那么这可能是跟踪总小时数的一个很好的理由，只要它没有过多地干扰生产性工作。或者，也许您需要知道总小时数以进行计费。因此，仅仅因为 Scrum 不需要某些东西并不意味着你不应该这样做。

但是，就 Scrum 本身而言，没有必要跟踪实际花费在一项任务上的总小时数。任何 Scrum 工件都不需要它，它只跟踪估计的剩余时间。

【讨论】：

这是一个非常敏捷的答案。有很多原因您可能想要添加更明确的跟踪实际花费在 scrum 之上的时间。最常见的可能是成本会计。也就是说，能够让团队花时间进行有意义的会计工作。

【解决方案3】：

我不知道我们的实现是否“正确”，但我们所做的是：

添加了待办事项，我们在上面加上了估计的复杂度数（相对于其他待办事项）。
在每个 sprint 之前，我们按优先级顺序（由产品所有者确定优先级）检查积压项目，将它们分解为任务，我们为此进行时间估计 （以小时为单位）。
当冲刺中的可用小时数用完时，冲刺已满

然后，在每天工作后的 sprint 期间，我们会调整我们一直在处理的任务的时间，以便它们显示我们认为在任务完成之前还剩下的小时数时间>。这意味着如果我有一个 6 小时的任务，工作一整天（我们认为一整天是 6 小时），然后觉得我还剩下 2 小时才能完成，然后我记下“剩余时间”从 6 到 2。如果任务是有时间限制的，我们当然需要检查实际使用的小时数。

【讨论】：

【解决方案4】：

我必须在这里添加一些东西，因为

但他带来的其中一件事是非常仔细地引用每项任务需要完成的实际小时数的估计值，以便随着时间的推移更准确地估计我们的估计值：因此一旦项目开始我们无法添加新任务或调整这些任务的每小时估算值。

只是简单的不是 scrum，所以我不知道你的副总裁从哪里得到他的信息。在计划下一个 sprint 之前，不会创建任务（称为 Sprint Backlog 项目）。它们是及时创建的，当然不是在项目开始之前创建的。在项目开始之前（Sprint 0），产品负责人创建产品待办事项并用故事填充它。他可以在项目期间的任何时间添加它。管理是他的。该团队在故事点或其他一些相关指标（理想的日子？）方面粗略地估计了这些故事。

以小时为单位的任务估算只是团队用来确定在 sprint 中要提交多少故事然后绘制进度以预测成功（燃尽）的工具。一旦团队凝聚并具有历史速度；它可能决定在几个小时内根本不进行任何跟踪，而只跟踪他们在故事点或故事数中的燃尽。如果团队不需要它来实现对 sprint 目标的承诺，那么以小时为单位进行估算本身就是一种浪费。

我会问副总裁，这些“非常谨慎”的估计会完成什么。

【讨论】：

【解决方案5】：

估计时间，但不在乎是否正确

只要确保你仔细并彻底估计任务。基本上你不会真正测量时间，因为它更容易出错。最好的方法是使用任务的时间估计作为故事点。这样您将获得：

如果您的时间估算值不正确，研究表明它们往往会始终处于偏差状态（准确度因素不会发生太大变化），因此可以轻松地将时间估算值用于故事点计算。
如果您在之前的 sprint 中凭经验成功完成了 x 个故事点，那么即使您的时间估计不正确，这一次您也可能会获得类似的结果。
您必须非常擅长估算所有故事任务。否则，您的 sprint 故事点往往会在执行过程中增加，您将无法按时完成任务 - 即使您的速度几乎保持不变
估计可能会发生变化，但与 #3 类似，请为这些更改保留一些 sprint 松弛时间，以满足 sprint 截止日期（演示日）。

但要保持时间估算，以实际了解哪些任务必须拆分或加入。

【讨论】：

【解决方案6】：

我们跟踪完成任务所花费的时间以及完成任务的剩余时间。剩余时间可以用来确定 Sprint 期间取得的进展，并预测我们是否能够实现 Sprint 目标。我们会更新任务的剩余时间，每天调整（有时会增加）。

花费的时间 - 据说 - 用于微观管理。它还使团队有机会获得有关估算准确性的一些反馈 - 并更好地估算 - 并展示中断如何阻止团队处理 Sprint 积压工作并因此减慢速度。

在 Scrum 流程中，单独的可交付目标称为待办事项，可以看作是任务桶。积压项目由产品负责人确定优先级，由团队估计，首先作为一个整体，然后逐个任务。可以修改积压项目的内容、范围、优先级和估计。

我们以时间单位估计积压项目和任务（积压项目的天数或周数，任务的小时数），并且我们应用一个焦点因素（专门用于 Sprint 任务的时间比率）来计算没有花在完成 Sprint 目标的任务上的时间。

【讨论】：

【解决方案7】：

关于时间跟踪，您正在寻找的是burndown chart。

Fredrik 解释了什么是烧毁，但没有使用该术语。本质上，您会定期重新估计特定活动的剩余时间。

因此，对于您关于我们是否跟踪时间花费的问题，不一定。 Scrum 喜欢使用 剩余时间。（你可以用故事点代替小时，原理是一样的，就像罗伯特解释的那样。）

关于您是否可以调整任务和估计的第二个问题，绝对可以。敏捷遵循“对变化做出反应”的理念；您优先考虑对客户最重要的事情。

然而，一些团队不希望在特定的sprint 开始后添加/删除/重新确定任务的优先级，因为这几乎是一种临时的工作方式，甚至 scrum 也需要一些结构和纪律。

声明“因此，一旦项目开始，我们就无法添加新任务或调整这些任务的每小时估算。”几乎可以肯定，这不符合敏捷精神。

【讨论】：

【解决方案8】：

我们使用Pomodoro Technique 来跟踪剩余时间。它的优点之一是所花费的时间以有规律的方式记录。

估计故事点中的故事后，我们根据番茄时间估计任务，并使用此估计（可能会临时重新估计）来判断剩余时间量。在 sprint 结束时，很容易看到我们最初估计的最不准确的任务，并改进我们未来的估计方式，因为我们在每个便利贴上标记了估计和完成的番茄钟数。

就冲刺而言，估计的剩余小时数只是衡量进度的一个指标，因此我们可以了解我们的燃尽点。它们是我们是否走上正轨的线索。重要的分数是完成的故事点。

【讨论】：

【解决方案9】：

根据定义，当为完全实施该项目而需要完成的所有任务还剩 0 小时时，该项目就完成了。您需要在 sprint 中跟踪剩余任务的剩余小时数。不是花在一项任务上的时间。为什么？因为我们对某件事情需要多长时间的了解并不完善，而且当我们应该在产品上工作时，试图提出一个超准确的估计，我们收获甚少。

您始终可以在 sprint 待办事项项下添加任务，因为您确定必须完成更多工作才能完全实施该项目，并且您应该每天更新剩余时间以完成（或在完成后将其设置为 0）完成任务）。

你应该告诉你的副总裁，根据你最准确的信息（今天）知道你什么时候发货，这比在过去设定一个数字/做出估计并且从不更新要好得多。这并不意味着重新估计用户故事（在发布结束之前不要这样做），它意味着用新任务更新 sprint backlog，以及活动任务何时在剩余时间内完成的最佳估计。

顺便说一句，进行准确估算的方法是使用故事点来规划您的发布，根据您估算的团队速度创建迭代计划，然后根据每个 sprint 结束时的输出不断更新迭代计划.经过几次冲刺后，您将非常准确地了解团队的实际速度，从而可以轻松预测何时发布具有所需范围的版本......或者在原始发布日期之前应该完成什么范围。使用当前项目中的实际项目数据来预测项目完成是一种软件工程最佳实践，因为它是进行预测的最准确方法。

【讨论】：