Scrum中的时间跟踪

作者: Just do it
发布时间: 2025-01-25 07:17:26 (1月前)
转自：

8 条回复

0#
回复此人
不想吃东西 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 我们用的是 <a href="http://www.pomodorotechnique.com/" rel="nofollow noreferrer"> 番茄工作法 </A> 跟踪剩余的时间。它的一个优点是花费的时间以纪律的方式记录。 在估计故事点的故事之后，我们根据番茄钟估计任务，并使用这个估计（可以重新估计）来判断剩余的时间量。在冲刺结束时，很容易看出我们最初估计哪些任务最不准确，并改善我们未来的估计，因为我们在每个帖子上标记估计和完成的番茄钟数量的方式。 就冲刺而言，剩余的估计剩余时间只是进度的衡量标准，因此我们可以看到我们在哪些方面是燃尽的。它们是我们是否走上正轨的线索。重要的分数是完成的故事点。 </DIV>

编辑
1#
回复此人
نسر الصحراء | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 我必须在这里添加一些东西，因为 <BLOCKQUOTE> 但他带来的其中一件事就是非常谨慎地引用每项任务应该完成的实际小时数估算的概念，目的是随着时间的推移更准确地得出我们的估计：因此一旦项目开始，我们就无法添加新任务或调整这些任务的每小时估算。 </BLOCKQUOTE> 很简单的 不 </强> scrum所以我不知道你的副总裁在哪里得到他的信息。在计划下一个sprint之前，不会创建任务（称为Sprint Backlog Items）。它们是在项目开始之前及时创建的。在项目开始之前（Sprint 0），产品负责人创建产品Backlog并用故事填充它。他可以在项目期间的任何时候添加它。这是他的管理。团队在故事点或其他一些相对指标（理想的日子？）中估计这些故事大致相互对立。 以小时计算任务只是团队用来计算sprint中要承诺的故事数量，然后绘制预测成功（燃尽）的进度的工具。一旦团队凝聚并具有历史速度;它可能决定在几个小时内不进行任何跟踪，只是跟踪故事点或故事中的故事情节。如果团队不需要它来实现对冲刺目标的承诺，那么以小时为单位估算本身就是一种浪费。 我会问VP，这些“非常谨慎”的估计将会实现什么。 </DIV>

编辑
2#
回复此人
故人 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 我们跟踪完成任务所花费的时间以及完成任务所需的剩余时间。剩余时间允许确定Sprint期间取得的进展，并预测我们是否能够实现Sprint目标。我们更新任务的剩余时间，每天调整它（有时会增加它）。 花费的时间 - 据说 - 用于微观管理。它还使团队有机会获得关于估算准确性的一些反馈 - 并且更好地估算 - 并显示中断如何阻止团队在Sprint积压工作，从而减慢速度。 在Scrum流程中，单个可交付目标称为Backlog Items，可以看作是一堆任务。积压项目由产品负责人确定优先级，由团队估算，首先作为整体，然后按任务进行任务。可以修改积压项目的内容，范围，优先级和估计。 我们估计积压项目和时间单位的任务（积压项目的天数或周数，任务的小时数），我们应用焦点因子（专用于Sprint任务的时间比率）来计算时间而不是花在完成任务上以实现Sprint的目标。 </DIV>

编辑
3#
回复此人
不丶离 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 关于时间跟踪，你正在寻找的是一个 <a href="http://www.controlchaos.com/about/burndown.php" rel="nofollow noreferrer"> 燃尽图 </A> 。 弗雷德里克在不使用该术语的情况下解释了烧毁的原因。从本质上讲，你经常重新评估 剩余时间 对于特定的活动。 那么关于我们是否追踪时间的问题 花费 ，不必要。 Scrum喜欢与之合作 剩余时间 代替。（你可以用故事点代替小时，原则是相同的，正如罗伯特解释的那样。） 关于你是否可以调整你的任务和估计的第二个问题，绝对是肯定的。敏捷遵循“反应变革”的理念;您优先考虑对客户最重要的事项。 但是，有些团队不愿意添加/删除/重新确定特定任务的优先级 短跑 一旦它开始，因为这几乎是一种特殊的工作方式，甚至scrum需要一些结构和纪律。 声明“因此，一旦项目启动，我们就无法添加新任务或调整这些任务的每小时估算值。”几乎可以肯定不是敏捷的精神。 </DIV>

编辑
4#
回复此人
滔滔江水 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 我不知道我们的实施是否“正确”，但我们所做的是： <UL> <LI> 有 积压物品 补充说，我们估计 复杂 号码（与其他积压物品相关）。 </LI> <LI> 在每个sprint之前，我们按优先级顺序（由产品所有者确定优先顺序）查看积压项目，将其分解为 任务 为此我们制作了一个 时间估计 （以小时计）。 </LI> <LI> 当sprint中的可用小时数用完时，sprint已满 </LI> </UL> 然后，在每天工作之后的冲刺期间，我们调整我们一直在处理的任务的时间，以便它们显示我们认为的小时数 在任务完成之前离开 。这意味着，如果我有一个6小时的任务，在它上面工作一整天（我们考虑一整天6小时），然后觉得我还有2个小时就完成了，然后我取下了“剩下的时间”从6到2.如果任务是时间框，我们需要检查实际使用的小时数，当然。 </DIV>

编辑
5#
回复此人
咿呀哟 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 根据定义，当需要完成的所有任务以完全实现该项目还剩0小时时，就完成了一个项目。您需要在sprint中跟踪的是剩余任务的剩余时间。没有花费在任务上的时间。为什么？因为我们对某事物将花费多长时间的知识是不完美的，并且当我们应该在产品上工作时，我们通过尝试提出超准确的估计而获得的收益很少。 您总是被允许在sprint backlog项下添加任务，因为您确定了为完全实现项目必须完成的更多工作，并且您应该每天更新剩余的小时数（或者在完成任务后将它们设置为0））。 您应该告诉您的副总裁，根据您最准确的信息（今天）知道何时运送产品远比设置过去的数字/进行估算并且永远不会更新它更好。这并不意味着重新估计用户故事（在发布结束之前不要这样做），这意味着使用新任务更新sprint backlog，以及关于活动任务何时在剩余时间内完成的最佳估计。 顺便说一下，准确估算的方法是使用故事点计划发布，根据估计的团队速度创建迭代计划，然后根据每个sprint结束时的输出不断更新迭代计划。在极少数冲刺之后，您将对车队的实际速度有一个非常准确的了解，从而可以很容易地预测何时将您的发布版本发送到所需范围......或者在原始发货日期之前应该完成哪个范围。使用当前项目的实际项目数据来预测项目完成是软件工程的最佳实践，因为它是进行预测的最准确方法。 </DIV>

编辑
6#
回复此人
离线请留言 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 我在这里看到的答案并没有错，但我认为他们并没有真正解决你的问题。 我想你在问，“ 应该 我跟踪总小时数 实际上花了 在某项任务上？“答案是，”你可以，如果你需要，但它不是Scrum的一部分。“ Scrum是一个非常轻量级的过程。它定义/仅需要使Scrum工作所需的内容。您可以（并且，在许多情况下，可能应该）覆盖Scrum之上的其他进程，以满足您的组织需求。例如，如果跟踪实际花费在任务上的总小时数使您能够更好地估计将来的类似任务（因为您的副总裁似乎想要），那么这可能是跟踪总小时数的一个很好的理由，前提是它不是过多地干扰生产性工作。或者，您可能需要知道用于计费目的的总小时数。因为Scrum不需要某些东西并不意味着你不应该这样做。 但是，出于Scrum本身的目的，无需跟踪实际花在任务上的总小时数。任何Scrum工件都不需要它，它只跟踪估计的剩余时间。 </DIV>

编辑

登录后才能参与评论