[敏捷开发实践] 敏捷团队如何应对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的变更，需要耗费太多的时间和资源，而且团队加班也未必能够确保功能交付和Sprint Test进行时，就一定要说明在本次Sprint交付时不能响应变更，希望在下一个Sprint迭代中再发布。毕竟这会对软件产品的质量产生巨大的风险。谁都不希望产品发布以后存在缺陷，哪怕是很小的缺陷，都会对用户造成不要的体验。 

尽管敏捷开发的理念是“拥抱变化”，但是变更并不能随时发生，Product Owner和客户方也不能随时提出了变更，Scrum团队就一定要立刻相应。Product Owner也是Scrum团队的组成部分，也是团队中的一员，有责任也有义务为软件产品的质量负责，需要和Scrum Master和Scrum开发团队进行深入的沟通确保顺利交付和新功能发布，也是需要控制变更的。

除了以上的观点之外，Scrum开发团队在Sprint迭代中，也需要为响应变更做一些“提前”的准备：

• 要使用工具，例如JIRA，严格规范的管理User Story和开发进度（计划开始日期，计划结束日期，实际开发日期，实际结束日期，User Story Point等），并且要能够让变更可以追溯（需求追溯）
• 变更的提出，和变更前后的内容一定需要有文字（或者设计图）的记录，需要文字性记录重要的沟通内容和过程。并且将其作为项目资产的一部分。
• Scrum开发团队要从项目的技术架构和设计上做一些准备。例如前后端分离的开发体系，API接口设计，Micro-Service等良好的设计等等。从软件体系结构上作出良好的设计，使得能够对于一些变更具有“兼容”能力。因为不知道何时，在哪里会发生什么样的变更，所以让软件开发的架构体系更具有“灵活性”。（一个有经验的开发团队，其实对于这一点在实践中都是很难得。但是如果做到了，Scrum团队的能力至少是可以得到证明的。）
• Scrum Master 一定要了解Product Owner的行事风格，和客户方的业务需求，在Product Owner和Scrum开发团队之间做好“桥梁”，让信息透明化。在需要维护开发团队利益时，要敢于说“不”。
• Scrum团队，包括：Product Owner、Scrum Master、Scrum开发团队要管理好项目的风险。
• 要善于利用工具：JIRA、Confluence、KANBAN、用户故事地图等工具，还有视频会议等来发布信息，共享信息。

有些时候，这种情况对于项目外包团队或者离岸开发团队很难，例如：Product Owner与Scrum开发团队分布在异地，甚至是不同的国家或地区时，由于沟通语言的障碍，工作文化和风格的差异，时间的差异等会增加沟通成本和管理的复杂度。但是软件交付的前提是质量，质量是容不得半点折扣的。所以，所有为了软件产品能够确保质量前提下的顺利交付而事实的沟通、尝试，甚至争论都是值得的。在Sprint迭代中，是否能够响应变更，能够响应多少（什么样性质）的变更，需要根据情况而定；不能简单的接受，也不能简单的拒绝。

但是可以肯定的一点是：以不能有效的完成开发（Coding—Sprint Testing—UAT）和牺牲质量为代价的变更是坚决不能接受的。即使收到了来自客户方的压力或者抱怨。短期内，甚至在本次Sprint发布中似乎降低了客户满意度，但是从项目长期来看，客户最终需要的是高质量的软件和软件交付。