Scrum Burndown问题

Question

我们已经使用Scrum大约9个月了，它在很大程度上是成功的。然而，我们的燃尽图看起来很少像“模型”图，而是更像一个可怕的过山车，伴随着一些呕吐物引起的上升和下降。

为了尝试和解决这个问题，我们在sprint原型和设计之前花费了更多的时间，但我们似乎仍然在sprint期间发现了比最初想象的更多的工作。注意:我的意思是，满足积压所需的工作比最初想象的要复杂得多，而不是我们为积压确定了新的条目。

这是Scrum的一个常见问题吗?有没有人有什么建议可以帮你顺利解决呢？

我应该指出的是，我们的大部分开发工作都不是新开发的，所以我们在现有的大型复杂应用程序中维护功能。scrum不太适合这种类型的开发仅仅是因为您不知道现有代码会抛出什么问题吗？

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

更新:我们现在有了更多的成功和更顺利的旅程。这在很大程度上是因为我们在估计时采取了更悲观的观点，这给了我们更多的喘息空间来处理没有按计划进行的事情。你可以说它让我们变得更“敏捷”。我们还试图改变这样一种看法，即烧毁图表是某种时间表，而不是范围v资源的指示。

Answer 1

一些解决问题的小贴士。

1)正如其他人所说--试着把任务分解成更小的块。要做到这一点，更明显的方法是尝试更详细地分解技术任务。在可能的情况下，我鼓励您与产品负责人交谈，看看您是否可以缩小范围或“精简”故事。我发现后者更有效。如果团队和产品所有者都了解正在讨论的内容，那么处理优先级和评估就会更容易。

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

2)尝试做更短的冲刺。如果你要做一个月的短跑--试试两周。如果你要做两周的训练--试试一周。

• 它在故事大小上起到了限制作用--鼓励产品负责人和团队在更小的故事上工作，这些小故事更容易准确地估计，而且你可以更频繁地获得关于你的估计的反馈--而且更容易看到你在sprint开始时所做的决定与实际happened
• Everything通过实践变得更好之间的联系:-)

3)使用stand ups和retrospectives来更多地了解起伏的原因。当你花时间在代码库的特定区域时？是不是民间对产品负责人的误解？随机突发事件会占用团队的开发时间吗？一旦你对起伏的来源有了更多的了解，你通常可以具体地解决这些问题。再说一次--更短的冲刺可以让这一点变得更明显。

4)相信你的历史。你可能知道这个。但不管怎样，我还是要说:-)如果摆弄那个可怕的遗留Foo包花费的时间比你想象的要长3倍，那么它也会花费你认为下一次sprint的3倍时间。无论你认为这一次你的效率会有多高;-)相信历史，并使用像昨天的天气这样的东西来指导你明年春天的估计。

希望这能有所帮助！

Answer 2

我很高兴听到scrum在很大程度上对你来说是成功的--这比让sprint burndown图表看起来更理想更重要。sprint burndown只是团队的一个工具，它可以帮助团队知道它是否在实现sprint目标的轨道上。如果团队已经达到了冲刺目标，我就不会太担心图表看起来像过山车。几点建议

• 在sprint回顾期间询问团队，额外的工作来自
• ，额外的工作可能来自于在sprint
• 早期没有良好的验收测试，额外的工作可能来自没有良好整理的待办事项。一条很好的经验法则是，团队至少要花5%的时间提前思考下一个parallel?
• During的故事。

sprint监视器正在进行中-团队在sprint计划中做得太多了吗?团队对组成故事的任务的分解有何感想？

如果你还没有达到冲刺目标--在下一次冲刺中，使用已建立的团队速度来承担更少的任务。你必须先学会走路，然后才能跑步。

Answer 3

根据我的经验，Scrum肯定更倾向于新的开发，而不是维护。新的开发比维护一个旧的、大型的代码库更容易预测。

话虽如此，一个可能的问题是你没有将任务分解成足够小的块。人们对软件规划的一个普遍问题是，他们认为“哦，这个任务应该花我两天的时间”，而没有真正考虑做这个任务需要做什么。通常，你会发现，如果你坐下来想一想，这个任务包括做A，B，C和D，最后是两天以上的工作。