Scrum中的时间跟踪[已关闭]

预计剩余工作量 不是 一个跟踪工具,一个决策工具。

事实上,

因此,在Sprint期间,团队成员显然应该尽快(向上或向下)更新剩余工作的估计。如果任务估计最初是6小时,但团队发现还有更多的工作要做,而且任务实际上需要8小时,那么团队应该相应地更新Sprint待办事项列表。如果有人在一项最初估计为4小时但仍需要2小时工作的任务上花费了4小时,那么这2小时应该在Sprint待办事项列表中报告。如果团队发现一项必须完成但未确定的任务,团队必须将该任务及其估计值添加到Sprint待办事项列表中。只要你用随着时间的推移收集到的知识更新待办事项列表,一开始不准确就不是问题。你越早进行这些更新,就越早能够适应并做出决定。

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

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

然而,就Scrum本身而言,不需要跟踪任务实际花费的总小时数。任何Scrum工件都不需要它,因为它们只跟踪估计的剩余时间。

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

• 有 待办事项 复杂性
• 在每次冲刺之前,我们按照优先级顺序(由产品负责人确定优先级)浏览积压项目,并将其分解为 为此,我们做了一个 (以小时为单位)。
• 当sprint中的可用小时数用完时,sprint已满

我必须在这里补充一些东西,因为

很简单 不 所以我不知道你的副总裁从哪里得到他的信息。任务(称为Sprint待办事项)在计划下一个Sprint之前不会创建。它们是及时创建的,当然不会在项目开始之前创建。在项目开始之前(Sprint 0),产品负责人创建产品待办事项列表并用故事填充。他可以在项目期间随时添加。这是他的管理。该团队在故事点或其他相对指标(理想天数?)上粗略地估计这些故事。

以小时为单位估算任务只是团队用来计算在冲刺中要提交多少故事,然后绘制进度以预测成功(燃尽)的工具。一旦一个团队团结起来,达到历史速度;它可能会决定在几个小时内根本不进行任何跟踪,而只是在故事点或故事数量上跟踪它们的烧毁情况。如果团队不需要它来实现冲刺目标,那么以小时为单位进行估算本身就是一种浪费。

我想问副总裁,这些“非常谨慎”的估计将实现什么目标。

估计时间,但并不在乎它是否准确

只要确保你很小心,彻底估计任务。基本上,你并没有真正测量时间,因为它更容易出错。最好的方法是使用任务的时间估计作为 。这样您将获得:

1. 如果你的时间估计不准确,研究表明,它们往往会一直不准确(准确系数变化不大),因此时间估计可以很容易地用于故事点计算。
2. 如果你凭经验做到了
3. 你必须非常善于估计所有的故事任务。否则,你的冲刺故事点在执行过程中往往会增长,你将无法在截止日期前完成——即使你的速度几乎保持不变

但要保持时间估计,以实际查看哪些任务必须拆分或合并。

据推测,所花费的时间是用于微观管理的。它还为团队提供了一个机会,让他们对估计的准确性获得一些反馈,并更好地进行估计,并展示中断如何阻止团队处理Sprint积压的工作,从而减缓进度。

在Scrum过程中,单个可交付目标被称为待办事项,可以被视为任务桶。待办事项由产品负责人确定优先级,由团队估算,首先作为一个整体,然后逐个任务。待办事项的内容、范围、优先级和估计值都可以修改。

我们以时间单位(待办事项为天或周,任务为小时)估算待办事项和任务,并应用焦点因子(专门用于Sprint任务的时间比率)来解释为实现Sprint目标而没有花在任务上的时间。

关于时间追踪,你要找的是 burndown chart .

Fredrik解释了什么是烧毁,但没有使用这个词。从本质上讲,你经常重新估计 对于特定的活动。

那么,对于你提出的我们是否追踪时间的问题 不一定。Scrum喜欢与 剩余时间

对于你的第二个问题,即你是否可以调整你的任务和估计,当然可以。敏捷遵循“对变化做出反应”的哲学;你优先考虑对客户最重要的事情。

冲刺 一旦开始,因为这几乎是一种临时的工作方式,甚至scrum也需要一些结构和纪律。

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

Pomodoro Technique 以跟踪剩余时间。它的一个优点是,所花费的时间是以一种有纪律的方式记录的。

在以故事点估计故事后,我们根据番茄来估计任务,并使用这个估计(可能会临时重新估计)来判断剩余的时间。在冲刺结束时,很容易看出我们最初估计的任务最不准确,并改进我们未来的估计方式,这是由于我们在每个帖子上标记估计和完成的番茄数量的方式。

根据定义,当为了完全实现该项目而需要完成的所有任务还剩0小时时,该项目就完成了。你需要在冲刺中跟踪的是剩余任务的剩余时间。不是花在一项任务上的时间。为什么?因为我们对某件事需要多长时间的了解是不完美的,当我们应该在产品上工作时,试图提出一个超准确的估计,我们收获甚微。

您始终可以在sprint待办事项列表项下添加任务,因为您确定了要完全实现该项必须完成的更多工作,并且您应该每天更新剩余的完成时间(或者在完成任务后将其设置为0)。

顺便说一句,准确估计的方法是使用故事点来规划你的发布,根据你估计的团队速度创建一个迭代计划,然后根据每个冲刺结束时的输出不断更新迭代计划。经过几次冲刺,你会对实际的团队速度有一个非常准确的想法,从而可以很容易地预测何时发布具有所需范围的版本。..或应在原发货日期前完成的范围。使用当前项目中的实际项目数据来预测项目完成情况是软件工程的最佳实践,因为这是进行预测的最准确方法。