首页 / 知识

关于敏捷：Scrum Burndown问题

2023-04-17 01:43:00

Scrum Burndown issues

我们已经使用Scrum大约9个月了，并且在很大程度上已经取得了成功。但是，我们的燃尽图很少像"模型"图那样，而是更像是一个令人恐惧的过山车，伴随着呕吐而引起的爬升和下降。

为了解决这个问题，我们在进行Sprint原型设计和设计之前花了更多的时间，但在Sprint期间我们仍然发现比最初想象的要多的工作。注意：我的意思是，准备积压所需的工作要比首先想到的要复杂得多，而不是为积压确定新的项目。

这是Scrum的普遍问题吗？有人有任何技巧可帮助您顺利驾车吗？

我应该指出，我们的大多数开发工作都不是未开发的项目，因此我们在现有的大型复杂应用程序中维护功能。 Scrum是否仅因为您不知道现有代码将引发哪些问题而不太适合这种类型的开发？

在sprint开始制定开发细节之前，我们应该花多少时间？

更新：我们现在获得了更多的成功，并且行驶更加顺畅。这主要是因为我们在估计时采取了更为悲观的观点，这为我们在事情没有计划时处理事情提供了更多的喘息空间。您可以说它使我们更加"敏捷"。我们还试图改变这种看法，即燃尽图是某种时间表，而不是范围v资源的指示。

一些使事情变得顺利的技巧。

1)正如其他人所说的那样-尝试将任务分解为较小的块。更明显的方法是尝试更详细地分解技术任务。在可能的情况下，我鼓励您与产品负责人交谈，看看您是否可以缩小范围或"简化"故事。我发现后者更有效。如果团队和产品所有者都了解正在讨论的内容，那么轻而易举地调整优先级和估算就容易了。

我的一般经验法则是，任何估计值大于理想天数的一半都可能是错误的:-)

2)尝试进行短距离的冲刺。如果您要进行一个月的冲刺，请尝试两个星期。如果您要做两个星期，请尝试一个。

它限制了故事的大小-鼓励产品所有者和团队处理更容易准确估算的较小故事
您会更频繁地收到有关您的估算的反馈-而且更容易查看在冲刺开始时所做的决策与实际发生的事情之间的联系
通过实践一切都会变得更好:-)

3)运用站立和回顾的方式，多分析起伏的原因。是您花时间在代码库的特定区域上吗？是因为人们误解了产品所有者吗？随机的紧急情况使开发人员远离了团队？一旦您更加了解起伏在哪里，您通常可以专门解决这些问题。再次-短距离冲刺可以使这一点更加明显。

4)相信你的历史。您可能知道这个...但是我还是会说:-)如果摆弄那个可怕的传统Foo包比您认为的最后一次冲刺花费了3倍多的时间-那么它也将花费您认为的3倍下一个冲刺。不管您认为这次您的工作效率如何；-)相信历史，并使用"昨天的天气"之类的东西来指导您明年春季的估算。

希望这可以帮助！

我很高兴听到Scrum在很大程度上已经为您成功-比让Sprint精简图表看起来理想更重要。冲刺燃尽只是团队的一种工具，可以帮助团队了解冲刺目标是否已步入正轨。如果团队一直在达到冲刺目标，那么我不会太担心图表看起来像过山车。一些建议

在sprint回顾期间，询问团队其他工作来自何处
冲刺初期没有良好的验收测试可能会导致额外的工作
没有积压的积压可能会导致额外的工作。一个好的经验法则是至少花费团队时间的5％来考虑下一个冲刺的故事。
监控进行中的工作-团队是否同时进行过多工作？
在sprint计划期间-团队对构成故事的任务的分解感觉如何？

如果您尚未达到冲刺目标，请使用已建立的团队速度降低下一次冲刺的速度。跑步之前，您必须先学会走路。

以我的经验，Scrum肯定更着眼于新开发而不是维护。新开发比维护旧的大型代码库更可预测。

话虽如此，一个可能的问题是您没有将任务分解成足够小的块。人们通常对软件计划有一个普遍的问题，就是他们认为"哦，这项任务需要我两天时间"，而没有真正考虑完成该任务的内容。通常，您会发现，如果您坐下来考虑一下，该任务将包括执行A，B，C和D，并且最终需要花费超过2天的时间。

正如其他人所说，我希望燃眉之急会越来越大。东西发生了！您应将"上下"位用作回顾的基础。

确保每个人都清楚"完成"是什么意思，并使用这种共同的理解来帮助推动您的计划会议。通常，列出可以完成的工作将(a)帮助您记住您可能忘记的事情，并且(b)可能会触发更多的想法，以供日后浮出水面的任务使用。

需要考虑的另一点-如果您每个月使用不可预测的代码库工作，我仍然希望您的速度正常化到一个合理的稳定水平。只需对照计划的工作跟踪您的成功，并在计划时最多使用已完成的项目。然后专注于您的计划外任务，看看是否有任何模式表明您可以做一些不同的事情以将这些事情包括在计划工作中。

我们正在将"有时间限制的"任务用于计划外的任务。每当需要进行高优先级的工作或突然出现错误时，我们都可以使用时间范围内的时间(但是，我们永远都不能低于零)。
这种方法的另一个优点是，我们可以轻松地跟踪哪些未预见的任务，并在我们的下一个冲刺计划中将这些事情考虑在内。

我的燃尽也有类似的问题。我通过细化燃尽中包括的内容来"修复"它。

SiKeep评论：

Its progress against the backlog
selected for that sprint, which may or
may not end up as a release.

既然您为sprint选择了某些东西，那就是燃尽中的事情，所以我不知道所有"新工作"都应该出现在燃尽中。我将看到它进入了待办事项列表(不影响燃尽)，除非它足够重要以进入您当前的冲刺(燃起之后燃起了燃眉之急)。

也就是说，如果趋势线基本上遵循您的预期速度，则小幅的上下波动是正常的。我会担心您提到的过山车趋势。但是，通过仅在当前sprint中添加高优先级项来隔离燃尽的想法可能有助于减轻燃尽方面的这些起伏。

就像其他人所说的，冲刺开始之前的计划应该很短(不超过4个小时)。

我有类似的问题。我以前的团队(工作了一年多)很大，我们为一系列的初始产品发布维护了一个非常庞大且快速变化的代码库。我们的倦怠看上去很可耻，但这是我们有史以来最好的。

可能有助于(使您的图形看起来更好)的一件事是坚持承诺的小时数/点数。如果您低估了一项任务，并且必须加倍工作，请从冲刺中抽出一些东西。如果您执行一项新任务，那么显然比您的团队承诺将其他任务淘汰的优先级更高。

我们尝试在计划内和计划之前将任务分解为许多任务，但这似乎无济于事。实际上，这只是给我们提供了更多该死的门票，以便在冲刺期间进行跟踪。需求开始转移到票证上，(毫不奇怪)在所有洗牌中迷失了。

在我的新团队中，我们采取了一种非常激进的方法，并开始制作大票(大约一周之久)，上面写着" ProjectX中的v1.2功能实现"。 ProjectX(包括1.2版)的要求/功能列表保存在Wiki上，因此票证非常干净，仅跟踪已执行的工作。这为我们提供了很多帮助-尽管我们不断摆脱冲刺任务来帮助其他团队或扑灭大火，但我们可以减少门票记录的方式，并且能够完成所有冲刺。

当(且仅当)我们(被男人)强迫携带新物品时，我们继续将物品从冲刺中推出。

另一个对我们有帮助的简单提示：在您的工作量中增加"总的冲刺时间"。这应该是所有估计的总和。保持这条线的平坦可能会有所帮助，并增加团队可能面临的问题的可见性(假设这不会使您降级……)

-ab

文章这是您的燃尽图吗？解释燃尽图表中给定状态的含义。它还提供了处理建议。

本文中描述的一些示例：

enter image description here