Scrum的風險管理

Michele Sliger指出在敏捷開發中每日站立會議、迭代計劃會議、發行計劃會議、專案回顧（retrospective）以及檢討會議都能應付風險。但是，她也提出結構性風險管理方法。步驟包括，

風險確定——每次迭代中整個團隊都進行一次，在結果紀錄在白板或者活頁樣板上。

風險分析——憑主觀判斷、直覺、及經驗作定性分析去判斷風險和潛在損失。敏捷開發中的短開發週期及定期檢討使這分析可行而有效。這有別於傳統專案管理中進行定量分析，按破壞程度配以分數。

風險反應計劃——整個團隊參與探討相關措施及行動以減低威脅。

風險監察及控制——於迭代後期監察風險及商討控制策略。以資訊輻射體（Information Radiator）方式每日監察風險。

Ron Jefferies指出風險不是問題， 而是在Scrum Master的觀察清單上的專案，記錄下哪些事情會出問題。他說，風險有不同的形式，例如內容未組裝好、新或不熟悉的技術、團隊分散於不同地域、與其他項 目的依賴等。Scrum團隊可以按價值和風險程度來決定故事的優先次序，花足夠的時間在有風險的故事上，正確地確定及減輕風險，風險應該以故事形式加上 Backlog並被處理。

Michael James提到像Scrum的軟體開發過程在專案週期中早期小心處理風險，提供各種途徑讓風險得以解決，像每日站立會議、迭代檢討等。根據Micheal，Scrum不需要建立風險紀錄，但是，團隊能定期管理風險。

有其他人指出，Scrum不能應付專案外部的風險，她能處理有關於需求轉變、缺乏溝通、和團隊表現不濟的風險，但是專案外部的風險就需要Scrum以外的技巧來處理。

Paul Hudson在Scrum Development群組亦同意類似想法， 他提出Scrum能處理專案中大部份的風險，但是Scrum不能處理團隊層面所不能處理的風險。他指出一些例子來支援他的觀點，例如顧客缺乏對Scrum 的認識、第三方產品未能如期運作、專案所依賴的外部因素沒有及時出現、團隊系統有資料丟失及遭到破壞、顧客有不同的意見聲音、顧客代表有私心並與專案目的 相違等。

另一個社群內激烈辯論的題目是“誰負責風險管理？”

Michele Sliger認為，整個Scrum團隊負責風險管理以及減低風險。

在Scrum Development群組的討論上，Ron Jeffries指出，以Scrum的術語來說，是產品負責人有責任去管理風險。有些成員同意Ron的說法，因為產品負責人最瞭解業務情況，他/她是決定 那些風險需要處理的最佳人選。產品負責人可以從團隊各成員收集訊息但最終責任始終歸於產品負責人。Peter Stevens說，

作為主要專案投資者，減輕風險直接關乎產品負責人的利益。Scrum Master 和團隊應該幫助產品負責人在Backlog作出最佳排列，但是因為產品負責人需直接負責投資回報（ROI），而風險的後果就是成本，所以風險管理就是產品負責人的責任。

群組上其他會眾提到風險管理是團隊的責任，Scrum團隊所有成員需要同心合力管理風險。

由 此可見Scrum能否管理風險以及應否明確指定管理風險都存在分歧。大多數敏捷社群的人仕都同意Scrum能處理專案有關的風險，但是當風險處於專案外部 就顯露出真空。同樣道理，到底誰負責風險管理亦沒有共識，有意見傾向產品負責人，但有部份則認為整個團隊有責任管理風險。

檢視英文原文：Managing Risk with Scrum

譯者附註：

風險管理是一個很大的研究題目，與軟體工程有關的風險管理的文獻亦有很多，很值得參考，首先要明白的概念是“風險”和“問題”之間的分別，風險是將來可能發生的事情，而不是現在發生又或者篤定會發生的事情，最明顯例子是“顧客缺乏對Scrum的認識”，在決定是否開始進行專案時這還是需處理的風險，但到專案進行中的事後，這已經是一個需要解決的“問題”。

另外值得留意一點，由SEI到南加州大學有關軟體系統工程風險研究都提出一整套風險管理方案，而沒有分“專案外部風險”或“專案內部風險”的處理方案。

2007年南加州大學Barry Bohem發表的Incremental Commitment Model，雖配以傳統定量分險管理計劃之外，也有以里程（Risk driven anchor point milestones）型式去決定下一步的工作。

• 如果專案參與者認為風險程度可以接受而風險管理計劃亦都合適，專案可以進行下一步。
• 如果風險程度可以接受而風險管理計劃未能達到需要，那需要延長這階段工作然後再檢討一次。
• 如果風險程度很低，亦直接可以進行開發。
• 如果風險程度太高，可以終止專案。

這方式提供了一個簡易的框架讓產品負責人作出相關決定。（文中對“時期”（stage）、“階段”（phase）、“里程”（milestone）有不同意思，閱讀時請留意）

敏捷開發的歷史中不斷提及去除浪費的活動，大型系統開發對風險管理的需求實在很明顯，然而對於較小型的開發專案（試想像一個四個人月完成的網站），像文中提 到“明確規定的風險管理過程”就會變得累贅，開發人員可能為“合乎標準”而循例完成一些他們或者產品負責人都覺得沒多價值的官僚活動，這樣就降低了“敏捷度”。另一方面，由於迭代和回顧機制低下，所以也不用擔心沒有及時引入風險管理措施。

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