與熊共舞：軟體專案的風險管理 Waltzing with Bears: Managing Risk on Software Projects

與熊共舞：軟體專案的風險管理
Waltzing with Bears: Managing Risk on Software Projects

作者：湯姆.狄馬克、提摩西.李斯特/著












風險管理的主要活動

• 風險探索(risk discovery)：風險腦力激盪，把風險歸類，再訂出可長久運作的機製
• 承擔分析(exposure analysis)：以風險成形的機率，及其潛在的衝擊程度為基礎，量化每個風險
• 應變規劃(contingency planning)：萬一風險真的成形，你期望採取的行動
• 紓緩(mitigation)：在風險蛻變前必須進行的步驟，使事先規劃的應變行動在必要時能發揮作用
• 蛻變的持續監視(ongoing transition monitoring)：風險被納管之後，就要進行風險追蹤，留意是否成形

Ch8.將不確定性量化

- 風險圖
最早的完成時間會自動變成最後期限
但完成機率是零...
說定最中間的日期(5/1)
加減10~15%

Ch9.風險管理的技巧

• 風險庫
• 選擇偵測風險成形的指標

卡車司機的座右銘：
每個滾動的球後面都跟著一位追逐的孩童

並不是指都有孩童將被撞到，但看到球，還是立刻踩下煞車比較好

Ch10.風險管理的處方

如何做風險管理

1. 透過風險抭索程序找出專案面臨的風險，彙整成風險調查報告
2. 確定軟體專案的主要風險都已納入調查報告
3. 針對每個風險，完成以下事項：
• 命名風險，賦予唯一編號
• 找出蛻變指標-能及早預告風險即將成形的事物
• 預估風險成形對成本和時程的衝擊
• 預估風險成形的機率
• 計算時程和預算的風險承擔
• 預先決定執行應變行動而必須預先進行的紓緩措施
• 把紓緩措施納入專案計劃
• 把所有細節記錄在類似附錄B的制式文件內
4. 指出致命風險(showstopper)
5. 假設不會有任何風險成形，估計最早完成日期(奈米機率日,N點)
6. 參考自己或業界的不確定性係數，以N點為起點，畫出風險圖
7. 利用風險圖表示出所有承諾，風跟規劃日期和預算有關的不確定性也標示出來
8. 監視所有風險，注意是否成形或解除，一旦成形，便立即啟動應變計劃
9. 在專案進行時，持續風險探索程序，以對付較晚才浮現出來的風險

承諾與目標
時程 = 目標 = N <=非常笨的做法
時程 > 目標 > N <=比較合乎情理

不確定性的取捨
如果交付日期已敲定，且不留任何延誤的餘地
可利用版本交付時程來達成

Ch13.軟體專案的核心風險

1. 先天的時程錯誤(schedule flaw)
不把規模想清楚就敲定時程，逾期50%~80%不足為奇，主管很少會怪時程，相反地，會怪人沒有盡力
2. 需求膨脹(requirement inflation) ... 沒完沒了的需求變動
每月合理的需求變更應小於1%，因此預留時間
3. 人力流失(employee turnover)
技術人員的年平均流動率 接替人員完全進入狀況時間(ramp-up time)
4. 規格崩潰(specification breakdown)
一般人傾向於促成案子，有談不攏的衝突都會先被掩飾起來，於是專案就在缺陷、模糊的目標下進行，但開發產品時就會爆發，通常是在專案後期，預算、時間都花光了。
5. 低生產力(poor productivity)
開發人員的表現好壞差異相當大，但在團隊中，個人因素或多或少都會被中和掉，所以差異不大。

把核心風險當作風險管理是否完備的指標
不敢說核心風險是完善，但沒考量五個核心風險，就說有做風險管理....

Ch16.漸進式風險紓緩

預先採取的一套作為，萬一風險成形，便可有效地處理風險
漸進式式交付的好處：

• 迫使為組件進行優先順序
• 反暈真實的開發效率

交付計劃

• 設計藍圖(design blueprint)：顯示要實作的低階模組或類別，及彼此之間的關係
• 工作分解結構(work breakdown structure, WBS)：顯示要完成的工作，及彼此之間的相依關係
• 一組版本驗收測試(version acceptance test, VAT)：把產品的驗收測試按版本細分，顯示哪個測試可用在哪個中間產品上

實獲率

工作編號	工作量	工作百分比	完成的版本	小計	VAT通過日期
1.	11人週	11%	版本1
2.	7人週	7%	版本1
3.	12人週	12%	版本1	30%	第100天
4.	10人週	10%	版本2
5.	9人週	9%	版本2	49%	第154天
6.	8人週	8%	版本3
7.	13人週	13%	版本3	69%	第173天
8.	9人週	90%	版本4	78%	第185天
9.	14人週	14%	版本5
10.	7人週	7%	版本5	100%	第206天

ch17 終極的風險紓緩策略
計劃準時參加會議，途中可能遇到預料外的耽擱，最簡單的做法只要提早出發...

假如專案交付日期非常關鍵，那麼早點出發才是真正的風險紓緩措施