Scrum中的变更控制

Posted 2021-04-25 漫话项目管理

        作为敏捷软件开发的当家花旦，Scrum开发方式的诞生，很大程度上是为了响应快速变化，包括但不限于需求变化、人员变化、进度变化、预算变化、环境因素变化等。也正是因为在应对变化方面的出色表现，Scrum开发方式被越来越多的软件开发人员所接受。

        尤其是在互联网领域，Scrum几乎成为标配。不知道用户故事，不懂Burndown Chart，不了解Scrum master的职责，都不好意思和人说自己是互联网码农。

        变更控制是传统项目管理理论中一套完整的流程，在项目的执行过程中占据重要地位。完善的变更控制流程会对变更的请求、评估、批准、实施、验证等环节都做明确定义和规定，保证项目目标的实现。下面是一个典型的变更控制流程图。

        那么，在采用Scrum开发方式的项目执行过程中，为了快速拥抱变化，还需要对变更进行控制吗？很多Scrum从业人员，甚至是具有一定经验的Scrum Master，都认为变更控制与Scrum是格格不入的，既然要求快速拥抱变化了，就没必要在变更控制上花费时间了。甚至有的人搬出了敏捷宣言来替自己打气。来看一下敏捷宣言怎么说的。

        但是很多人没有看到宣言最后的一句话：也就是说，尽管右项有其价值，我们更重视左项的价值。其实宣言从来没有否定过流程、文档、合同和计划，只是在重心上发生了偏移，让我们更重视右边的各项内容。

        试想一下，当客户有一天心血来潮产生了灵感，在原有需求的基础上提了些“小建议”；我们的PO秉着拥抱变化的心态，快速以最高优先级加入了backlog中；我们诚实可靠的程序员们加班加点，费尽心思最终完成了这些临时导入的需求。验收的时候，客户来了一句：“我只是说说而已，你们还当真了，感觉还没有原来的方案看着舒服，改回去应该不难吧”。

        WTF！要是法律不管...

        那变更的正确打开方式是什么样的呢？老谢也不敢说最正确的方式是什么，只是结合Scrum开发方式，给大家一个建议的变更控制流程。

        首先一个需求变更产生了（现实中不一定只有需求变更，这里仅以需求变更为例），Scrum Master被通知到后，应该上报给PO确认是否需要导入该需求。有时候，用户觉得是一个新需求，在PO的product backlog里可能已经包含了。对于有价值的新需求，PO采纳后要决定优先级，必要时候需要和直属领导做讨论并给出决定。这中间PO需要邀请Scrum Master和团队成员对变更请求做评估，包括对Sprint plan、人员安排、项目成本、发布计划等方面的影响。这些评估结果将作为PO做出决定的重要参考因素。最终确定需要执行的新需求，除非异常紧急，原则上不会直接加入当前正在执行中的Sprint，而是在product backlog中等待下次plan meeting时按优先级纳入之后的某个Sprint中执行。这中间的变更申请、评估报告、最终决定、调整后的 product backlog、发布计划等资料都应该存档，以备日后查阅（很多时候是防止有人赖账）。

【评】如何协调Scrum快速拥抱变化的天性，以及变更控制工作的开展，是一个合格的Scrum Master应该思考的问题。如果有项目管理部（PMO）的存在，也应该考虑将两者结合，为项目经理、Scrum Master提供项目执行的规范和标准。