project-management - Scrum 中的时间跟踪

标签 project-management agile scrum time-tracking

注意:在提出这个问题之前,我进行了详尽的搜索,并在其他各种问题中找到了一些答案,例如:

但是,我觉得这个问题还没有被直接解决(如果有,请告诉我)。

您是否根据任务所花费的小时/天来跟踪 Scrum 中的时间,或者只是跟踪该任务是否完成?您可以调整这些任务和估算吗?

背景:我们的新任开发副总裁来自 Scrum 环境,因此我们都在学习该流程,但他带来的其中一件事是非常仔细的概念引用每项任务需要完成的实际时间的估计,目的是随着时间的推移使我们的估计更加准确:因此,一旦项目开始,我们就无法添加新任务或调整这些任务的每小时估计。

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

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

最佳答案

Do you track time in Scrum as a function of hours/days spent on a task, or simply whether that task is complete or not?

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

Can you adjust those tasks and estimates?

当然!

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

正如我所说,冲刺待办事项列表和燃尽图是决策工具,因此应该代表您的实际情况。如果你隐藏现实,如果你不透明,这些工具将无法帮助你做出任何有值(value)的决定,它们将毫无用处。大家想一想,如果数字再好看又有什么用呢?如果“好看的燃尽图”不能反射(reflect)现实,那么它有什么意义。

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

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

关于project-management - Scrum 中的时间跟踪,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/1607214/

相关文章:

agile - 你如何处理 Scrum 中一堆不相关的小错误?

visual-studio - 更改网站项目的名称(命名空间)

ios - 无法将嵌入式二进制文件(其他项目)添加到 XCode 中的项目依赖项

project-management - 如何将 QA 集成到 Sprint 中

agile - 如何将FogBugz与敏捷方法一起使用?

agile - 敏捷环境中的需求、规范和管理

project-management - 如何告诉别人他应该提高他的技能?

python - 一个文件中的所有代码

tfs - TFS 的燃尽图,理想趋势从最大值(剩余小时数)开始,而不是第一次日期(剩余小时数)

debugging - Scrum,如何处理冲刺中的错误以及如何估计错误的时间