&

軟件開發基本原則（四）—— 風險管理

admin

2012年4月9日 10:39 本文熱度 2752

　　1988年，Peat Marwick針對600家成功公司的調查結果顯示，35%的公司有過軟件項目失控的經歷。（Rothfeder 1988）

　　1982年，Allstate公司宣布其公司運營全部要實行自動化。他們啟動了一個將耗時5年投資800萬美元的大型項目，而在花費了6年和1500萬美元后，Allstate公司重新調整了目標和最終期限，重新調整后的預算大約1億美元。

　　1988年，Westpac Banking公司決定重新設計他們的信息系統。他們做了5年、8500萬美元的計劃。3年后，在花費了1.5億美元卻依然收效甚微時，Westpac Banking公司為了減少損失，取消了這個項目，并為此裁員500人。（Glass 1992）

　　從項目管理的角度來看，有五大硬性知識領域：范圍管理、進度管理、成本管理、質量管理和風險管理。風險會出現在前面四個領域的各個過程中，只有有效地消除可能發生的危險因素，才能確保項目順利推進。項目的風險貫穿于整個項目過程，因此整個項目的生命周期都應該堅持有效的風險管理。

　　根據風險的內容，可以把風險歸為以下幾類：

產品規模風險：與軟件的總體規模相關的風險
商業影響風險：商業風險影響到軟件開發的生存能力
客戶特性風險：與客戶的素質以及開發者和客戶溝通能力相關的風險
過程定義風險：與軟件過程定義相關的風險
開發環境風險：與開發工具的可用性及質量相關的風險
技術風險：技術風險是指在設計、實現、接口、驗證、維護、規約的二義性、技術的不確定性、陳舊的技術等方面存在的風險
人員數目及經驗帶來的風險：與參與工作的軟件工程師的總體技術水平及項目經驗相關的風險

　　軟件項目的風險主要體現在四個方面：需求、技術、成本、進度。風險管理是一個相當重要的話題，但涉及的問題太多，很難在本章中全部囊括，本章主要講述進度相關的風險管理。

風險管理要素

　　軟件風險管理就是在風險成為影響軟件項目成功的威脅之前，識別、處理并消除風險。可以在幾個層次上定位風險管理：

1、危機管理 — 救火模式，即在風險已經造成麻煩后才著手處理它們

2、失敗處理 — 覺察到了風險并迅速做出反應，但只是在風險發生之后

3、風險環節 — 事先制定好風險發生后的補救措施，但不做任何防范措施

4、著力預防 — 將風險識別與風險防范作為軟件項目的一部分加以規劃和執行

5、消滅根源 — 識別和消除可能發生的風險的根源

　　本章描述如何定位第4、5個層面上的進度風險管理。

　　總體來講，風險管理由風險評估和風險控制組成：

圖 5.1-1 風險管理由風險評估和風險控制組成

1. 風險評估

風險識別：建立一個潛在破壞項目進度的風險列表
風險分析：評估每一個風險出現可能性及其影響，判定風險的級別
風險優先級：按風險影響大小排出一個風險優先級列表，這個列表將作為風險控制的基礎

2. 風險控制

風險管理計劃：定制一個應對每個重要風險的方案，同時應確保每一個單獨的風險管理計劃相互之間以及與項目計劃之間保持一致
風險化解：執行每一個重要風險所對應管理計劃
風險監控：對解決風險的過程進行監控。還包括：識別新的風險，并將其加入到正在進行的風險管理進程；在風險列表中移除已經化解的風險等工作

風險識別

1. 最常見的進度計劃風險

功能蔓延
需求鍍金或開發人員鍍金
質量不穩定
計劃過于樂觀
設計欠佳
銀彈綜合癥
研究導向的開發
人員薄弱
承包人導致的失敗
開發人員與客戶之間發生摩擦

2. 進度計劃風險列表

　　下面列出了詳盡的可能對軟件進度有負面影響的潛在風險。除了這里所列出的風險，大多數項目都有其特定的風險，如：

　　“Joe要退出項目組，除非可以允許他帶自己的小狗來上班，而管理層還沒有決定是否同意他這樣做”—— 這樣的風險就要靠自己識別了！

　　潛在的進度計劃風險： （資料來源：Gilb 1988、Boehm 1989 Pressman 1993、Thomsett 1993、Jones 1994）

類型	風險
1、計劃編制	1) 計劃、資源和產品定義全憑客戶或上層領導口頭指令，而且不完全一致 2) 計劃是優化的，是“最佳狀態”（但不現實，只能算是“期望狀態”） 3) 計劃忽略了必要的任務 4) 計劃基于使用特定的小組成員，而那個小組成員其實指望不上 5) 在限定時間內無法建成已定規模大小的產品 6) 產品規模比估計的要打（代碼行數、功能點或與前一產品規模的百分比） 7) 工作量大于估計數（代碼行數、功能點、模塊等） 8) 進度已經拖延的項目在重新評估時過于優化或忽略項目歷史 9) 過度的進度壓力造成生產力下降 10) 目標日期提前，但沒有相應地調整產品范圍或可用資源 11) 一個任務的延時導致相關任務的連鎖反應 12) 涉足不熟識的產品領域，花費在設計和實現上的時間比預期要多
2、組織和管理	1) 項目缺乏一個用凝聚力的最高領導人 2) 由于前期乏力，項目長時間被擱置 3) 解雇和削減開支導致項目小組能力下降 4) 僅由管理層或市場人員進行技術決策，導致計劃進度延長 5) 低效的項目組織結構降低生產率 6) 管理層審查或決策的周期比預期的時間長 7) 預算削減打亂項目計劃 8) 管理層作出了打擊項目組積極性的決定 9) 非技術的第三方的工作比預期延長（預算批準、設備采購、法律審查等） 10) 計劃性太差，無法達到期望的開發速度 11) 項目計劃由于壓力而放棄，導致開發混亂低效 12) 管理層強調英雄主義而忽略客觀確切的狀態報告，錯過發現和改正問題的機會
3、開發環境	1) 設施沒有及時到位 2) 設施到位但不配套 3) 設施擁擠、雜亂或破損 4) 開發工具沒能及時到位 5) 開發工具不如期望的那樣有效 6) 開發工具的選擇不是基于技術需求，不能提供計劃要求的性能 7) 開發人員需要長時間創建工作環境或切換新開發工具 8) 新開發工具的學習周期比預期的長，內容繁多
4、最終用戶	1) 最終用戶堅持新的需求 2) 最終用戶對于最后交付的產品不滿意，要求重新設計或重做 3) 最終用戶不買進項目產品，無法提供后續支持 4) 最終用戶的意見未被采納，造成產品無法滿足最終用戶的期望而必須重做
5、客戶	1) 客戶堅持新的需求 2) 客戶對規則、原型和規格的審核和決策周期比預期的長 3) 客戶沒有或不能參與規劃和原型審查工作，導致需求不穩定和耗時的變更 4) 客戶溝通或答復的時間比預期長 5) 客戶堅持技術決策而導致進度計劃延長 6) 客戶對開發進度管理過細，導致實際進展緩慢 7) 客戶提供的組件無法與開發的產品匹配，導致額外的設計和集成工作 8) 客戶提供的組件質量欠佳，導致額外的設計、測試、集成和客戶關系管理工作 9) 客戶要求的支持工具和環境不兼容、性能差或功能不完善，導致生產率降低 10) 客戶不接受交付的軟件，盡管它滿足合同的條款要求 11) 客戶期望的開發速度無法達到
6、承包商	1) 承包商沒有按承諾交付組件 2) 承包商遞交的組件質量低下無法滿足要求，必須再花時間改進 3) 承包商沒有買進項目開發需要的工具，進而無法提供需要的性能水平
7、需求	1) 需求已經成為項目的基準，但變化仍在繼續 2) 需求定義欠佳，但進一步的定義會擴展項目的范疇 3) 添加額外的需求 4) 需求定義含糊的部分需要的處理時間比預期多
8、產品	1) 錯誤發生率高的模塊需要比預期更多的設計、實現和測試工作 2) 校正質量低下的產品需要比預期更多的設計、實現和測試工作 3) 在一個或多個新興領域推過產品技術使得進度延長或不可預期 4) 由于軟件的功能錯誤使得需要重新設計和實現 5) 開發額外不需要的功能（鍍金）延長了計劃進度 6) 要滿足產品規模的要求，需要比預期長的時間，包括重新計劃、設計和實現 7) 嚴格要求與原有系統兼容，需要進行比預期更多的計劃、設計、實現和測試 8) 要與不受項目組控制的其他系統集成，導致無法預料的設計、實現和測試工作 9) 要求在不同操作系統或軟硬件環境下運行將花費比預期更長的時間 10) 在不熟識或未經檢驗的軟件環境中運行，產生未預料到的問題 11) 在不熟識或未經檢驗的硬件環境中運行，產生未預料到的問題 12) 開發一些全新的功能模塊比預期花費更長時間 13) 依賴未成熟的技術，使得進度延長或不可預期
9、外部環境	1) 產品依賴政府的政策或制度，而政策或制度不可預期 2) 產品依賴草擬中的技術標準，而最后的標準不可預期
10、人員	1) 招聘人員所花時間比預期長 2) 培訓、工作許可證或其他項目的收尾等作為先決條件的任務不能按時完成 3) 開發人員和管理層之間關系不佳導致決策緩慢影響進度 4) 項目組成員沒有全身心投入項目，進而無法達到要求的產品質量水平 5) 缺乏激勵措施，士氣低下，降低生產力 6) 缺乏必要的規范，增加了工作失誤幾率和重復工作 7) 某些人需要更多時間適應新的軟件工具和環境 8) 某些人需要更多時間適應新的硬件工具和環境 9) 項目結束前，成員調離團隊或離職 10) 項目后期加入新開發人員，額外的培訓和溝通降低現有成員的生產率 11) 項目成員不能有效地一起工作 12) 項目組成員間有沖突，導致溝通不暢、設計欠佳、接口錯誤和額外的重復工作 13) 有問題的成員沒有調離項目組，損害了其他成員的積極性 14) 項目的最佳人選沒有加入項目組 15) 項目的最佳人選已加入項目組，但因政治或其它原因未能合理使用 16) 沒有找到項目急需的，具有特殊技能的人 17) 關鍵人物只能兼職參與 18) 項目人員不足 19) 任務的分配與人員技能不匹配 20) 人員工作的進度比預期的慢 21) 項目管理人員怠工導致計劃的進度失效 22) 技術人員怠工導致工作遺漏和質量低下
11、設計和實現	1) 設計過于簡單，無法確定主要事件，并導致重新設計和實現 2) 設計過于復雜，導致一些不必要的工作，影響實現效率 3) 設計質量低下，導致重復設計和實現 4) 使用不熟識的方法和技術，導致額外的培訓時間 5) 使用低級語言開發產品，導致生產率比預期低 6) 一些必要的功能無法使用現有的代碼或庫實現，必須采用新庫或重新實現 7) 代碼和庫質量低下導致需要額外的測試、錯誤修正或重做 8) 過高估計了工具對計劃進度的節省量 9) 獨立開發的模塊無法有效集成，需要重新設計或重做
12、過程	1) 大量的書面工作導致進度比預期慢 2) 進度跟蹤不準確，導致無法預知項目是否已落后于計劃進度 3) 前期的質量保證行為不真實，導致后期重復工作 4) 質量跟蹤不準確，導致無法得知影響進度的質量問題 5) 不夠正規（缺乏對軟件開發標準和策略的遵循），導致溝通不足和質量問題 6) 過于正規（教條地遵循軟件開發標準和策略），導致過多耗時于無用的工作 7) 向管理層撰寫進度報告占用開發人員的時間比預期多 8) 風險管理不夠重視，導致沒有發現重大的項目風險 9) 軟件項目風險管理花費的時間比預期多

風險分析

1. 風險暴露量

　　一種很有用的風險分析方法就是風險暴露量。風險暴露量就是風險發生的概率乘以損失的程度。舉例來說：如果你認為“完成需求分析比原計劃延長4周的概率是30%”，那么風險暴露量就是4周*30%=1.2周。

風險	*發生概率*	*損失程度（周）*	風險暴露量（周）
計劃過于樂觀	50%	5	2.5
由于要完全支持自動從主機更新數據而造成的額外需求	5%	20	1.0
由于市場變化而增加額外的功能	35%	8	2.8
圖形格式子系統接口不穩定	25%	4	1.0
設計欠佳——需要重新設計	15%	15	2.25
項目審批超過預計時間	25%	4	1.0
設施未能及時到位	10%	2	0.2
為管理層撰寫進程報告占用開發人員的時間比預期的多	10%	1	0.1
承包商的圖形格式子系統推遲交付	10~20%	4	0.4~0.8
新的編程工具沒有節省預期的時間	30%	5	1.5

表 5.3.1-1 風險暴露量

　　1) 評估損失程度

　　損失程度常常比發生概率更容易估算，在表5.3.1-1中，完全可能很精確地估計出由于增加“完全支持自動從主機更新數據”而增加的研發時間是20個月。如果有時損失程度不容易直接估算出來，還可以把損失分解為更小的部分分別進行估算，之后將各個小的獨立評估結果累加得出合計估算值。

　　2) 評估發生概率

　　估算發生概率比估算損失程度更具主觀性。有許多實踐方法可以提高主觀評估的精確度，例如：

由最熟識系統的人評估每個風險的發生概率，然后保留一份風險評估審核文件
每個人對風險進行獨立評估，然后討論評估的合理性，直到達成共識
使用“形容詞標準”，如非常可能、很可能、可能、或許、不大可能和不可能等，然后把口頭評估轉換成量化的評估

2. 項目的延期和緩沖

　　由于我們只談論進度風險，所以可以累加所有的風險暴露量來得到項目總風險暴露量。這個項目的總風險暴露量為12.8~13.2周，這意味著，如果不做任何風險管理的話計劃可能要延期12.8~13.2周。如果例子中的項目歷時25周，那么超出預計值12.8~13.2周就很顯然要進行風險管理了。

風險優先級

　　項目通常花費80%的金錢解決20%的問題，所以風險管理的重點是關注那最重要的20%的部分。（Boehm 1989）

　　如果只關注進度計劃風險而不是關注所有的風險，確定風險優先級的工作就變得比較容易了。在風險評估表中按風險暴露量從大到小排序看看會得到什么結果：

序號	風險	*發生概率*	*損失程度（周）*	風險暴露量（周）
1	由于市場變化而增加額外的功能	35%	8	2.8
2	計劃過于樂觀	50%	5	2.5
3	設計欠佳——需要重新設計	15%	15	2.25
4	新的編程工具沒有節省預期的時間	30%	5	1.5
5	圖形格式子系統接口不穩定	25%	4	1.0
6	由于要完全支持自動從主機更新數據而造成的額外需求	5%	20	1.0
7	項目審批超過預計時間	25%	4	1.0
8	承包商的圖形格式子系統推遲交付	10~20%	4	0.4~0.8
9	設施未能及時到位	10%	2	0.2
10	為管理層撰寫進程報告占用開發人員的時間比預期的多	10%	1	0.1

表 5.4-1 排序后的風險暴露量

　　排序后的風險評估表實際上就形成了一個粗略的風險優先級列表。如果能成功地處理風險列表中的前5個風險，就有希望將超出預期計劃的時間減少10.05周，如果能成功地處理后5個風險，則只能將超出預期計劃的時間減少2.7~3.1周。一般情況下，你的時間最好花在風險列表中靠前的風險上。

　　表5.4-1的排序只是粗略的，你可能想將損失更大的風險排在優先級更高的位置，確保他們不會發生（如：上表第6個風險）。

你也可以把一些關聯的風險排在比各自優先級更高的位置，如表5.4-1中第5和第8個風險。讓承包商開發圖形格式子系統接口，其組合風險要遠大于它們各自的風險。

　　這里確定的風險優先級是比較粗糙的，因為用于確定風險的數據都是估計的，因此優先級本身也就是個相對主觀的值。所以，對風險的客觀公正態度，是風險管理必要的組成部分。

風險管理計劃

　　編制風險管理計劃的重點是制定一個計劃，以處理風險分析中確定的高優先級風險。風險管理計劃可以簡單地理解為一段一段的風險管理描述，如：每個風險的起因，表現形式，可能發生的時間、地點，為什么發生以及怎樣發生等。風險管理計劃同時也包含：監控風險，處理新風險，關閉已化解的風險等計劃內容。

風險化解

　　特定風險的化解在許多情況下都決定于特定風險本身，下面列出一些化解風險的一般方法：

　　1、 避免風險

　　不要做冒險的活動。例如，你的項目進度比較緊，有一個工具提供商聲稱它的工具能提高你的開發速度，但是你的團隊成員從來沒使用過這個工具，這時你就不應該冒險采用這個工具。首先該工具不一定像它聲稱的那樣好，其次對工具的學習和熟識需要一個過程，如果冒險用它很可能會得不償失。

　　2、 轉移風險

　　有時，項目某部分的風險對項目另一部分來說卻不是風險，因此可以將它轉移到另一部分。例如，可以負責大部分的系統設計工作，但不要承擔不熟識的部分的設計工作，讓比較有把握的人負責設計這部分。

　　3、 購買風險相關信息

　　如果不能確切知道風險的嚴重性，可以做一些調研。也可以請外面的咨詢顧問幫你進行評估。

　　4、 消除產生風險的根源

　　例如，系統中某部分的設計可能面臨嚴重的問題，可將其作為一個研究項目徹底重新設計。

　　5、 接受風險

　　如果風險的后果較小，而處理它的成本太高，那么可以接受這個風險，不做任何處理。

　　6、 發布風險

　　讓上級領導、市場人員、客戶知道有關的風險以及可能的后果。這樣，即使風險真的發生了，他們也不會感到太驚訝。

　　7、 控制風險

　　定制計劃應對風險無法化解的情形。例如分配額外的資源來測試設計中令人擔心的那部分系統，并留出額外時間處理測試發現的問題。

　　8、 記住風險

　　總結項目相關的風險及其處理辦法、處理效果等，為未來的項目建立一組風險管理計劃。

風險	控制方法
1、功能蔓延	a) 使用基于用戶的實踐 b) 使用增量開發實踐 c) 控制功能集 d) 采取針對變更的設計
2、需求鍍金或開發人員鍍金	a) 修正需求 b) 時間鎖定開發 c) 控制功能集 d) 使用舍棄原型實踐 e) 基于進度表的開發
3、質量低劣	a) 給QA留出時間，注重質量保證基礎
4、計劃過于樂觀	a) 采用多估算實踐 b) 多個估算員和自動估算工具有原則地進行談判 c) 基于進度表的開發 d) 使用增量開發實踐
5、設計低劣	a) 要有清晰的設計活動和足夠的設計時間 b) 進行設計檢查
6、銀彈綜合癥	a) 要有一定的生成率要求 b) 建立軟件量度計劃 c) 建立軟件工具庫
7、研究導向的開發	a) 不要試圖進行研究的同時強調加快開發速度 b) 使用基于風險的生命周期模型警惕地進行風險管理
8、人員薄弱	a) 招募頂尖人才 b) 項目開始前招聘或預定關鍵成員 c) 培訓 d) 團隊建設
9、承包商失敗	a) 檢查參考資料 b) 外包前分析承包商能力 c) 積極管理承包商
10、開發人員與客戶發生摩擦	a) 采用面向進度的實踐