用Scrum收集需求

Question

我的开发团队正在努力研究Scrum方法.我们有一个优先产品积压,我们分解为由燃尽图跟踪的冲刺.

麻烦的是,产品经理(从利益相关者那里收集需求)将为我们提供需求的概述,比如在冲刺开始前几天,或者一组冲刺.

然后我们仔细研究它们,用可行的方法(技术上和合理的时间内)进行修改.管理层,其他产品管理人员和利益相关者会将其发送给我们进行审核,并且通常会进一步修改/调整,这种情况往往会一直持续下去,直到全部安定下来.

与此同时,冲刺的开始日期已经到来,我们开始抓住我们非常肯定稳定的要求.一旦完成这些,我们将无休止地调整代码,因为需求略有变化.

虽然我知道不应该考虑修复需求,但我只是觉得我们正在严格管理这些需求,并尝试将瀑布需求方法融入敏捷开发中.

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

编辑:这可能是我们最糟糕的情况 - 有时需求非常稳定,我们实际上正确使用Scrum!但是,我们更频繁地在冲刺中看到上述情况,这就是我提出这个问题的原因.我知道上面的Scrum并不是很合适,这就是问题:)

Answer 1

是.这很重要:在冲刺开始后不要接受故事的变化.

这将代表scrum主人花费很多精力告诉产品所有者这是不允许的.向他们强调的重要一点是,作为开发人员,您承诺按照规定估算和传递故事,任何更改都会抵消这些努力.

在某些情况下,在sprint开始后,需求会合法地发生变化.在这里,考虑完全中止冲刺.(这应引起他们的注意.)

如果您的产品所有者发现这太不灵活,请考虑减小弹簧长度.我曾经在一家使用一周冲刺的商店工作,我认为这是最小的,因为这些故事的结果非常小.

有关详细信息,请参阅Ken Schwaber使用Scrum进行的敏捷项目管理.

Answer 2

把你的利益相关者带到scrums; 将它们打包将通过产品经理消除任何"中国人的低语".另外,他们需要优先考虑后台日志而不是开发人员.当利益相关者处于scrums时,他们也会更好地看到变化的后果,虽然他们不会停止进行更改,但他们将更好地了解他们的变更如何影响迭代.

关于要求的变化; 看敏捷宣言......"拥抱改变!"

善良,

担

Answer 3

"与此同时,冲刺的开始日期已经到来,我们开始抓住我们非常肯定稳定的要求.一旦完成这些要求,我们将无休止地调整代码,因为需求略有变化."

请不要称之为敏捷方法或scrum.

那只是疯狂.

如果你在sprint开始之后调整了一些东西,你就不会做得对.

你正在实现(实际上是你令人鼓舞的)不良行为.如果他们在sprint开始之前无法满足要求,您有两种选择.

1. 等待.这没什么不对.从长远来看,它更便宜.

2. 开始.然而.由于要求在冲刺期间是固定的,因此您必须在没有"调整"的情况下完成冲刺.变更成为积压的一部分.

   • 你可以做更短的冲刺.

   • 你可以简单地积压调整,直到他们知道他们造成了他们自己的问题.

此外,很多管理评论都不是很敏捷.这本身并不是错的.但这表明缺乏信任.敏捷意味着开发人员和产品所有者之间的协作和交互.这并不意味着另一层管理评审.