敏捷風險管理

風險管理包括風險評估、舒緩風險影響以及監控風險。很多敏捷用家相信敏捷開發專案風險管理過程跟傳統專案差不多，雖然這過程在敏捷的內容中較為輕盈，但是在找尋、過濾、優先化以及製造解決方案上的步驟跟傳統專案中很接近。

Mike Cottmeyer提出以敏捷開發去識別和舒緩風險影響更為有效，他指出：

敏捷開發方式之所以能有效管理風險因為風險管理過程建立在我們執行專案的結構上，這隱含的意思就是風險在專案中無處不在，風險清單不能包括所有風險，也不 能透過團隊會議和定期的風險評估來減輕風險，風險處理必須是不能抽離的思想，我們減輕風險的策略不是處於專案以外，而是影響著如何規劃和安排工作的本質。

他把風險分成三類：

• 業務風險 – 涉及專案付運能否帶來它所預期的價值
• 技術風險 – 涉及技術方案在若干時間及資金下的可行性
• 後勤風險 – 涉及人與其他基建之間的假設

根據Mike所說，敏捷開發的本質就是要求頻密的付運、定時的檢察和調整，這本身已經是風險管理。

但是也有人認為敏捷開發不是固有地處理風險。

Jurgen Appelo認為敏捷專案經常缺乏風險的關注。

他認為，

Prince2、PMBOK、CMMI都有包含風險管理的部份，但敏捷方法的書本上就很少明確地看到風險管理的內容，對此我感到莫名其妙。

他同時指出，專案經理經常埋頭在專案裡，而忽略了整體巨集觀形勢，這導致嚴重缺乏對風險管理的關注。

另外，James Shore認為有效的風險管理能幫助團隊作出更實在的承諾，他建議使用風險倍數（risk multiplier）和Burn-up圖來管理專案有關的風險。

風險倍數包括常見的風險，例如人事變動、要求改變、工作上的障礙之類，這些風險倍數讓你更準確地於設定日期和估計需要多少故事點數（story potints）。

James建議在團隊使用較為精確的開發過程（相對於風險較高的開發過程，可參考James網站上這例子），而且速度（velocity）固定、每個故事都在迭代完結時做到"Done Done"（不僅完成客戶需要的功能，而且沒留下支援團隊的工作，原文出至於James的網站，亦可參考"The Power of Done"一文）的情況下使用以下的風險倍數。

風險倍數

機會率	精確的開發過程所使用的倍數	內容
10%	1	幾乎沒可能
50%	1.4	伸延目標--只得一半機會，有機會再去完成
90%	1.8	幾乎可以成事的承諾

（這些倍數來至DeMarco和Tim Lister的RISKOLOGY模擬器（詳文可參考「與熊共舞」一書）以及Todd Little的分析資料）

這風險倍數使用方式如下：

（假設團隊的速度為14，十個迭代後釋出的話，那麼當前可運用的故事點數有140點）

機會率	能完成的故事點數	內容
10%	140 (140 ÷ 1)	幾乎沒可能
50%	100 (140 ÷ 1.4)	伸延目標--只得一半機會，有機會再去完成
90%	78 (140 ÷ 1.8)	幾乎可以成事的承諾

從以上例子中：

讓你可以跟專案有關人士和管理人員說：「我們幾乎肯定會在釋出前完成當中的78點，所以我們先承諾完成功能A、B和C，我們有一半機會能完成總共100點，所以我們安排功能X、Y和Z作為伸延目標，完成好A、B和C之後再去完成他們的。」

所以風險管理在敏捷專案中就如傳統專案一樣，都是核心部份，重點在於適當的重視、有效地處理而基於這裡作出承諾。

檢視英文原文：Agile Risk Management

譯者附註：

James的網站有更多關於其風險倍數的內容，亦可參考他所寫的"The Art of Agile Development"一書，特別是此文沒有包括的Burn-up圖。此外，風險倍數的使用還有其他注意的地方：

• 「承諾」背後的意義，值得思考的就是「承諾」到底是什麼、管理人員如何理解和使用這裡作出的「承諾」。要知道，這些還是機會率，如果最後變成合約，又或者客戶拿來爭議的「論點」，那麼也是沒有意思的。
• 風險倍數的由來，這裡的1、1.4和1.8是如何得出呢？到底又有多適合您的專案情況呢？就連James自己的網頁上 也有這樣一句 "I'm guessing somewhat at how accurately they apply to XP. The most accurate approach is to calculate your own risk multipliers from past project history, but most companies don't track that data" （我在猜這些數字對極限程式設計的情況有多準確，最準確的方式還是根據過往專案紀錄來計算您的風險倍數，但很多公司根本不會記下這些資料），所以千萬不要把這 些數字看成什麼魔幻數字。
• 延續上面這點，如果公司為了提供「承諾」而去收集專案相關資料，這是否對容戶有所得益呢？容戶為什麼要投資金錢給開發公司去收集資料？客戶又如何可以知道投資金錢讓公司收集這些資料可以有所回報呢？

其他方法如Prince2、PMBOK或CMMI等對風險管理都有值得參考之處，而跟敏捷有關的獨特觀點則是減少開發上浪費而沒必要的過程和活動，之前在「Scrum的風險管理」也有相關的討論。

還有，要好好管理風險，評估形勢的能力很重要，甚至比其方法更重要，例如如何猜量我們是否在"風險較高進行開發"呢？這裡其實可以套用Stacey模型和Cynefin模型來輔助。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-566762/，如需轉載，請註明出處，否則將追究法律責任。