風(fēng)險管理包括風(fēng)險評估、舒緩風(fēng)險影響以及監(jiān)控風(fēng)險，
敏捷風(fēng)險管理
。很多敏捷用家相信敏捷開發(fā)項目風(fēng)險管理過程跟傳統(tǒng)項目差不多，雖然這過程在敏捷的內(nèi)容中較為輕盈，但是在找尋、過濾、優(yōu)先化以及制造解決方案上的步驟跟傳統(tǒng)項目中很接近。Mike Cottmeyer提出以敏捷開發(fā)去識別和舒緩風(fēng)險影響更為有效，他指出：
敏捷開發(fā)方式之所以能有效管理風(fēng)險因為風(fēng)險管理過程建立在我們執(zhí)行項目的結(jié)構(gòu)上，這隱含的意思就是風(fēng)險在項目中無處不在，風(fēng)險清單不能包括所有風(fēng)險，也不能透過團隊會議和定期的風(fēng)險評估來減輕風(fēng)險，風(fēng)險處理必須是不能抽離的思想，我們減輕風(fēng)險的策略不是處于項目以外，而是影響著如何規(guī)劃和安排工作的本質(zhì)。
他把風(fēng)險分成三類：
業(yè)務(wù)風(fēng)險– 涉及項目付運能否帶來它所預(yù)期的價值
技術(shù)風(fēng)險– 涉及技術(shù)方案在若干時間及資金下的可行性
后勤風(fēng)險– 涉及人與其他基建之間的假設(shè)
根據(jù)Mike所說，敏捷開發(fā)的本質(zhì)就是要求頻密的付運、定時的檢察和調(diào)整，這本身已經(jīng)是風(fēng)險管理。
但是也有人認為敏捷開發(fā)不是固有地處理風(fēng)險。
Jurgen Appelo認為敏捷項目經(jīng)常缺乏風(fēng)險的關(guān)注。
他認為，
Prince2、PMBOK、CMMI都有包含風(fēng)險管理的部份，但敏捷方法的書本上就很少明確地看到風(fēng)險管理的內(nèi)容，對此我感到莫名其妙。
他同時指出，項目經(jīng)理經(jīng)常埋頭在項目里，而忽略了整體宏觀形勢，這導(dǎo)致嚴(yán)重缺乏對風(fēng)險管理的關(guān)注。
另外，James Shore認為有效的風(fēng)險管理能幫助團隊作出更實在的承諾，他建議使用風(fēng)險倍數(shù)（risk multiplier）和Burn-up圖來管理項目有關(guān)的風(fēng)險。
風(fēng)險倍數(shù)包括常見的風(fēng)險，例如人事變動、要求改變、工作上的障礙之類，這些風(fēng)險倍數(shù)讓你更準(zhǔn)確地于設(shè)定日期和估計需要多少故事點數(shù)（story potints）。
James建議在團隊使用較為精確的開發(fā)過程（相對于風(fēng)險較高的開發(fā)過程，可參考James網(wǎng)站上這例子），而且速度（velocity）固定、每個故事都在迭代完結(jié)時做到"Done Done"（不僅完成客戶需要的功能，而且沒留下支持團隊的工作，原文出至于James的網(wǎng)站，亦可參考"The Power of Done"一文）的情況下使用以下的風(fēng)險倍數(shù)。
風(fēng)險倍數(shù)
機會率精確的開發(fā)過程所使用的倍數(shù)內(nèi)容10%1幾乎沒可能50%1.4伸延目標(biāo)--只得一半機會，有機會再去完成90%1.8幾乎可以成事的承諾
（這些倍數(shù)來至DeMarco和Tim Lister的RISKOLOGY模擬器（詳文可參考「與熊共舞」一書）以及Todd Little的分析數(shù)據(jù)）
這風(fēng)險倍數(shù)使用方式如下：
（假設(shè)團隊的速度為14，十個迭代后發(fā)布的話，那么當(dāng)前可運用的故事點數(shù)有140點）
機會率能完成的故事點數(shù)內(nèi)容10%140 (140 ÷ 1)幾乎沒可能50%100 (140 ÷ 1.4)伸延目標(biāo)--只得一半機會，有機會再去完成90%78 (140 ÷ 1.8)幾乎可以成事的承諾從以上例子中：
讓你可以跟項目有關(guān)人士和管理人員說：「我們幾乎肯定會在發(fā)布前完成當(dāng)中的78點，所以我們先承諾完成功能A、B和C，我們有一半機會能完成總共100點，所以我們安排功能X、Y和Z作為伸延目標(biāo)，完成好A、B和C之后再去完成他們的，管理資料
《敏捷風(fēng)險管理》(http://clearvueentertainment.com)�！�所以風(fēng)險管理在敏捷項目中就如傳統(tǒng)項目一樣，都是核心部份，重點在于適當(dāng)?shù)闹匾�、有效地處理而基于這里作出承諾。
查看英文原文：Agile Risk Management
譯者附注：
James的網(wǎng)站有更多關(guān)于其風(fēng)險倍數(shù)的內(nèi)容，亦可參考他所寫的"The Art of Agile Development"一書，特別是此文沒有包括的Burn-up圖。此外，風(fēng)險倍數(shù)的使用還有其他注意的地方：
「承諾」背后的意義，值得思考的就是「承諾」到底是什么、管理人員如何理解和使用這里作出的「承諾」。要知道，這些還是機會率，如果最后變成合約，又或者客戶拿來爭議的「論點」，那么也是沒有意思的。
風(fēng)險倍數(shù)的由來，這里的1、1.4和1.8是如何得出呢？到底又有多適合您的項目情況呢？就連James自己的網(wǎng)頁上 也有這樣一句 "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" （我在猜這些數(shù)字對極限編程的情況有多準(zhǔn)確，最準(zhǔn)確的方式還是根據(jù)過往項目紀(jì)錄來計算您的風(fēng)險倍數(shù)，但很多公司根本不會記下這些數(shù)據(jù)），所以千萬不要把這 些數(shù)字看成什么魔幻數(shù)字。
延續(xù)上面這點，如果公司為了提供「承諾」而去收集項目相關(guān)數(shù)據(jù)，這是否對容戶有所得益呢？容戶為什么要投資金錢給開發(fā)公司去收集數(shù)據(jù)？客戶又如何可以知道投資金錢讓公司收集這些數(shù)據(jù)可以有所回報呢？
其他方法如Prince2、PMBOK或CMMI等對風(fēng)險管理都有值得參考之處，而跟敏捷有關(guān)的獨特觀點則是減少開發(fā)上浪費而沒必要的過程和活動，之前在「Scrum的風(fēng)險管理」也有相關(guān)的討論。
還有，要好好管理風(fēng)險，評估形勢的能力很重要，甚至比其方法更重要，例如如何猜量我們是否在"風(fēng)險較高進行開發(fā)"呢？這里其實可以套用Stacey模型和Cynefin模型來輔助
本文出自：http://www.infoq.com/cn/news/2009/02/agile-risk-management