Michele Sliger指出在敏捷開發(fā)中每日站立會議、迭代計劃會議、發(fā)行計劃會議、項目回顧（retrospective）以及檢討會議都能應(yīng)付風(fēng)險，
Scrum的風(fēng)險管理
。但是，她也提出結(jié)構(gòu)性風(fēng)險管理方法。步驟包括，風(fēng)險確定——每次迭代中整個團(tuán)隊都進(jìn)行一次，在結(jié)果紀(jì)錄在白板或者活頁樣板上。
風(fēng)險分析——憑主觀判斷、直覺、及經(jīng)驗作定性分析去判斷風(fēng)險和潛在損失。敏捷開發(fā)中的短開發(fā)周期及定期檢討使這分析可行而有效。這有別於傳統(tǒng)項目管理中進(jìn)行定量分析，按破壞程度配以分?jǐn)?shù)。
風(fēng)險反應(yīng)計劃——整個團(tuán)隊參與探討相關(guān)措施及行動以減低威脅。
風(fēng)險監(jiān)察及控制——于迭代后期監(jiān)察風(fēng)險及商討控制策略。以信息輻射體（Information Radiator）方式每日監(jiān)察風(fēng)險。
Ron Jefferies指出風(fēng)險不是問題， 而是在Scrum Master的觀察清單上的項目，記錄下哪些事情會出問題。他說，風(fēng)險有不同的形式，例如內(nèi)容未組裝好、新或不熟悉的技術(shù)、團(tuán)隊分散於不同地域、與其他項 目的依賴等。Scrum團(tuán)隊可以按價值和風(fēng)險程度來決定故事的優(yōu)先次序，花足夠的時間在有風(fēng)險的故事上，正確地確定及減輕風(fēng)險，風(fēng)險應(yīng)該以故事形式加上 Backlog并被處理。
Michael James提到像Scrum的軟件開發(fā)過程在項目周期中早期小心處理風(fēng)險，提供各種途徑讓風(fēng)險得以解決，像每日站立會議、迭代檢討等。根據(jù)Micheal，Scrum不需要創(chuàng)建風(fēng)險紀(jì)錄，但是，團(tuán)隊能定期管理風(fēng)險。
有其他人指出，Scrum不能應(yīng)付項目外部的風(fēng)險，她能處理有關(guān)於需求轉(zhuǎn)變、缺乏溝通、和團(tuán)隊表現(xiàn)不濟(jì)的風(fēng)險，但是項目外部的風(fēng)險就需要Scrum以外的技巧來處理。
Paul Hudson在Scrum Development群組亦同意類似想法， 他提出Scrum能處理項目中大部份的風(fēng)險，但是Scrum不能處理團(tuán)隊層面所不能處理的風(fēng)險。他指出一些例子來支持他的觀點，例如顧客缺乏對Scrum 的認(rèn)識、第三方產(chǎn)品未能如期運作、項目所依賴的外部因素沒有及時出現(xiàn)、團(tuán)隊系統(tǒng)有數(shù)據(jù)丟失及遭到破壞、顧客有不同的意見聲音、顧客代表有私心并與項目目的 相違等。
另一個社區(qū)內(nèi)激烈辯論的題目是“誰負(fù)責(zé)風(fēng)險管理？”
Michele Sliger認(rèn)為，整個Scrum團(tuán)隊負(fù)責(zé)風(fēng)險管理以及減低風(fēng)險。
在Scrum Development群組的討論上，Ron Jeffries指出，以Scrum的術(shù)語來說，是產(chǎn)品負(fù)責(zé)人有責(zé)任去管理風(fēng)險。有些成員同意Ron的說法，因為產(chǎn)品負(fù)責(zé)人最了解業(yè)務(wù)情況，他/她是決定 那些風(fēng)險需要處理的最佳人選。產(chǎn)品負(fù)責(zé)人可以從團(tuán)隊各成員收集訊息但最終責(zé)任始終歸於產(chǎn)品負(fù)責(zé)人。Peter Stevens說，
作為主要項目投資者，減輕風(fēng)險直接關(guān)乎產(chǎn)品負(fù)責(zé)人的利益。Scrum Master 和團(tuán)隊?wèi)?yīng)該幫助產(chǎn)品負(fù)責(zé)人在Backlog作出最佳排列，但是因為產(chǎn)品負(fù)責(zé)人需直接負(fù)責(zé)投資回報（ROI），而風(fēng)險的后果就是成本，所以風(fēng)險管理就是產(chǎn)品負(fù)責(zé)人的責(zé)任，管理資料
《Scrum的風(fēng)險管理》(http://m.msguai.com)。
群組上其他會眾提到風(fēng)險管理是團(tuán)隊的責(zé)任，Scrum團(tuán)隊所有成員需要同心合力管理風(fēng)險。
由此可見Scrum能否管理風(fēng)險以及應(yīng)否明確指定管理風(fēng)險都存在分歧。大多數(shù)敏捷社區(qū)的人仕都同意Scrum能處理項目有關(guān)的風(fēng)險，但是當(dāng)風(fēng)險處於項目外部 就顯露出真空。同樣道理，到底誰負(fù)責(zé)風(fēng)險管理亦沒有共識，有意見傾向產(chǎn)品負(fù)責(zé)人，但有部份則認(rèn)為整個團(tuán)隊有責(zé)任管理風(fēng)險。
查看英文原文：Managing Risk with Scrum
譯者附注：
風(fēng)險管理是一個很大的研究題目，與軟件工程有關(guān)的風(fēng)險管理的文獻(xiàn)亦有很多，很值得參考，首先要明白的概念是“風(fēng)險”和“問題”之間的分別，風(fēng)險是將來可能發(fā)生的事情，而不是現(xiàn)在發(fā)生又或者篤定會發(fā)生的事情，最明顯例子是“顧客缺乏對Scrum的認(rèn)識”，在決定是否開始進(jìn)行項目時這還是需處理的風(fēng)險，但到項目進(jìn)行中的事后，這已經(jīng)是一個需要解決的“問題”。另外值得留意一點，由SEI到南加州大學(xué)有關(guān)軟件系統(tǒng)工程風(fēng)險研究都提出一整套風(fēng)險管理方案，而沒有分“項目外部風(fēng)險”或“項目內(nèi)部風(fēng)險”的處理方案。
2007年南加州大學(xué)Barry Bohem發(fā)表的Incremental Commitment Model，雖配以傳統(tǒng)定量分險管理計劃之外，也有以里程（Risk driven anchor point milestones）型式去決定下一步的工作。
如果項目參與者認(rèn)為風(fēng)險程度可以接受而風(fēng)險管理計劃亦都合適，項目可以進(jìn)行下一步。
如果風(fēng)險程度可以接受而風(fēng)險管理計劃未能達(dá)到需要，那需要延長這階段工作然后再檢討一次。
如果風(fēng)險程度很低，亦直接可以進(jìn)行開發(fā)。
如果風(fēng)險程度太高，可以終止項目。
這方式提供了一個簡易的框架讓產(chǎn)品負(fù)責(zé)人作出相關(guān)決定。（文中對“時期”（stage）、“階段”（phase）、“里程”（milestone）有不同意思，閱讀時請留意）
敏捷開發(fā)的歷史中不斷提及去除浪費的活動，大型系統(tǒng)開發(fā)對風(fēng)險管理的需求實在很明顯，然而對於較小型的開發(fā)項目（試想像一個四個人月完成的網(wǎng)站），像文中提 到“明確規(guī)定的風(fēng)險管理過程”就會變得累贅，開發(fā)人員可能為“合乎標(biāo)準(zhǔn)”而循例完成一些他們或者產(chǎn)品負(fù)責(zé)人都覺得沒多價值的官僚活動，這樣就降低了“敏捷度”。另一方面，由於迭代和回顧機(jī)制低下，所以也不用擔(dān)心沒有及時引入風(fēng)險管理措施。
譯者簡介： 麥天志（Steven Mak），現(xiàn)職系統(tǒng)工程經(jīng)理，工馀時間除了游水、觀賞足球賽事、看電影以外則喜歡鉆研有關(guān)軟件開發(fā)過程、另類編程語言、美學(xué)、道德、創(chuàng)意、和預(yù)測市場等問 題。從小對編程產(chǎn)生興趣，畢業(yè)于香港大學(xué)，主修計算機(jī)科學(xué)，并于倫敦帝國學(xué)院獲取工商管理學(xué)碩士學(xué)位。志愿參與InfoQ中文站內(nèi)容建設(shè)，請郵件至editors【AT】cn.infoq.com。
來自：http://www.infoq.com/cn/news/2008/08/managing-risk-with-scrum