Sprint是如何工作的

Question

我不是IT背景。现在正在研究产生一个想法。最初我们从瀑布方法论开始，现在使用敏捷。想要了解这个敏捷方法到底是如何工作的。请不要错误地考虑我的问题。请求您的投入。

1. 在sprint之间发现了一个bug，以前没有。这可能是因为在当前sprint中添加了一些特性。现在，PO应该为同样的故事写一个故事，然后等到下一次冲刺吗？
2. 是否应该假设每个sprint都有能力处理由于添加了新特性而创建/即将出现的bug？理解团队必须寻找避免but的方法，但是这里的解决方案是什么呢？
3. 在sprint中的积压还没有完成，它只是向前推进到下一个sprint。PO或任何人都不能告诉任何事情，因为这就是敏捷方法的工作原理。是真的吗？

Answer 1

首先，我要说，你没有具体说明一种方法。敏捷更像是一种做事的方式，如果你愿意的话，这是一种哲学。因此，不存在“应该这样那样做”的情况。

你想在冲刺中工作。这意味着你在计时你的努力，你可以在那个时间范围内做你能做的。在sprint中，明智的做法是允许测试和修复您所做的任何工作的bug。

现在，会有一段时间，在sprint完成之后，甚至对于更旧的更改，就会发现一个bug。对于这些bug，您可以做出一些选择。我想说的是，首先，你会想要评估一个bug的影响。如果有一个可以接受的解决方案，或者影响很低，那么您可以决定在sprint中修复这个bug。

如果影响很大，并且无法设计可接受的解决办法，那么您可能希望尽快修复它。我这样做的方法是从sprint中获取所需的容量并修复bug。然后接受它对冲刺所能提供的任何影响。

根据bug的复杂性和所需时间，您可能需要考虑首先构建一个解决方案，如果可以的话，并在下一个sprint中正确地修复它。

至于为错误写用户故事，我希望无论是谁报告错误或从用户那里获取报告，届时都会报告复制路径和预期行为，所以PO不需要实际编写任何东西。

Answer 2

你必须记住的是，冲刺的目的是帮助你设定和完成最后期限。

本质上，你是想知道你有多快就能编程出“特性”。然后你可以把你的特性列表乘以这个‘速度’，并说“我们应该在这个日期之前完成，因此软件的成本是X”。

在一个sprint开始时，您需要一些特性，然后说：“是的，我可以在一次冲刺中完成这些任务”。在冲刺结束时，你会说：“嗯，看上去我们的估计差了X%！更好的因素是，下次告诉顾客我们可能迟到了！”

之所以将事物分组为sprint，而不是每个单独的任务，是因为在编写功能时，它们之间存在着大量的相互作用。当你编程和估计的时候，把它们放在一起比较容易。

如果你在冲刺中添加或删除一些东西，你就会抛出你的数字，并把死线推回去。有时候有些事情会很重要，所以你必须承受这一打击。但如果可能的话你应该避免。

有些人确实把x%免费留给了计划外的东西，但在我看来，它并不真正有效。你只是在你的估计计算中增加了一个因素。“哦，我们没有把这一切都做好，但那是因为有比预期更多的虫子。”是吗？你实在说不出来。

可能发生的最糟糕的事情是，您不断地添加和移除正在进行中的sprint中的内容，因此您永远不知道您的估计值是否正确。当最后期限到来时，你会发现你还有很多原本计划好的功能要做。

将所有这些bug保留到最后，并有一组有限的已知bug来清除，这要容易得多。至少你只会超过一个已知的数量。

如果您担心错误的发现和修复之间的延迟，那么这可能是一个很长的问题。最好的方法是短跑。2周冲刺意味着在bug修复发布前4周。1周短跑意味着2周。反过来，这是一个很大的不同。