田海立

2012-9-14

軟件工程絕不僅僅是書面的理論的學科，是實踐性很強的。軟件工程源自于西方管理科學理論與知識，并在很多西方的公司得到實踐。筆者有十余年的工作經歷，服務 過全球領先的巨頭公司，也服務過占絕大多數的國內公司。軟件工程出身，看到學校里學習的理論知識在西方公司確實能實際執行，且效果良好；而國內很多公司做 事幾乎還是毫無章法，并且狀況還將一直持續。改變這個狀況是一個系統過程，而我輩所能做的是從點滴做起，逐步改善。

本文從RUP(RationalUnified Process)推薦的變更管理出發，看實際工作中如何定制適合自己團隊與項目的變更管理策略與工作機制。

一、RUP中的變更請求（Change Request / CR）管理

下面兩個圖是RUP中實例中的變更管理的活動圖（圖一）與CR的狀態圖（圖二）。

圖一、RUP中的變更管理活動示例

圖二、RUP中的變更請求的狀態圖

這兩個圖描述的信息很明確，這里不做闡述。

二、變更管理實戰

下面體現了RUP中變更管理的精髓。但是恰恰很多組織在實際定制時給定制掉或削弱了。

1) 所有涉眾都可提交變更請求（CR）

所有項目相關的人員應該都能提交CR。因為項目中的任何人員都可能會對項目有自己的看法，這應該有出口，把這個想法提交CR，而CR可以是新的需求也可以是BUG。新的CR也不一定需要在當前迭代周期中去實現，需要經過CCB審核決定。

如果CR的提交者不是測試人員，在CR的后續跟蹤過程中，需要測試經理指定測試人員來Verify。

所有項目相關的人員都提交CR，不應停留在允許，而應該建立機制來鼓勵這種行為。

在實際執行過程中，往往會有其他非測試人員提交CR的行為不被重視與執行，到后來就會發現除了測試人員提交CR，其他人不再提交，這樣可能漏過了很多好的想法，改進項目的機會。

2) CCB及CCB復審會議

RUP中有CCB (Change Control Board) 變更控制委員會。該委員會監督變更流程，由所有利益方包括客戶、開發人員和用戶的代表組成。在小型項目中，項目經理或軟件構架設計師一人即可擔當此角色。

CCB 復審會議 - 此會議的作用是復審已提交的 變更請求。在該會議中將對變更請求的內容進行初始復審，以確定它是否為有效請求。如果是，則基于小組所確定的優先級、時間表、資源、努力程度、風險、嚴重 性以及其他任何相關的標準，判定該變更是在當前發布版的范圍之內還是范圍之外。此會議一般每周開一次。如果變更請求量顯著增加或者發布周期臨近結束時，該 會議可能每天開一次。CCB 復審會議的成員一般是測試經理、開發經理和營銷部門的一名成員。將根據“需要”適當增加與會者。

CCB及CCB復審會議著重的幾點：

•  所有與會方特別是實現階段的開發與測試人員進行交流，對CR討論，能讓他們對項目/產品的定義、風格以及項目進度做進一步的溝通，使目標更一致。今后所提交的CR更有針對性，質量更高。
•  CR后續的狀態變化是與會方討論的結果，CR的分配不容易出現相同的問題分配給不同的人員；或者很多無效的或產品定義不明確的CR指定給開發人員，而他們又是無法做出決定的，再反過來assign給其他人這樣反復的周轉。這些問題在CCB這里分配之前就已經得到解決。
•  CR所提的粒度經過CCB復審會議后會比較一致。在項目不同階段，所提的粒度是不一致的。比如，剛項目的起始階段，實現還不完整，粒度就很粗；到了項目后期，問題可能提交的就很細。這做不到完全一致，但是經過不斷溝通交流，某個階段不同人提交CR的粒度會趨于一致。
•  無論什么樣的CR，都被同樣被復審，以確認變更是否有效，并評估優先級、時間表、資源、風險和嚴重性。
•  一次會議可能不是處理完所有的CR（包括新提交的CR/補充更新過信息的CR/本迭代周期要考慮的上周期中Postponed的CR）。所以會議之前CCB可委托一個代表要這些CR大致基于優先級或者嚴重等級做一個列表，按照這樣的次序來處理這些CR。

這是很多組織沒有做到的，會經常遇到：

•  不同現象所描述的相同的問題被不斷的提交或者被不同的人反復提交；
•  新 提交的CR直接分配給了開發人員。開發人員理解認知不同，對不明確或者根本不需要做變更的CR，對項目整體有Sense的人會reassign給相關人做 決策，而有些人會不管三七二十一直接做變更。并且一般是根據現象判斷在那個模塊而assign給了相應的模塊，但其原因可能是相同的。這樣就不可避免的出 現，不同人在做同一個變更而他們彼此卻不知道。

這無關乎個人的理解和知識認知水平，作為一個組織需要用制度和機制策略來保證。

CR是作為人員考評的重要依據。如果機制有問題，對人的評價體系建立在不客觀的數據基礎上，顯而易見對團隊人員的工作積極性和士氣就會是個打擊。

3) 重復的（Duplicate）/拒絕（Rejected）的CR的處理

CCB 認定重復的/拒絕的CR應該有機會讓提交者補充信息。CCB認定重復的/拒絕的CR也不一定就是無效的，這要提交者來確認，可能是提交的信息不明確而被錯 認為是重復的/拒絕的。提交者更新CR之后，該CR還會被CCB復審，確定是否有效，并評估優先級、時間表、資源、風險和嚴重性。。

被提交者確認重復的/拒絕的CR才可以被關閉。

4) 推遲（Postponed）的CR的處理

所謂的推遲的CR是指CR是有效的而只是當前迭代版本中不做變更。所以，到下一個迭代周期開始時，上一周期被認為推遲的CR會與新提交的CR以及更新過的CR一起被CCB復審，確定是否有效，并評估優先級、時間表、資源、風險和嚴重性。

5) 已解決（Resolved）與已驗證（Verified）的CR

RUP中有測試版本和正式發布版本兩個版本，所以針對CR有兩個狀態Resolved和Verified。

在對Artifacts（不僅限于代碼，還可能是需求、分析設計、實施、制作用戶支持材料、設計測試等）進行所請求的變更，并被經過Review和單元測試活動之后，CR被確認并標識為Resolved。

在測試版本中，如果已經包含了Resolved的CR，該CR會在該測試版本中被驗證，驗證通過將該CR標識為Verified，并可以正式發布了。

Verified的CR在發布版本中得到確認才可以關閉（Close）。

根據組織的規模和版本發布的頻率以及對發布版本質量的要求，不一定所有組織都會有兩個版本發布。不過這樣確實能對發布出去版本的質量做進一步確認，在制定變更管理策略時，根據需要來定制。

不過不管最后定制的結果如何，最好要有類似上面的兩個圖，并在組織內部被充分理解并執行！

三、工具的選擇與定制

變更管理關鍵的是理念并定制適合自己組織和項目的策略，工具不是最重要的，但是好的適用的工具的選取卻是提升效率和增進交流的利器。現在很多免費或商業的變更管理工具中都可以定制做到，只要基本滿足下列要求：

用戶管理

    變更管理工具應該能基于角色配置對用戶進行用戶管理，這是基本的需求，一般工具都能滿足。

CR的狀態和相應的轉換可定制

    一般工具里都可根據定制增加或改變CR的狀態；

    并且從某一個狀態到另一個狀態轉換過程的路徑就那么幾條，要根據轉換圖給出可能的下一狀態的選擇；

    最好CR的狀態轉換之后，根據轉換到的新狀態能自動更改相應的Owner。

Email通知

    變更管理工具應該具有基本的Email通知機制。在CR做任何改變時，都能及時通過Email通知該CR感興趣的相關人。感興趣的相關人的郵件列表應該可以手動新增加。

報表

    方便功能強大的報表功能對項目CR跟蹤和數據分析至關重要。

與配置管理結合

    變更管理工具如果能與配置管理工具無縫結合是最佳的組合。Rational的ClearCase與ClearRequest分別是配置管理工具和變更管理 工具，它們能很好的無縫結合，不過做為商業軟件，價格也是很很多公司不能接受的。不過這也不是必須的，在變更管理工具里如果能增加一個字段指向配置工具里 變更的信息也可以了。

分布式Web訪問

    這點雖然不是絕對要求的。但是如果你所在的公司有多個辦公地點，或者需要在家辦公之類的需求的話，這點就是必須的了。