「老師，要管好專案的風險，您覺得是用傳統式的方法比較好，還是用敏捷式的方法比較好？」一位學員在課後向我這樣提問。

當下我還真楞了一下，倒不是因為我不會回答這個問題，而是自從教授敏捷相關課程這麼多年以來，這還是頭一遭有人問到這樣的議題。

先說我的結論，總體而言，我認為，敏捷方法技高一籌。

有人說，需求的變化少，市場相對穩定的產品專案，就不適合使用敏捷方法，這點我是不太認同的。因為即便是需求變化少，市場相對穩定的產品專案，敏捷方法依然可以較傳統方法更能對團隊和組織產生貢獻，例如，溝通效率和效果的提升、團隊凝聚力的提升、團隊承諾度的提升、專案進度的透明度和可預測性等等，在風險管理的議題上，其實也是如此。

管理過專案的人，多半都有過這樣的經驗，那就是，在專案執行過程中，總會時不時地冒出一些意外狀況，打亂原本的美好計畫（ㄜ…如果你有先做計畫的話…），若是這些意外狀況嚴重一些，甚至還會把整個團隊搞得天翻地覆，人仰馬翻。這些意外狀況通常被人稱為「風險」，但我卻認為，這種說法只對了一半。

其實，大部分的這些「風險」都不應該發生，只要你有認真落實專案風險管理作為的話。但事實是，從我為眾多企業客戶提供服務的經驗中可以發現，絕大多數的專案，在專案風險管理作為的投資上，都是嚴重不足的，包括專家人力、時間和金錢等。

不僅如此，還有為數不少的專案，甚至是連基本的計畫（Excel 甘特圖不算喔）都沒做就趕著開工的。「不做計畫，先衝再說」本身就是專案最大的風險！這也合理說明了，為什麼「大小意外頻傳」在專案管理上是這麼普遍常見了，而這就正是專案管理之所以一直做不好的根源所在之一。

坦白說，不論是採用傳統方法或敏捷方法來管理專案，只要腳踏實地，好好落實，不要偷工減料，專案的風險多半都能獲得良好的控管，不致於發生什麼嚴重後果而無法收拾。可是，如果組織的專案常態性地遭遇「意外狀況」，久而久之，組織就會視此為「理所當然的不可控」，就愈不會積極事先投放資源去減輕或消滅風險。慢慢地，組織的專案管理就會陷入惡性的循環，沒人想做專案管理，團隊也很難士氣高昂。

關於敏捷方法裡的風險管理是怎麼做的，官方文件並沒有什麼著墨，坊間的各派說法其實也不一，不過大多都和傳統專案風險管理的手法相去不遠，這裡我就不贅述這些細節了。我比較想談的是，那些早就巧妙融合進敏捷方法框架的風險管理作為，而我們卻不太容易察覺得到的。

（以下我假設你已經具備了敏捷方法的基本認識）

-----------------------------------------------------------------------------------

1. 需求的蒐集（Requirement collection），必須從用戶和客戶的觀點出發，幫用戶和客戶創造最大價值，以滿意度而非範疇完整度，做為產品專案成功與否的依據，讓專案範疇失焦的風險大減。

2. 需求的實作，必須以對用戶和客戶創造的價值大小為優先順序，總是將有限資源聚焦在高價值需求之上，讓較難以預期的專案人力資源斷鏈和臨時壓縮專案時程的風險衝擊大減。

3. 需求的所需工時，必須由所有開發團隊成員、敏捷大師，以及產品負責人，以集體經驗和智慧共同迅速估算，同時彌補個別成員在各自獨立時間估算上的盲點，讓專案時程延誤的風險大減。

4. 衝刺規劃會議（Sprint planning meeting），必須由所有開發團隊成員、敏捷大師，以及產品負責人共同參與，以集體經驗和智慧共同迅速產出所需的實作細節，同時填補個別成員的專家偏誤和盲點，讓專案的範疇失焦、品質瑕疵，以及時程延誤的風險大減。

5. 衝刺的週期（Sprint duration）必須固定，且最長不超過四週，用戶、客戶，以及敏捷團隊，在每個衝刺後，都要進行一連串包括進度、成本、團隊合作效能等之績效評量，短期就可及時發現進度落後、成本超支、範疇失焦、範疇潛變（Scope creep）等問題，並於下個衝刺及時修正，排除類似的潛在風險。

6. 每個衝刺都得有具體可用的產出（M.V.P.），且必須是「累加過去驗收成果」之總成果，可以交付給用戶和客戶實際試用，取得真實、具體的市場回饋，以做為後續修訂實作或變更需求的依據，大幅減少專案範疇失焦的風險。

7. 衝刺期間，衝刺待辦事項清單（Sprint backlog）內的需求必須鎖定，不得再任意變更，以避免不斷範疇失焦或潛變的風險，同時取得各種績效衡量所需的數據和基準。

8. 回顧與改進會議（Retrospective meeting），每個衝刺結束時都得召開，敏捷團隊必需全員參與，檢討並改進重點缺失，包括「對需求的誤解」、「進度承諾的失守」等，並於後續衝刺及時導正，排除進一步範疇失焦和進度延誤的風險。

9. 每日立會（Daily Scrum），在專案期間每天都得召開，敏捷團隊必須全員參與，以及時處理團隊所遭遇的障礙，降低進度延誤的風險。

一個新產品最大的風險，不外乎就是「上市時程延誤」、「銷售不佳」，以及「遭遇大量客訴」這三大主要風險，而這三者在產品的專案開發期間，對照的就是「團隊績效不彰」、「需求掌握不足」，以及「品質紀律不良」，所幸，這些都是敏捷方法所擅長解決的風險議題。

除了適度引用傳統的專案風險管理手法之外，老實說，只要能好好落實敏捷方法的要求，不要任意偷斤減兩，很多風險都會在不知不覺當中就被敏捷方法給消滅掉，這也就是為什麼我在文章一開始之時就說，「敏捷方法會技高一籌」的原因了。您覺得呢？

本文轉貼自：威廉網紙（原文標題：Scrum 敏捷方法裡，渾然天成的九大風險管理把關設計）