變更控制是用于變更管理的一個傳統(tǒng)項目管理流程。在傳統(tǒng)的項目中，變更控制主要表現(xiàn)為填寫一個詳細(xì)的變更需求表，表中包含了像變更細(xì)節(jié)、對項目的影響、風(fēng)險、緩解計劃等條目。它還需要多人批準(zhǔn)。傳統(tǒng)的變更控制和敏捷相違背，因為它和“響應(yīng)變化勝過遵循變化”的原則相沖突。在大量的表要填和大量的需求要確認(rèn)的情況下，響應(yīng)變更是困難的。精益敏捷Scrum群組發(fā)起了一個有趣的討論，群組成員就Scrum中對變更控制的需求、變更可被跟蹤的可能方法等展開了討論。
　　為什么團隊需要跟蹤變更？
　　Ashish Pathak提到說，其原因之一是阻止產(chǎn)品經(jīng)理在產(chǎn)品Backlog中添加不必要的信息。反過來，它也反應(yīng)了產(chǎn)品經(jīng)理的效率。討論組同意說有時候，Backlog中的條目沒有被深入思考，所以需要經(jīng)常進(jìn)行變更。Mary Poppendieck建議說，原則上，阻止往Backlog中添加變更聽起來像一個流程味道（process smell）。但是，她也認(rèn)為產(chǎn)品Backlog中變更的長度不應(yīng)該太長：
　　任何一個Backlog的目標(biāo)都是：它應(yīng)該足夠短、級別足夠高，無特殊情況不需要修改。如果Backlog改變了，那么我認(rèn)為你應(yīng)該假設(shè)你的Backlog錯了，而不是需求變更了。變更需求通常意味著Backlog太長或者太詳細(xì)，無從下手；或者說需要花費太多的時間猜測它究竟講的是什么。
　　她還提到以下內(nèi)容：
　　如果你測量了變更長度（Churn，從Backlog條目中的變更創(chuàng)建開始到產(chǎn)品交付使用結(jié)束），我認(rèn)為超過變更長度10-15%的話，那不是什么問題。但是如果超過了50-200%，那么這說明有些人正在浪費大量時間在Backlog中添加需要變更的信息，他們不清楚什么需要做和什么不需要做。變更長度太長通常傳遞了一個信號：Backlog被用來阻止變更和使組織免受不確定之“苦”，而不是創(chuàng)建一個流程來很好地響應(yīng)已經(jīng)發(fā)生的事件并允許組織處理這些不確定的事情。
　　討論組一致認(rèn)為，基于Backlog變更長度作分析會有益于產(chǎn)品經(jīng)理調(diào)整Backlog，以包含相關(guān)的條目。討論還說明了跟蹤變化在很多場景中都是有幫助的，包括什么時候需要跟蹤和變更相關(guān)的以往決定，以及什么時候跟蹤已調(diào)整的需求。
　　那么，團隊如何跟蹤變更？
　　組里的大多數(shù)人同意說變更應(yīng)該被加到Backlog里。Brian Bozzuto建議說，Backlog條目應(yīng)該有個屬性來標(biāo)明故事的起始點。該屬性的值可以為開始、新的和變更等。
　　無獨有偶，Erik Landes也建議說應(yīng)該使用一個基于方法（Approach）的精益看板來管理變更需求。Chris Woodill建議采用一個通用的方法來實現(xiàn)敏捷變更控制流程。根據(jù)他的說法，主要的考慮應(yīng)該是讓流程保持輕量級，并盡可能消除浪費。
　　他的主要觀點如下：
　　將變更記錄到Backlog表或者變更跟蹤器
　　盡可能消除確認(rèn)（Approval）
　　必要情況下，使用一個簡單的變更控制表
　　加入利益相干方和相關(guān)操作
　　這樣，在特定的情況下，也許有必要跟蹤變更。使用如產(chǎn)品Backlog變更長度等工具跟蹤變更，可幫助從根本上消除流程中的浪費，還可能讓產(chǎn)品經(jīng)理更加高效。當(dāng)然也有其他一些原因和方法來跟蹤變更，但是關(guān)鍵點是讓流程保持精益，并盡可能提供一些有用的詳細(xì)信息。

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://www.vanceur.cn/pmqhd/index.html