Scrum 项目中的需求变更管理

Posted 2021-04-25 博克软件

摘要

在软件行业做Scrum项目管理现在已经是一个流行的趋势，敏捷方法能帮我们解决很多过去传统开发方式的问题，比如反馈慢，需求蔓延等。变更管理是项目管理中很重要的一个实践，一般公司也都有变更管理流程。但实际项目中，往往会碰到各种问题，导致变更管理形同虚设。特别是需求变更，有时会决定一个项目的成败。在Scrum开发中，介绍如何有效结合变更管理，控制住需求变更，是本文的主要目的。

都Scrum 方式开发了，为什么还要做需求变更管理？

这个问题是在工作中和客户讨论时碰到的，客户觉得敏捷开发/Scrum项目管理能随时变更，为什么还需要像传统开发方式那样进行变更管理？简单的说，Scrum和变更管理没有矛盾；全面的说，变更管理是项目管理中必不可少的一个项目实践，在Scrum 开发中，变更管理变得简单，更容易控制。下面的内容会详细介绍变更管理和如何在Scrum 开发中做需求变更管理。

变更管理是每个项目中不可缺少的一个项目实践

首先，变化才是永远不变的主题，在项目管理中，变更时常发生。任何项目中的变化，都可能是变更。用户需求变了需要调整计划或者设计；测试发现了问题需要对错误代码进行变更；甚至人员流失了，也需要项目进行一定的调整以适应这种情况。Bug管理，需求管理，风险控制等本质上都是项目变更的一种。

既然变更是无法避免的，变更管理也是不可缺少的。PMP 的项目管理体系中，有五大过程组：启动过程组，规划过程组，执行过程组，监控过程组，收尾过程组。变更管理就属于“监控过程组”的一个过程，下面是“实施整体变更控制”过程的流程图：

实际项目中的情况

理论上每个公司在项目管理上都会建立变更流程，看起来都很完美，但真正执行过程中，变更管理往往形同虚设。拿需求变更为例，从有交付物给客户开始，客户就会感觉与当初设想有差异，需求变更就多起来了。

需求变更大致分三类：

1.  外部原因导致的变更，比如政策变化，接口增加。

2.  需求灰色区域，随着开发的进行，对工作范围会越来越明确，之前灰色的区域逐渐清晰。

3.  客户测试时的一些反馈，这些变更有时候很小，但数量众多。

第一类的变更相对较大，第二类次之，第三类比较小。一般情况下，大一些的变更比较容易控制，大家也愿意走变更流程来管理。问题常常是出现在小的需求变更上，因为时间的压力，客户提出的小的需求变化，就懒得走流程，找开发直接改了再说。慢慢的变更流程就变得松懈，特别是进度压力大的时候，执行变更流程就更困难，逐渐变更流程就形同虚设了。

PMP中的变更控制流程很多地方都有，就不在这里赘述了，下面介绍一下Scrum开发中的需求变更流程。

如何在Scrum 开发中做需求变更管理

Scrum是敏捷开发中最流行的一个开发框架，应用Scrum 框架能让变更管理更为简便实用。

在开发过程中，每天都会产生未审批的变更，这个变更可能需求细化过程中出现的，也可能是客户因为各种原因增加的。一般变更管理需要符合“申请->评估->审批->执行”流程，Scrum中的变更管理还有几个原则：

1.  不建议在当前迭代加入已审批的变更。

2.  如变更必须马上执行，需要停止当前迭代，重新开始新的迭代来执行变更。

3.  Product Owner 负责变更审批。

4.  审批通过的变更会加入到产品 Backlog，和其它需求进行按优先级排序。

Scrum是按照迭代为周期进行开发，变更只能在迭代开始时加入到迭代backlog 中，这样既能保证迭代工作内容的稳定性，又能保证变更能尽早执行。因为至少有一个迭代的缓冲期，所以也不会出现前面提到的需求变更流程形同虚设的情况。

结束语

变更管理是项目管理中一个必不可少的实践， 采用Scrum开发框架，可以兼顾开发效率和变更的紧急性。再看文初的问题，“都Scrum 方式开发了，为什么还要做需求变更管理？”，是不是心中已经有了答案。

如需转载，请注明出处