敏捷开发中如何从容应对需求变更？

2022 年 4 月 28 日
本文字数：2093 字
阅读完需：约 7 分钟

说起最让程序员痛心疾首的事，非需求变更莫属了。一度到了谈“需求变更”色变的程度，网上更流传着各种段子进行调侃，可见需求变更是工作中最令程序员头疼的事情了。原有的需求代码已经写了大半，或已经准备上线，此时再提出变更需求，就相当于造的房子，已经到了封顶阶段，这个时候要求从原来一层改成两层，这不仅仅是说再加盖一层那么简单，为了保证牢固性，从地基以及房屋结构等等方面都需要发生改变。

既然需求变更如此令人生厌，那可不可以不允许需求变更呢？如果可以，相信研发兄弟们早就这么干了，又何必为此头疼呢？闭门造出来的轮子可能还没上路跑就已经被市场淘汰了。

大家都知道敏捷开发提倡拥抱变化，那是不是就可以随意更改需求了？不是的，应对需求变更敏捷开发有一套自己的办法，下面就对敏捷开发中如何处理需求变更进行解析。

拥抱变化的正确解读

在软件开发过程中有一条真理：需求的变化是永恒的，需求不可能是完备的。软件开发过程实际上就是一个不断应对变化的过程。敏捷开发提倡拥抱变化，但是有些对敏捷开发有误解的人会认为：拥抱变化就是可以随意变更需求。其实不然，在敏捷开发中有两个工件：Product Backlog（产品代办列表）和 Sprint Backlog（迭代代办列表），这里说的变化是指 Product Backlog 是一个不断变化的需求池，由 PO 负责管理完善，在整个开发过程中，PO 都可以对 Product Backlog 中的需求进行修改和完善，根据情况调整优先级，增添必要需求，删除无价值需求。而 Sprint Backlog 是迭代计划会议上的产物，是当前迭代需要完成的产品需求，是从 Product Backlog 中通过优先级、重要性等筛选出来的子集。在迭代计划会议上 PO 需要向开发团队承诺在迭代进行中到结束都不会更改 Sprint Backlog 中的需求。

敏捷开发需求管理遵循的原则

1. 精确的需求优先开发，模糊的需求延后开发

软件的需求具有模糊性、不确定性、变化性和主观性的特点，在项目初期客户可能只知道大概想要一个什么样的软件，大部分的需求都不是清晰的，这个时候让客户把所有需求细节都表述明白，也着实是难为人了。那么此时应该做的是将已经明确的需求落入到前期的迭代中，而随着项目开发的进行，客户想要一个什么样的软件的想法也会越来越清晰，再把需求细节进行补充，根据需求的精确程度调整优先级，把之前只是一个想法，后来发现并没有什么价值的需求剔除。这样就一定程度上避免了开发中的需求发生变更。

2. 开发中的需求，原则上不允许变更

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

3. 必须变更的需求需经过评估确认

当然，理论是比较理想的状态，进入现实，完全拒绝需求变更是不现实的，还是会有出现需要修改迭代中需求的情况，那该怎么处理呢？

在敏捷开发中遇到需求变更，不是直接的接受或者拒绝，需要遵循“NO CHANGE”原则，先对需求进行分析，在根据分析结果做相应的处理：

无价值需求

通过与 PO 沟通分析后，对于无价值需求果断拒绝。

优先级高，影响小的需求

对于优先级比较高的，对迭代影响小的需求变更，可以接纳，但要工作量评估，做等价交换，就是把未做的优先级低的需求从迭代替换出来，移动到 Product Backlog 中。

优先级高，影响很大的需求

对于高优先级的，对迭代影响很大的需求变更，需要停止当前迭代，重新规划新的迭代。“影响很大”是指当前迭代中的需求继续做下去也没有价值，这时应该停止当前迭代。这种情况影响较大需要全体成员（包括客户方）共同商定，并接受由此带来的影响和成本提升。为避免或减少这种情况的出现，日常工作中 PO 应该至少整理好接下来 1-3 个迭代需要做的 Product Backlog，然后按优先级，挑选出最近一个迭代需要开发的需求，形成 Sprint Backlog。

该不该进行项目细节展示？

敏捷开发的三个支柱：透明、检视和适应，其中透明指的是：“涌现的过程和工作必须对执行工作的人员和接受工作的人员都是可见的”，对于这一点有的人会存在这样的疑虑：给客户（接受工作的人）展示项目的细节越多，客户的问题和需求就会越多，到底应该不应该给客户展示项目的全貌呢？

不给客户展示项目细节只是一种逃避的做法，要知道展示或不展示，需求就在那里，只是早与晚的区别。早在 1980 年代，Barry Boehm 发布的一些统计数据（软件工程经济学，1981 年）就表明，随着时间的推移，进行软件更改或修复的成本会显着增加。所以最好的办法就是要求客户共同参与，及时发现问题，及时修正，他们也能了解你的初衷和困难，更容易达成共识，才能保证交付的产品满足客户的要求。