軟件開發過程中的變更請求管理

1. 變更請求管理(Change Request Management: CRM)
變更請求
變更伴隨着軟件開發的各個階段。軟件開發過程中的變更可以從兩個側面來描述,一個是對軟件開發過程之中工件(如:需求設計文檔、設計模型、代碼及測試腳本等)的變更;另一方面是驅動工件變更的理由(如:缺陷修正、新功能添加等等)。這種驅動軟件工件變更的理由就是變更請求。

 

變更請求管理(CRM)的必要性
伴隨着現代化社會的高速發展,對軟件開發的要求也越來越高,變更量之多、變更頻率之快,使開發人員必須在相當的壓力之下,迅速解決問題。另一方面,隨着開發規模的不斷擴大,加入開發的人數也在不斷增加,處理錯誤的成本也相應成指數級增加。在這種狀況下,是否能高效地跟蹤併合理地管理變更請求對軟件開發的成功與否,就起到了舉足輕重的作用。所以,爲了保證整個項目開發的成功,在項目管理方面必須克服如下挑戰:

 

難以有效地管理和追蹤變更請求
變更請求是指在軟件開發生命週期內產生的所有需要改動項目相關內容的請求,如:缺陷、功能增強、需求變更等。它是推動項目向前發展的源動力,同時也是項目重要的過程資產。所以,能否有效地管理和追蹤變更請求成爲項目成功的關鍵要素之一。正是因爲如此,目前有很多研發企業都已建立了自己的變更管理流程,但多數企業都是以書面變更單的形式來記錄和管理變更請求,但此種方式很難對變更請求的發展狀態進行追蹤,導致變更管理流程難以貫徹實施,同時也很難對變更請求進行統計分析。

 

缺少必要的團隊溝通導致工作效率降低
目前大多數項目的研發人員都在幾十人甚至上百人,在如此大規模的項目中溝通成了一個至關重要的問題。例如某個開發人員對自己模塊的接口進行改動後沒有及時通知相關的開發人員,導致集成困難。又如某個核心模塊的缺陷被修改後沒有通知整個團隊,導致開發團隊多次修改同一個缺陷。諸如此類的溝通問題如果不能很好的解決將會導致團隊效率的降低。

 

難以及時準確地瞭解項目狀態和發展趨勢
在軟件開發生命週期中變更請求可以被視爲項目的活動或任務,所以變更請求的信息和統計數據可以直接反映項目的狀態和發展趨勢,但由於我們多以書面變更單的形式來記錄和管理變更請求,導致難以查詢變更請求的狀態或對現有變更請求進行統計分析,所以,項目經理通常是通過會議、電話或郵件的方式去了解項目狀態,但這種方式不但耗時且很難及時準確地瞭解項目狀態和發展趨勢,致使項目經理對項目做出錯誤的判斷或決策。

 

難以進行量化的項目管理
變更請求是項目管理的重要數據之一,通過對這些數據的統計分析可以進行量化的項目管理。例如我們可以統計項目組每個成員的任務分配情況;統計目前還有多少未被響應的變更請求;統計缺陷的平均修復時間;統計在一段時間範圍內變更請求數量的變化等等!以上這些統計數據都是項目經理迫切需要的,但如果在項目規模較大的情況下,僅以手工的方式對變更單進行管理,根本無法對其進行統計分析。

 

難以將項目活動與配置管理對象的變更相關聯
項目活動的主要來源是變更請求,項目活動的最終結果是配置管理對象的變更(即文檔或代碼的修改)。通過傳統的項目管理方式很難將項目活動與配置管理對象的變更相關聯。從而使得開發人員不清楚自己對代碼所作的修改是和那些任務相關,導致在集成時代碼提交錯誤;同樣集成人員和項目經理很難確定某一個特定的變更請求到底和那些代碼的修改相關,導致集成過程出現的問題難以定位,以上這些問題都會直接導致集成時間的拖延。

 

由此可見,如果沒有變更管理,重要的變更就會被遺漏,項目的監視、檢查能力就會喪失,項目管理人員及開發人員不能掌握工作重點及輕重緩急,測試及文檔的編寫均不能反映項目開發的實際狀況。直接後果表現爲:由於交貨期推遲而造成的開發成本增加、生產率低下、產品質量低下。
變更請求管理是軟件開發的成本降低的最大因素之一。再優秀的軟件開發團隊也不能保證從一開始就100%地正確開發。在開發系統生命週期中,變更是永遠不可避免的。部署高效的CRM 系統,通過對項目開發整個生命週期中的變更請求進行管理及各種數據查詢,可以使問題的解決時間大幅度降低,從而有效地降低開發成本。

 

 

如何有效地組織和管理變更請求

 

成立變更管理委員會
變更請求管理決不是向大家所想象的僅僅是單一的跟蹤,變更請求管理所強調的是對開發過程中成百上千的變更請求進行慎重的信息管理,“慎重”包含的是跟蹤、分析、決策的完整過程。這種“慎重”的處理過程必須由一個變更管理委員會(CCB)進行控制和管理,CCB 應該由開發團隊中富有分析、決策能力的角色構成,CCB 的主要職責是對遞交進來的所有變更請求進行審查、分析,從而決定如何處理這些變更請求。

 

制定合理的變更流程
如前所述,變更管理的關鍵目的是通過建立合理的變更流程,來改進產品的質量和服務。而變更管理流程執行的有效性取決於團隊之間的密切配合。單一的工具並不能保證變更請求管理的成功。以下是變更請求管理流程實施的基本步驟:
1 確定變更請求管理流程執行的範圍:你可以從一個項目、一個部門或多個組開始實施。但在制定變更管理流程前,你必須確定好實施範圍,然後制定響應的變更流程;
2 制定變更管理流程模型:這是整個變更管理流程的核心部分。你必須與團隊人員合作,編制、審查和修改此模型,直到團隊每一個人都能認可此流程;
3 決定團隊各個角色在流程實施中所起的作用:通常情況下,在團隊中有變更請求提交者、
CCB、請求解決方案實施者、測試人員及QA 等;
4 確定實施計劃及開始實施日程:實施過程可以分階段完成,但要注意跟蹤各個階段完成的質量,保證變更請求相關者對各個階段完成的認可;
5 部署變更請求管理系統:在完成了上述步驟後,你已具備了實施變更請求管理的條件;
6 不斷強化變更管理流程:變更管理流程不是一成不變,它需要團隊發展的不斷變化及時作相應的調整,不斷地被改進和強化。
開發項目有關人員都有權利提交變更請求。如開發人員在編碼過程中,會覺得某部分設計不合理,提出更改設計的請求,這種請求如不得到跟蹤管理,我們就不能清晰地掌握產品是否真正滿足了最終用戶需求。所以,完整的變更管理系統,不應該僅僅是對缺陷的管理。它應是通過對缺陷及其各種他變更的登記、保管、跟蹤、解析,達到團隊之間的各種變化信息的共有、安全而可靠的高質量變更信息管理系統。這種信息管理系統通過以下特徵的體現,有效地組織和管理變更請求。
1 應可提供具有各種重要特徵的變更請求信息,且對各種變更請求在處理完畢之前的內容能及時調整、並保證各種請求的信息絕對不能丟失。
2 有效地跟蹤各種變更,對管理人員提出各種變更狀況的查詢請求,做到快而準地提供信息。
3 有能力對項目整體發展狀況,提供宏觀及定量的分析,從而能合理分配項目開發人員的工作、合理制定項目的計劃、合理管理項目各種請求實施的優先級。
有效的CRM 系統,應具備從簡單地列出問題清單對缺陷進行跟蹤,到對項目開發的各種可能的變更流程進行定義、以及各種變更請求在適當時機採用適當方法進行訪問等靈活多樣的選擇性,以適應開發過程中的各種變化。也就是說,有效的CRM 系統應具備良好的系統適應性、擴展性及靈活定製性。

 

 

典型的變更管理流程

2. 完整的變更請求管理解決方案:IBM Rational ClearQuest
概要
IBM Rational ClearQuest 是強有力的且靈活性很強的CRM 系統。通過對開發整個生命週期中發生的各種類型變更請求的跟蹤及管理,保證各種規模的開發團隊按照預定計劃按期交出高質量的軟件產品。
IBM Rational ClearQuest 是一個具有定製性高、跨越多種數據空間的CRM 系統。適用於在任何平臺上,任何類型的項目中,捕獲各種類型的變更。ClearQuest 使用行業標準數據庫(Microsoft Access SQLAnywhere SQL Server DB2Oracle),因此支持的項目可大可小;並擁有可完全定製的界面和工作流程機制,能適用於任何開發過程。此外,通過提供各種各樣的流程模,對於一般的開發環境和流程,可以做到“拿來就用”或“稍做修整,即可使用”的方便而靈活的部署。
ClearQuest IBM Rational 的其他解決問題方案(如配置管理工具、自動測試管理工具、需求管理工具)的集成,使團隊開發的各個角色在開發的各個階段都可以隨時遞交變更請求,成爲支持軟件開發整個生命週期的變更管理的有效工具。

 

ClearQuest 的特點

有效的記錄、管理和追蹤變更請求
ClearQuest 通過多種易於使用的客戶端(WindowsUNIXWebEmail),讓您在任何地點、以任何方式都可以捕獲在整個開發生命週期中出現的各種類型的變更請求,包括測試階段發現的缺陷、需求分析階段的需求擴展請求等等。所有的變更請求在ClearQuest 中被集中存儲在統一的數據庫之中,以便進行各種形式的查詢,同時也便於集中管理。另外,ClearQuest 給變更請求還附加了狀態信息,以便於追蹤變更請求的發展狀態。
促進團隊的溝通和協作
ClearQuest 提供一套完備的電子流管理系統。它可以利用企業現有的郵件服務系統實現自動電子郵件通知功能。當系統內提交了新的變更請求或已有變更請求的狀態發生變化時,ClearQuest 會自動通過電子郵件通知相關的人員,從而大大促進團隊的溝通和協作。
隨時隨地瞭解項目狀況
ClearQuest 支持通過WEB 的方式對系統進行訪問,在瀏覽器中可以查詢變更請求的狀態、瀏覽變更請求的信息、生成多種統計分析圖表和項目狀態報告。所以,項目經理無論是在公司還是在外地出差都可以及時準確的瞭解項目的狀況。
靈活、客觀的項目統計指標
ClearQuest 的查詢、圖表(年齡、趨勢、分佈圖表)、報告(與SoDA 集成)功能,使得項目管理人員能夠方便、準確地得到項目統計指標數據,如:
“變更請求是否在團隊成員中被合理分配?
“還有多少優先級爲1 的缺陷未得到處理?
“平均修復一個錯誤需要多長時間?”,“實現一個擴展請求需要花多少時間?
“在兩個月內變更請求數量的變化曲線”
依賴各種項目統計指標數據,項目管理人員就可以進行更加科學、量化的管理、規劃、調配、監控,保證項目如期的進行。
系統可定製能力強
ClearQuest 系統中所涉及的表單信息域、狀態變遷過程、分析圖表和狀態報告等都是可以根據企業的實際需要進行定製的,並且可以隨項目的發展不斷進行調整。所以,ClearQuest 可以適用於任何類型以及任何規模的項目。對於一個立足長遠發展的企業而言,ClearQuest 是一筆可以長期保值的投入。
可以有效地控制各種變更請求之間關係在ClearQuest 可以建立各種變更之間的關係,這種變更的關係實際上是雙向的,這種關係的管理,體現在以下幾個方面:
1 變更請求的包括關係,通過建立多數“子”請求與“父”請求的關係,控制全部“子”請求沒有到closed 狀態,“父”請求不能close
2 不同變更請求之間的連接關係, 通過建立定義不同的變更請求類型,建立數據的參照關係(record reference),實現數據共享。比如:在缺陷變更請求中調用用戶信息時,可以另建立用戶變更信息數據庫,通過建立與缺陷變更請求關聯,便可得到實現。
通過與ClearCase 的集成可以實現項目活動和配置管理對象的統一ClearQuest 可以和配置管理工具ClearCase 集成,從而將變更請求和配置管理對象有機的聯繫到一起。主要的集成方式有以下兩種:
1 ClearQuest Base ClearCase 集成
集成是通過將ClearCase 的版本對象庫(VOB)與ClearQuest 的數據庫相關聯來實現的,集成後開發人員在修改代碼(Check Out)時會自動彈出ClearQuest 的變更請求列表,並強制開發人員將此次修改與特定的變更請求相關聯。這樣一來,開發人員在代碼提交時可以清楚的知道哪些修改過的代碼是對應哪些任務的,集成人員可以準確的瞭解到某次建立到底集成進來哪些變更請求。項目經理可以輕鬆的定位變更請求和哪些改動相關。
2 ClearQuest UCM ClearCase 集成
此種集成方式與上一種集成方式從實現機制上沒有本質的區別,但從功能上二者的集成更加緊密,且很多功能更加自動化。如開發人員在提交代碼時系統會自動檢測出此次需要提交的變更請求,待開發人員確認後系統會自動對代碼進行歸併。總而言之,UCM 對於開發人員來講使用非常簡便且不要出錯,對於集成人員來講,由於UCM 採用組建式管理,使得系統架構更加清晰,集成工作更加快捷。對於項目經理來講UCM 爲團隊提供了一套完整且高效的變更管理流程。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章