我的开发团队几乎都在使用 Scrum 方法论。我们有一个优先的产品积压工作,我们将其分解为由燃尽图跟踪的冲刺。
麻烦的是,产品经理(从利益相关者那里收集需求)会给我们一个需求大纲,比如在一个 sprint 或一组 sprint 开始前几天。
然后我们浏览它们,用可行的方法(技术上和在合理的时间内)修改它们。这会被送交管理层、其他产品经理和利益相关者进行审查,并且通常会进一步修改/调整,这往往会循环往复,直到一切尘埃落定。
同时,冲刺开始日期即将到来,我们开始抓住我们非常确定稳定的需求。一旦完成了这些,随着需求的轻微变化,我们将有无数天的时间来调整代码。
虽然我知道需求不应该被认为是固定的,但我只是觉得我们管理得不好,并试图将瀑布式需求方法融入敏捷开发中。
有没有人对此类问题有任何改进建议或经验?
编辑:这对我们来说可能是最坏的情况——有时需求非常稳定,我们实际上正确地使用了 Scrum!但是,我们在 sprint 中更频繁地看到上述情况,这就是我提出这个问题的原因。我知道上面的内容并不是真正正确的 Scrum,这就是问题所在:)