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

　　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变更长度等工具跟踪变更，可帮助从根本上消除流程中的浪费，还可能让产品经理更加高效。当然也有其他一些原因和方法来跟踪变更，但是关键点是让流程保持精益，并尽可能提供一些有用的详细信息。