2012年3月17日 星期六

《與熊共舞:軟體專案的風險管理》筆記


1.五個風險管理活動:

(1)風險探索: 一開始先進行風險腦力激盪,然後把風險歸類,再訂出一套可長可久的運作機制,使這套程序持續進行下去

(2)承擔分析: 以風險成形的機率、及其潛在的衝擊程度為基礎,量化每個風險

(3)應變規劃: 萬一風險真的成形,你期望採取的行動

(4)舒緩: 在風險蛻變前必須進行的步驟,使事先規畫的應變行動在必要時能發揮作用

(5)蛻變的持續監視: 風險被納管之後,就要進行風險追蹤,留意是否成形


2.程序背後不確定性的來源:

(1)需求: 這系統要做的究竟是什麼?

(2)匹配: 這系統要如何與使用者、及其他周邊系統進行互動?

(3)變動的環境: 在開發期間,若需求和目標改變的話,該怎麼辦?

(4)資源: 在專案進行時,哪些關鍵的專業技術是必備的(若有需要,隨時就能派上用場)?

(5)管理: 是否有足夠的管理天分去組織一個具管理: 是否有足夠的管理天分去組織一個具屍

(6)供應鏈: 與這次開發相關的其他單位,都能如期得到他們的支援嗎?

(7)政治: 如果動用政治力來影響現實,會有什麼效果?對專案最後的成功會造成什麼限制?

(8)衝突: 不同利害關係人的目標彼此衝突時,該如何排解?

(9)創新: 影響專案最終成果的各種技術和方案有多麼獨特?

(10)規模: 根據過去的經驗,把份量和範圍擴大之後,對專案執行績效的衝擊會有多大?


3.風險管理的九個步驟:

(1)透過風險探索程序找出專案面臨的風險,彙整成風險調查報告

(2)確定軟體專案的主要風險都已納入風險調查報告

(3)針對每個風險,完成以下事項:
﹡為風險命名,並賦予唯一的編號
﹡進行腦力激盪,找出風險的蛻變指標–能有效及早預告風險即將成形的事物
﹡預估風險成形對成本和時程的衝擊
﹡預估風險成形的機率
﹡計算時程和預算的風險承擔
﹡預先決定一旦風險蛻變則必須採取的應變行動
﹡敲定為有效執行應變而必須預先進行的舒緩措施
﹡把舒緩措施納入專案計畫
﹡把所有的細節記錄在制式文件內

(4)指出做為專案前提的致命風險,循一般正式管道把這些風險往上報

(5)假設不會有任何風險成形,估計最早完成的日期

(6)下載RISKOLOGY。在主工作表上輸入專案參數,盡量客製化,最好從周遭環境、歷史紀錄中找出更可靠的資料,替換預設的業界核心風險數據。如果還追蹤了其他非核心風險,也為它們補上自訂的工作表

(7)任何承諾都以風險圖來表示,把跟預定日期和預算有關的不確定性通通標示出來。若遇上沒什麼見識的利害關係人,就直接進行模擬,把各種可能結果、各種可能性秀給他們看

(8)建立工作分解結構(WBS),展現必須完成的工作,不管用什麼方法,把每項工作要耗費的心力都預估出來。這些預估值的用法與傳統的不同:只關心相對權值(weight),不在乎它實際的值,相對權值將用來計算EVR

(9)專案一開始,再難也要敲定淨輸出入資料流定義–要律定到資料元素層級–在專案時程前12% ~ 15%就該搞定,把淨資料流的簽署視為重大里程碑,通不過,後續工作就不要做。記住,這是一個完工量測指標,簽署不成便是一項致命警告

(10)再難也要在進行任何實作前做好設計切分,再根據切分結果建立漸進交付計畫

(11)設計切分完成後,再把工作分解結構拿出來,重新預估各項工作的權值,以佔剩下未完成工作的百分比來表示

(12)以跟成本評估一樣的精確程度來進行價值評估

(13)把規格裡的需求細分到最基本的等級,根據對使用者的價值、技術風險這兩項評斷標準,進行優先順序排定

(14)建立漸進交付計畫,把產品切成很多版本(多到每周至少一個版本)。按照越優先、越早交付的方式,把所有基本需求配置到各個版本。算出每個版本的EVR,記錄在這份計畫中。把漸進交付計畫當作專案的必備文件

(15)建立產品總驗收測試計畫,切分成VAT,為每個版本都安排一個VAT

(16)把每個版本的EVR和預定交付日期標示出來,當通過VAT時,把實際結果一併標示在同一張圖上

(17)至此一直到專案結束,監視所有風險,注意是否蛻變或解除,一旦成形,便立即啟動應變計畫。注意EVR降落航道,若發現偏離,便是風險出現的徵兆

(18)在專案進行時,持續風險探索程序,以對付較晚才浮現的風險


4.為了避免模糊不清掩蓋了背後的意見不合,要定義出規格敲定(specification closure),就是各路人馬都簽署了產品對外輸出入的資料規格,而且資料流必須律定到資料元素層級。
注意,這份認可僅止於資料,跟利用資料做出什麼功能、或產生資料需要什麼功能,都沒有關係。這份規格簽署後才能放下心,對於是否已達成共識,是個不錯的指標


5.在雙贏模型,專案要開誠佈公地邀請所有利害關係人,就自身的觀點來思考專案成功的贏取條件(win condition)。這套方法中,需求被定義成一組贏取條件;除非被某人確認是贏取條件,否則不會被納入需求當中。
有時,這些條件可能會彼此衝突,尤其當利害關係人較多的時候。這時,造成衝突或對立的贏取條件就是風險


6.風險管理活動列表:

(1)持續監控蛻變指標,緊盯著風險列表上的任何東西,原來只是「可能發生的麻煩」,注意是不是就要變成「真實問題」了

(2)持續進行風險探索

(3)蒐集資料,充實風險庫

(4)每天持續追蹤完工量測指標


7.漸進交付計畫由三個專案產物所構成:

(1)設計藍圖: 顯示要實作的最低階模組或類別,以及彼此之間的交互關係

(2)工作分解結構(WBS): 顯示要完成的工作,以及彼此之間的相依關係

(3)一組版本驗收測試(VAT): 把產品的總驗收測試按版本細分,顯示哪個測試可用在哪個中間產品上


8.漸進交付計畫三要素彼此之間的關係:

(1)一個版本就是設計藍圖的一個子集

(2)能被版本驗收測試證實完成與否的工作才歸屬到同一個版本

(3)每個版本驗收測試是由一組足以判定該版本完成與否的基準所組成


9.完整的漸進交付計畫應包含:

(1)版本編號

(2)功能和特色的簡述,最好能參考到規格中的基本需求章節

(3)對應的版本驗收測試

(4)版本完成(通過VAT)的預定日期

(5)版本完成的實際日期(完成後再填)

(6)工作列表,其中的工作項目都出自於WBS,而且為版本完成所必需

(7)版本的EVR值
﹡EVR是在目前版本中,已證實完成並可正常運作的部分所消耗的工作成本,以佔總預算的百分比來表示


10.當風險管理開始進行,成為組織文化的一部份時,專案應可通過以下全部的測驗:

(1)有一份風險調查報告。其中不但列出所有軟體專案的核心風險,也列出該專案的獨特風險,全都是造成災難的真正原因(會導致恐怖結果的事物,而不僅僅是恐怖結果本身)

(2)風險探索程序正在進行。風險探索對所有參與人員都是開放而歡迎的,對於不受歡迎的構想,有特定步驟保戶參與人員,讓他們安全而清楚地表達意見。甚至開放匿名管道,以傳遞壞消息

(3)不確定性圖隨處可見。這些圖用來量化成因風險、展現加總風險和期望值。有一種組織文化開始形成: 認為在承諾前沒有明確把不確定性標示出來,就是不夠專業

(4)專案不但有目標,也有預估,而且分開成兩碼事。目標也許會訂在完成機會是奈米級的程度,但預估一定非常保守,假如目標訂在十二個月後,預估應該至少在十八個月以後。任何承諾都一定伴隨某種程度的把握,並透過不確定性圖來表示

(5)每個風險都指定了蛻變指標。蛻變監控正持續進行,以偵測風險成形

(6)每個風險都安排好應變計畫和舒緩措施。應變行動已列入工作分解結構,寧可備而不用。舒緩行動也已律定清楚,安排在最早需啟動應變行動之前實施

(7)對每個風險都評估過風險承擔

(8)有專案價值評估的量化數據,專案結束也會量測實際價值。各系統組件已根據價值進行優先順序排定,並建立版本計畫

(9)專案計畫至少採取了某種程度的漸進法。版本中有某部分或全部會真正交付給利害關係人,或假交付(交付步驟都做到,只是不交出成果)。每個版本的完成時間、耗費心力、相對規模等數據都被保留,做為專案中、後期的完工量測指標

沒有留言:

張貼留言