使用Scrum收集需求

Question

我的开发团队正致力于Scrum方法，差不多就是。我们有一个优先级优先的产品待办事项，我们将其分解为由烧毁图表跟踪的sprint。

问题是，产品经理(从涉众那里收集需求)将给我们一个需求的概要，比如在sprint开始前几天，或者一组sprint。

然后我们看一看，用什么是可行的(在技术上和合理的时间内)对它们进行修改。这将由管理层、其他产品管理部门和利益相关者进行审查，并且通常会进一步修订/调整，这往往会在一个循环中进行，直到它们都稳定下来为止。

同时，冲刺开始日期即将到来，我们开始抓住我们非常确定是稳定的需求。一旦完成了这些任务，随着需求的轻微变化，我们就会有无数天的代码调整。

虽然我知道需求不应该被认为是固定的，但我只是觉得我们管理得很糟糕，并且试图将瀑布式需求方法应用到敏捷开发中。

有没有人对这类问题有任何改进的建议或经验？

编辑：--对我们来说，这可能是最坏的情况--有时候需求是相当稳定的，我们实际上正确地使用了Scrum！然而，更频繁的是，我们在sprint中看到了上述场景，这就是为什么我会问这个问题。我知道上面的Scrum并不是真正合适的Scrum，这就是问题所在:)

Answer 1

把你的利益相关者带到scrums上来，通过产品经理，调用他们将消除任何“中国人的窃窃私语”。而且，他们需要优先考虑后台日志，而不是开发人员。当涉众在scrums上时，他们也会更好地看到变更的后果，虽然他们不会停止进行更改，但他们会更好地了解他们的更改如何影响迭代。

关于改变需求；参见敏捷宣言..。“拥抱改变！”

善良，

丹

Answer 2

是。这一点很重要:不要在冲刺开始后接受对故事的更改。

这将花费大量的精力代表scrum大师告诉产品所有者，这是不允许的。重要的是要向他们强调的是，作为开发人员，您承诺按照指定的方式来估计和交付故事，而任何更改都会否定这种努力。

在某些情况下，在sprint开始后，需求会合法地改变。在这里，考虑完全中止sprint。(这应该引起他们的注意。)

如果您的产品所有者发现这是太不灵活，考虑减少弹簧长度。我在一家用了一周短跑时间的商店工作过，我认为这是最低限度的，因为故事最后都是很小的。

有关更多细节，请参见Ken的敏捷项目管理 with Scrum。

Answer 3

我们的团队中有一个人代表产品负责人负责修正需求。有时我们有及时的要求，有时，我们有一些返工要做.QA接受在最新版本的sprint中对需求进行正式审查。

团队只应提交产品负责人明确定义的任务，否则无法估计它们。也许您可以缩短您的迭代，以便只有稳定的需求才能被规划？

如果您的流程要求这个评审周期，那么也许可以将您的sprintable项限制在产品经理/管理人员/涉众批准的范围内。