在 Scrum 中管理变更需求

变更控制是用于变更管理的一个传统项目管理流程。在传统的项目中，变更控制主要表现为填写一个详细的变更需求表，表中包含了像变更细节、对项目的影响、风险、缓解计划等条目。它还需要多人批准。传统的变更控制和敏捷相违背，因为它和“响应变化胜过遵循变化”的原则相冲突。在大量的表要填和大量的需求要确认的情况下，响应变更是困难的。精益敏捷Scrum 群组发起了一个有趣的讨论，群组成员就Scrum 中对变更控制的需求、变更可被跟踪的可能方法等展开了讨论。

为什么团队需要跟踪变更？

Ashish Pathak 提到说，其原因之一是阻止产品经理在产品 Backlog 中添加不必要的信息。反过来，它也反应了产品经理的效率。讨论组同意说有时候，Backlog 中的条目没有被深入思考，所以需要经常进行变更。 Mary Poppendieck 建议说，原则上，阻止往 Backlog 中添加变更听起来像一个流程味道（process smell）。但是，她也认为产品 Backlog 中变更的长度不应该太长：

任何一个 Backlog 的目标都是：它应该足够短、级别足够高，无特殊情况不需要修改。如果 Backlog 改变了，那么我认为你应该假设你的 Backlog 错了，而不是需求变更了。变更需求通常意味着 Backlog 太长或者太详细，无从下手；或者说需要花费太多的时间猜测它究竟讲的是什么。

她还提到以下内容：

如果你测量了变更长度（Churn，从 Backlog 条目中的变更创建开始到产品交付使用结束），我认为超过变更长度 10-15% 的话，那不是什么问题。但是如果超过了 50-200%，那么这说明有些人正在浪费大量时间在 Backlog 中添加需要变更的信息，他们不清楚什么需要做和什么不需要做。变更长度太长通常传递了一个信号：Backlog 被用来阻止变更和使组织免受不确定之“苦”，而不是创建一个流程来很好地响应已经发生的事件并允许组织处理这些不确定的事情。

讨论组一致认为，基于 Backlog 变更长度作分析会有益于产品经理调整 Backlog，以包含相关的条目。讨论还说明了跟踪变化在很多场景中都是有帮助的，包括什么时候需要跟踪和变更相关的以往决定，以及什么时候跟踪已调整的需求。

那么，团队如何跟踪变更？

组里的大多数人同意说变更应该被加到 Backlog 里。 Brian Bozzuto 建议说，Backlog 条目应该有个属性来标明故事的起始点。该属性的值可以为开始、新的和变更等。

无独有偶， Erik Landes 也建议说应该使用一个基于方法（Approach）的精益看板来管理变更需求。Chris Woodill 建议采用一个通用的方法来实现敏捷变更控制流程。根据他的说法，主要的考虑应该是让流程保持轻量级，并尽可能消除浪费。

他的主要观点如下：

• 将变更记录到 Backlog 表或者变更跟踪器
• 尽可能消除确认（Approval）
• 必要情况下，使用一个简单的变更控制表
• 加入利益相干方和相关操作

这样，在特定的情况下，也许有必要跟踪变更。使用如产品 Backlog 变更长度等工具跟踪变更，可帮助从根本上消除流程中的浪费，还可能让产品经理更加高效。当然也有其他一些原因和方法来跟踪变更，但是关键点是让流程保持精益，并尽可能提供一些有用的详细信息。

查看英文原文： Managing Change Requests in Scrum