[敏捷开发实践] 敏捷团队如何应对Product Owner不断变化的需求

敏捷团队如何应对Product Owner不断变化的需求

敏捷项目推进中，经常会遇到 Product Owner 提出新的需求事项，或者在原来的Product Backlog上扩充范围的情况。

最可怕的情况是在Sprint迭代即将结束时，开发团队已经按照计划开发了User Story并且开始进行测试了，但是 Product Owner 不断的要增加新的需求，或者对已经开发完成的User Story提出了紧急变更，要做功能的修改。

通常一个Sprint迭代以2周~3周为一个Sprint周期。在Sprint迭代中，那么面对Product Owner 不断变化的需求，Scrum Master 和 Scrum开发团队应该如何正确的对待呢？

首先，Scrum Master 要和Scrum开发团队一起评估新的变更对当前Sprint交付价值所带来的影响。理论上，在一个Sprint迭代已经开始进行了，尤其是已经到了Sprint迭代的后期，是不允许接受变更的。即使Product Owner提出了变更，也需要在随后的Sprint中响应。但是在实践中，很少有Scrum团队能够做到这一点，尤其是遇到了很强势的Product Owner，或者客户方的“老板们”很强势，要求必须在本次发布新的功能。

当面对这种情况时：

• 如果满足了Product Owner的变更，并不会耗费太多的时间和资源时；或者变更的功能本身没有太大的技术风险，则可以响应变更，尽量让客户方满意。但是，因为增加了Sprint交付的质量风险，所以也需要和Product Owner及客户方的“老板们”讨价还价，说明存在一定的质量风险。
• 如果满足了Product Owner的变更&#