Nat*_*int 11 agile project-management scrum time-tracking
注意:在提出这个问题之前,我做了详尽的搜索,并在其他各种问题中找到了一些答案,例如:
但是,我觉得这个问题还没有直接解决(如果有的话,请告诉我).
您是否将Scrum中的时间跟踪在任务上花费的小时/天数,或者只是该任务是否完成？你能调整这些任务和估算吗？
背景:我们新的开发副总裁来自Scrum环境,因此我们都在了解这个过程,但他带来的一件事就是非常谨慎地引用每个任务应该要求的实际小时数的概念.完成,目的是随着时间的推移更准确地估算:因此,一旦项目启动,我们就无法添加新任务或调整这些任务的每小时估算.
但我的理解是敏捷实践,特别是Scrum,基于任务的概念,即存储单个可交付目标的存储桶,并且随着客户的需求在每个sprint之后发展,您可以添加/删除/调整它们.
我意识到这可能是有争议的,但我认为将Scrum视为一个过程,这些概念中只有一个是该系统的"正确"理念.
Pas*_*ent 21
您是否将Scrum中的时间跟踪在任务上花费的小时/天数,或者只是该任务是否完成？
我跟踪估计的剩余工作量.这是必须拥有的信息.没有这个,你就无法绘制Burndown图表.如果没有Burndown Chart,你不知道"你在哪里",你不知道你的Sprint是否还在轨道上.这会使这个决策工具变得毫无用处.是的,Burndown图表不是一个跟踪工具,它是一个决策工具.
你能调整这些任务和估算吗？
当然!
实际上,团队拥有估计,没有其他人,ScrumMaster的工作是保证应用这一原则.这应该已经回答了这个问题.但还有其他原因.
正如我所说,Sprint Backlog和Burndown图表是决策工具,因此应该代表你真正的位置.如果你隐藏现实,如果你不透明,这些工具将无法帮助你做出任何有价值的决定,它们将毫无用处.想一想,如果它们没用,那么拥有好看的数字有什么意义呢？如果它不能反映现实,那么拥有"漂亮的燃尽"是什么意思.
因此,在Sprint期间,团队成员显然应该尽快更新剩余工作的估计(向上或向下).如果任务估计最初为6h,但团队发现必须完成更多工作并且任务实际需要8h,则团队应相应地更新Sprint Backlog.如果有人花了4小时完成最初估计为4小时但仍需要2小时工作的任务,那么这些2小时应该在Sprint Backlog上报告.如果团队发现有许多工作要做,但是这是不识别的任务,球队必须添加此任务及其估计Sprint Backlog中.只要您使用随时间收集的知识更新积压,并且在开始时不准确不是问题.越早进行这些更新,您就能越早适应并做出决定.
也就是说,保持"初始估计"并将其与"完成所花费的实际时间"进行比较可能很有用.但不是为了跟踪目的,只是为了帮助团队做出更好的估算.实际上,如果您正在转换到Scrum,我建议不要这样做.在学习Scrum值和原则时,通常还有许多其他障碍需要解决,还有许多其他需要改进的地方.如果你这样做,请注意瀑布守护进程.准备好与他们作斗争,他们可能会很快回来.
Cra*_*ntz 10
我在这里看到的答案并没有错,但我认为他们并没有真正解决你的问题.
我想你在问," 我应该跟踪实际花在某项任务上的总时数吗？" 答案是,"你可以,如果你需要,但它不是Scrum的一部分."
Scrum是一个非常轻量级的过程.它定义/仅需要使Scrum工作所需的内容.您可以(并且,在许多情况下,可能应该)覆盖Scrum之上的其他进程,以满足您的组织需求.例如,如果跟踪实际花费在任务上的总小时数使您能够更好地估计将来的类似任务(因为您的副总裁似乎想要),那么这可能是跟踪总小时数的一个很好的理由,前提是它不是过多地干扰生产性工作.或者,您可能需要知道用于计费目的的总小时数.因为Scrum不需要某些东西并不意味着你不应该这样做.
但是,出于Scrum本身的目的,无需跟踪实际花在任务上的总小时数.任何Scrum工件都不需要它,它只跟踪估计的剩余时间.
我不知道我们的实施是否"正确",但我们所做的是:
然后,在每天工作之后的sprint期间,我们调整我们一直在处理的任务的时间,以便它们显示我们认为在任务完成之前剩下的小时数.这意味着,如果我有一个6小时的任务,在它上面工作一整天(我们考虑一整天6小时),然后觉得我还有2个小时就完成了,然后我取下了"剩下的时间"从6到2.如果任务是时间框,我们需要检查实际使用的小时数,当然.