敏捷研发模式下如何处理需求变更？

在项目管理中最头疼的莫过于变更了：工作快做完了，客户需求变更了，又得重新来；项目范围变更了，交付又要延期了……我们到了谈变更色变的程度，变更，让人痛心疾首。

但，在敏捷中，我们提倡“响应变化胜过遵循计划”，也就是所谓的拥抱变更。如果按照敏捷的拥抱变更，那还了得？项目岂不是遥遥无期？拥抱变更，那我的成本怎么控制？……等等等等，一系列的问号。本文带你详细解读敏捷的中的变更到底怎么处理。

一、为什么要变更？

客户、业务方等，他们应该还不会闲到就喜欢变更玩。变更，一定是基于一些缘由，比如市场变化、业务调整、资源冲突等不同的因素。闭门造出来的轮子可能还没上路跑就已经被市场淘汰了。如果我们一味的压着不让变更，可能你做出来的东西对于客户来说，已经是没有价值的了，或者已经无法解决他目前的痛点。那这样的产品对于客户来说就是食之无味弃之可惜的东西。也就造成了很多项目的烂尾，宁可不要了，也不在无用的产品上浪费金钱。所以，积极的拥抱变更，才能更好的满足客户需要，才能更好的适应VUCA时代下的变化。

二、拥抱变化是什么意思？

敏捷开发提倡拥抱变化，但并不是随时可以随意变更，其实不然。通常，在Sprint整个执行过程中，我们是拒绝变更的，否则在迭代结束后，很可能无法交付一个可用的产品。在敏捷中有两个工件：Product Backlog（产品待办列表,简称PB）和Sprint Backlog（迭代待办列表,简称SB），这里说的变化是指PB是一个不断变化的需求池，由PO（产品负责人）管理。在整个开发过程中，PO都可以对PB中的需求进行修改和完善，根据情况调整优先级，增添必要需求，删除无价值需求。而Sprint Backlog是Sprint计划会议上的输出，它是从PB的子集。在Sprint计划会议上PO需要向开发团队承诺在迭代进行中到结束都不会更改Sprint Backlog中的需求。

三、什么时候可以变更？

在每个Sprint结束后，都会召开Sprint评审会，基于当前的可交付成果，和干系人确认产品功能是否OK，以及和干系人确认下个迭代的工作计划。很多时候客户只有看到你的产品，才会发现哪些功能是要变更的。而这个Sprint 评审会，就是给我们提供了一个确认的契机。

在评审会结束后，除了收集到客户对成果的验收，还有一个重要的信息就是：接下来需要调整的需求。如果本次变更的需求优先级高于PO之前计划的需求，则接受变更，PO将会在下个迭代的Sprint计划会上提出来。我在给众多企业咨询过程中，发现一个变更最典型的根源是：PO在当前迭代中，没有梳理好下个迭代要做到事项。导致在Sprint评审会，只是评审了产品，没有确认下个迭代的需求。

所以实际工作中，PO需要梳理好Sprint N+1的需求，这样才可以更好的和客户确认迭代目标。综上，变更的最佳时机是在Sprint 评审会上，而在Sprint循环期间，尽量的“NO CHANGE”。也许你会说：我们的客户等不到那个时候，必须在Sprint期间变更怎么办？这种情况建议缩短迭代周期。迭代周期怎么设置，具体可参看之前的文章《Sprint迭代周期怎么确定？》

四、变更了怎么办？

1、已经在开发中的需求，原则上不允许变更

上面说过，在迭代计划会议上PO需要向开发团队承诺：在迭代进行中到结束都不会更改Sprint Backlog中的需求。迭代计划会需要全员参与，就本次迭代完成的增量达成共识，迭代开始后，为不影响开发节奏和进度，原则上是不允许修改Sprint Backlog中的需求。迭代进行时PO可以修改未进入迭代中的需求。

2、必须变更的需求需经过评估确认

有时候完全拒绝变更是不现实的，还是会有出现在开发过程中变更的情况。所有的变更，在实施前需回答3个问题：

1、需不需要变？

2、影响点有哪些？

3、实施变更和测试完成，需要投入多少资源？

对于措施，可根据不同的变更类型来执行。比如需求变更，PO需先通知团队所有成员，明确变更的具体内容：谁，干什么，为什么；然后再与相关人员讨论确定以上三个问题。

a.对于低价值的需求：直接拒绝变更，明确告知客户当前迭代的需求价值更高。

b.高价值、高优先级、影响小的需求：这类需求对迭代影响较小，可以接受变更。但需要研发一起评估工作量，采用“置换”原则。就是把未做的、等量的、优先级低的需求从当前迭代替换出来，放到PB需求池中。当然，是否要纳入本次迭代，需要得到研发人员的一致认可，而不能是PO直接命令团队接纳该需求。

c.高价值、高优先级、影响很大的需求：这类需求对迭代影响很大（指当前迭代中的需求继续做下去也没有价值）的需求变更，需要停止当前迭代，重新开始一个新的迭代，也就是我们说的“迭代终止”。这种情况需要全体干系人共同商定，并接受由此带来的影响，如进度延期、成本增加等。为避免或减少这种情况的出现，PO应该至少整理好接下来1-2个迭代需要做的Product Backlog。

总结

敏捷研发的理念之一是客户满意度，交付客户满意的产品。我们不能遇到变更就拒绝或者按照传统瀑布模式，走一个冗长的变更流程。而是要动态管理，邀请客户共同参与到研发过程中，尽可能多频次的给客户展示团队的成果，并获取其反馈。这样才能及时发现问题、调整应对，将变更的影响降到最低。这也是敏捷的三大支柱：透明、检查、适应。

以上文章由@丁仿  圣略咨询敏捷教练、管理圈APP创始人

原创发布于管理圈，未经许可禁止转载。