|
|
7 回复 | 直到 10 年前
|
1
8
在我看来,燃尽表不能变成负数。如果你完成了你的工作,你要么继续坐在椅子上什么也不做,这意味着你的精力消耗将保持在零。 如果你确实做了一些事情,那么应该将其添加到任务列表中,这意味着当你完成了添加到sprint工作负载中的任务时,工作倦怠会上升,然后又下降。 如果在sprint结束之前完成了原始工作负载,那么当新任务(单个任务,比如bug修复或其他什么,或者一个或多个新用户故事)再次添加时,sprint应该会显示一个小的峰值,一旦发现还有更多的空间。 然而,如果你的团队经常出现这种情况,你似乎总是低估你的速度,应该从一开始就开始投入更多的任务。我并不是说能够提前完成并承担更多的任务是件坏事,但如果这种情况发生在很多sprint中,那就表明团队从一开始就表现欠佳,要么是偶然的,要么是绝对确保他们不会在sprint中失败。 如果你的产品所有者同意的话,就这样吧。如果我是产品负责人,我会看到一个团队总是提前完成任务,我会努力让他们从一开始就承担更多的任务。这听起来可能比预期的要严厉一些。 |
|
|
2
5
燃尽表明在一个承诺范围内仍然存在。如果你因为超额交付而在承诺中添加了内容,则将其添加到图表中记录的数字中。结果,一个过度交付的团队会有一个朝着零的消耗,然后在那里一直徘徊到图表时间框的末尾。 为了显示您真正交付的是什么,请考虑一个燃耗或累积流程图。 编辑
|
|
|
3
3
当我们向sprint添加更多项时,我们会更新 剩余工程估算 要在sprint burndown图表中反映这一点: alt text http://www.movingsummit.co.uk/images/burndown_chart.JPG 但正如其他答案所指出的,这表明 剩余工程估算 改变了,不是原因(我们只是重新评估了工作还是增加了工作?)而不是工作的积累。不过,这可能不是问题。 为了表示已完成工作的累积,燃耗图更合适(我们在发布级别使用燃耗图)。工作负荷的燃耗可以表示已完成工作的进度,也可以表示需求的增加或减少(以及这对完成预测的影响): alt text http://www.movingsummit.co.uk/images/burnup_chart.JPG |
|
|
4
2
扩展y轴可以让每个人都清楚地看到,你已经超越了sprint的目标。通常这并不是什么大问题,因为你不会做那么多。 如果它成为一个经常发生或如果你去了一个重要的数额有问题,你的估计过程。也许你在处理业务的“非敏捷”方面过于谨慎。试着带大家一起去兜风。 |
|
|
5
1
将燃尽图的y轴延长到零以下是一个很好的跟踪实践 释放 进展。 在链接的图片上,你可以看到发布燃尽图-添加到发布范围的所有内容都超过了零。 我不建议对sprint burndown chart做同样的事情。你只需在剩下的工作中增加新的工作,显然你的倦怠会持续一段时间。 如果你使用白板来展示你的sprint燃尽图,那么最好在你添加新的故事/需求时用适当的注释来标记时间的位置。这样就可以很清楚地看到发生了什么,为什么你的精疲力尽上升了。 |
|
|
6
0
如果你一直对自己的情绪低落持否定态度,那就意味着你总是高估自己,因此“太早”完成工作。要解决这个问题,开始将估计值乘以小于1的因子(即0.75,3/4)(我忘记了正确的术语-它是“缩放”吗?)。对于一个sprint或三个sprint,看看它如何影响结果,可能需要几次迭代才能为每个开发人员获得正确的因素。这意味着你将能够适应更多的常规冲刺,而不应该提前结束。 |
|
|
7
0
我在此不同意以下观点:-)试着考虑以下场景:团队开始研究一个故事,并意识到有一定数量的工作没有计划,现在他们添加任务来完成这项工作。工作倦怠上升,但并非完全是因为一个好的原因,在这种情况下,不是范围变更,而是“错误的估计”,从团队的角度来看,这没有任何区别,因为信息仍然是:“这是需要完成的工作量”。 产品负责人呢?你有多想和别人说你已经超额交货了?对于团队来说,区分这两个案例,并在回顾性研究中使用它们来分析下一次如何改进评估,或者从一开始就致力于更多的评估,这有多重要?类似的方法被用来定义替代燃耗图( http://www.mountaingoatsoftware.com/scrum/alt-releaseburndown ,因此,重新建立图表并烧掉更多的内容,清楚地显示范围的扩大,烧掉的内容可能是团队在开始编写sprint中某个故事时发现了新任务;-)
CIAO
|
推荐文章