敏捷項目風(fēng)險管理——識別項目中的威脅和機會
Why：為什么要討論敏捷項目風(fēng)險管理
學(xué)習(xí)Scrum Guide的方法論，可以比喻為在游泳池里面練習(xí)游泳。而運用Scrum Guide為企業(yè)在現(xiàn)實市場大潮中的潮起潮落中用好和解決實際項目問題確為何那么困難?？偨Y(jié)起來因為有很多不被Scrum Guide所描述的部分其實卻是非常重要的。
比如，敏捷項目風(fēng)險管理，就是其中之一。
其實，敏捷的節(jié)奏性和迭代性使其非常適合于管理產(chǎn)品開發(fā)和相關(guān)項目中常見的各種風(fēng)險。敏捷實踐所帶來的好處和價值不容置疑，我們不能因為它的某些缺失，而完全放棄掉，這樣同樣也會放棄掉敏捷所帶來的好處。而是將其他的優(yōu)秀管理實踐結(jié)合到敏捷管理中，同時保持敏捷本身的原則不變。如何正確的將風(fēng)險管理納入敏捷項目管理，又不會破壞敏捷本身的優(yōu)勢，正是此文要探討。
傳統(tǒng)方法假設(shè)需求是定義明確和穩(wěn)定的，同時風(fēng)險也是可預(yù)知的，在這種條件下風(fēng)險可以被傳統(tǒng)方法所捕捉和建模。然而敏捷模式下（迭代性和快速變化）對傳統(tǒng)的風(fēng)險識別方法來說是很大的挑戰(zhàn)。
為了有助于應(yīng)對不確定性和獲得預(yù)期結(jié)果，敏捷模式下的方式是這樣的：
用引導(dǎo)工作坊、敏捷建模AM進行需求理解和細化
用原型設(shè)計、架構(gòu)刺探實施探索式設(shè)計方法
用增量的方式交付解決方案
這一點在高度創(chuàng)新的解決方案中尤其明顯。在這種模式下，客戶和交付團隊既要相互協(xié)作，以反復(fù)確定最終解決方案的范圍和內(nèi)容，同時又要應(yīng)對上行和下行風(fēng)險。
上行風(fēng)險類似于通過持續(xù)不斷的交付，不能擴大市場占有率，并獲得更多的業(yè)務(wù)營銷增長的風(fēng)險。
下行風(fēng)險類似于交付物無法實現(xiàn)、不能成功交付、沒有達到客戶預(yù)期，失去客戶，最終失去市場。
然而，遍尋敏捷文獻，貫穿著一種明顯的傾向，就是一貫的完全專注于下行風(fēng)險，而沒有考慮到機會的開發(fā)和利用。這種觀點單一視角的認為，風(fēng)險必須需要被考慮用來暴露潛在的消極后果。此外，還有一種盛行的觀點認為，有敏捷就夠了，因此沒有必要更明確地關(guān)注風(fēng)險的識別、評估、處理和監(jiān)控。
盡管如此，還是有一些方法論，例如基于動態(tài)系統(tǒng)開發(fā)方法（DSDM）的敏捷項目管理（AgilePM）采納了與風(fēng)險社區(qū)（Risk community）實踐較為一致的風(fēng)險管理方法。此外，敏捷社區(qū)（Agile community）越來越多的人認識到（就不確定性而言的）風(fēng)險和學(xué)習(xí)之間的關(guān)聯(lián)。
What：敏捷風(fēng)險管理實踐都有哪些？
在現(xiàn)實中，風(fēng)險可能是微妙而復(fù)雜的，缺少經(jīng)驗的人難以對其進行識別和管理。不論選擇哪一種敏捷方法，都需要敏捷風(fēng)險管理以解決以下問題：
1、識別項目中的威脅和機會，以平衡期望的回報和追求回報過程中的風(fēng)險。這不僅需要對項目中的風(fēng)險偏好和承受能力有一個徹底的了解，還需要對各個團隊成員的風(fēng)險傾向以及社會文化因素對風(fēng)險管理的影響有所認識。
2、基于風(fēng)險暴露（敞口）并通過與敏捷實踐相一致的方式辨識適當?shù)娘L(fēng)險應(yīng)對策略，并對風(fēng)險應(yīng)對策略進行優(yōu)先級排序，例如，接受、緩解、利用。
敏捷對傳統(tǒng)項目管理風(fēng)險識別實踐的借鑒和移植，可以專注于透明化，可視化，信息共享，權(quán)責(zé)共享，自組織。
敏捷實踐中，對風(fēng)險應(yīng)對策略有：
1）在Product Backlog中納入風(fēng)險應(yīng)對的相關(guān)任務(wù)。
2）使用風(fēng)險緩解看板，風(fēng)險緩解看板是一種計劃工具，其中各種活動在代表不同階段的各泳道之間移動，這些泳道分別對應(yīng)計劃、進行中、已完成。
3）用戶故事地圖（后面還會提到）
能夠通過對風(fēng)險的監(jiān)控判斷風(fēng)險是否被有效和高效的方式管理。這也包括意識到迭代層的殘余風(fēng)險，以及這些殘余風(fēng)險如何影響項目的整體風(fēng)險。
因此，無論以何種形式出現(xiàn)，敏捷風(fēng)險管理都是敏捷項目治理的基礎(chǔ)。在敏捷環(huán)境下，敏捷風(fēng)險管理可以理解為推動風(fēng)險的可視化，確保與風(fēng)險相關(guān)的集體所有權(quán)和問責(zé)制，并在往往是按以人為本的原則建立的環(huán)境中為知情決策提供支持（例如，集體主義、自組織和自我授權(quán)）。
雖然敏捷實踐者常常能說出他們基于什么在工作（例如，用戶故事）、適用哪些質(zhì)量標準（例如，“ 已完成”的定義），然而他們很少能夠說清楚他們的工作對整體項目風(fēng)險有何影響，或者他們?yōu)轱L(fēng)險管理做出了何種貢獻。
為了保證團隊異質(zhì)性、高效反饋回路和精益決策的價值不被侵蝕，將成熟的風(fēng)險管理技術(shù)集成到敏捷項目需要謹慎。因此，有必要采用與敏捷宣言中的偏好和原則相一致的風(fēng)險管理方法，而不是簡單地將傳統(tǒng)的風(fēng)險實踐嫁接到敏捷過程。事實上，經(jīng)驗表明，使用通常存在于敏捷項目中的工件（例如，Product backlog或Kanban），這是可能實現(xiàn)的。
When：什么時候?qū)嵤┟艚蓓椖匡L(fēng)險識別？
風(fēng)險管理可分為如下不同的階段：
識別
評估
處理
監(jiān)控
那么在敏捷實踐中什么時候，又如何正確實施？
敏捷項目的節(jié)奏表明，風(fēng)險的識別和評估以及風(fēng)險措施的制定應(yīng)一起納入迭代計劃。在以產(chǎn)品為導(dǎo)向的方法中（例如，Scrum，XP），這相當于 Sprint 計劃；然而，在以項目為中心的方法（例如，AgilePM），這應(yīng)該在每個時間盒（即，以啟動和規(guī)劃活動開始、緊隨執(zhí)行工作并以回顧結(jié)尾的結(jié)構(gòu)化和固定時間段）的起點發(fā)生。此后，風(fēng)險的處理和監(jiān)控可以納入迭代層的日常實踐。
傳統(tǒng)和敏捷項目風(fēng)險管理之間的一個主要區(qū)別是，風(fēng)險的所有權(quán)由項目團隊成員以類似于用戶故事（即敏捷需求）和相關(guān)任務(wù)分配的方式來確定。這就將風(fēng)險管理者的傳統(tǒng)角色轉(zhuǎn)換為一個確保風(fēng)險管理任務(wù)被關(guān)注和被實施的角色。這些功能可以很容易地通過現(xiàn)有的敏捷角色（例如，Scrum Master，DSDM 項目經(jīng)理）承擔(dān)。
風(fēng)險識別與評估
由于風(fēng)險和后果經(jīng)常被混淆，風(fēng)險的識別往往比人們想象的困難。例如，假設(shè)有一個將 Web 應(yīng)用程序從物理基礎(chǔ)架構(gòu)遷移到一個虛擬基礎(chǔ)架構(gòu)的項目，其中一種擔(dān)憂是該應(yīng)用程序在遷移后是否仍然能被訪問。許多人可能認為 Web 應(yīng)用程序的不可用性是一個項目風(fēng)險，但這實際上是失敗遷移的后果。真正存在于不確定性中的風(fēng)險是首先導(dǎo)致了web應(yīng)用程序的不可訪問（例如，關(guān)于虛擬基礎(chǔ)架構(gòu)系統(tǒng)設(shè)置是否正確的疑問，或者 Web 應(yīng)用能否通過域名系統(tǒng) [DNS] 尋址）。 風(fēng)險和后果之間的這種混淆是特別有害且不易被察覺的，因為它會對風(fēng)險管理活動造成誤導(dǎo)。
鑒于圍繞風(fēng)險認識的微妙細節(jié)，敏捷團隊的最好技巧之一是基于“是什么-為什么”的實踐（圖 1 ）。這就需要一個小組頭腦風(fēng)暴會議，以發(fā)現(xiàn)項目可能出現(xiàn)的風(fēng)險問題，隨后分析每件事情為什么可能會發(fā)生。前者識別后果，后者涉及風(fēng)險。事實上，在討論為什么一個事件可能會發(fā)生時，聽到關(guān)于不確定性的明確陳述，這種情況并不少見。例如，在前面提到的遷移示例中，可以對 Web 應(yīng)用程序的不可訪問性（是什么）進行進一步分析，以揭示各種各樣的風(fēng)險（為什么），例如，虛擬服務(wù)器的配置或 DNS 條目的正確性，從而能夠識別有意義的對策。這種方法的優(yōu)點在于它的簡單，特別是對于那些由于更長于多面手技能而疏于專家級風(fēng)險管理實踐的團隊而言。此外，由于業(yè)務(wù)和技術(shù)多種多樣，常見于敏捷團隊的多樣性可以視為尋找可能的風(fēng)險的一項優(yōu)勢。但是，舉行這類討論會時，不要專注于純粹的消極事件（例如，通過詢問什么可能出錯），而要保持討論的開放性，以發(fā)現(xiàn)該項目可利用的機會。
因此在敏捷風(fēng)險管理實踐中，我們更多的應(yīng)該關(guān)注于：
Oppotunity replace the Negative result
在“消極結(jié)果”中看到“機會”
根據(jù)傳統(tǒng)實踐，風(fēng)險應(yīng)被記錄在風(fēng)險登記簿中。然而，該工件必須始終保持可見性，其中的風(fēng)險所有權(quán)屬于團隊成員，并與用戶故事或其他敏捷項目任務(wù)一致的方式進行維護。這可以通過將風(fēng)險登記簿放在所有團隊成員能夠訪問的地方、并鼓勵他們盡可能經(jīng)常和盡可能早地提供反饋（例如，更新、補充、修正）來實現(xiàn)。
風(fēng)險評估涉及對風(fēng)險暴露的測定（其中 T 恤型號即可滿足要求，例如，使用Small，Medium、Large和Extra Large表示量級）和基于風(fēng)險所在的暴露帶對風(fēng)險打分（用于之后的風(fēng)險監(jiān)測）。這個分數(shù)需要考慮固有風(fēng)險，并應(yīng)包括需求或任務(wù)中涉及的內(nèi)容，以及如何完成這種需求或任務(wù)（例如，使用減少風(fēng)險的敏捷技術(shù)）。風(fēng)險暴露也是風(fēng)險優(yōu)先定級的核心內(nèi)容；反過來，風(fēng)險優(yōu)先定級也表明了為了應(yīng)對項目風(fēng)險而開展學(xué)習(xí)的緊迫性。如下圖，風(fēng)險暴露帶評估和風(fēng)險打分：
風(fēng)險處理
風(fēng)險評估提供確定風(fēng)險響應(yīng)（例如，避免、接受、利用）所需的輸入。有些風(fēng)險可以通過開展具體活動（稱為敏捷風(fēng)險管理中的“風(fēng)險任務(wù)分配”）來解決，有些則需要關(guān)注活動所采取的方式（稱為敏捷風(fēng)險管理中的“風(fēng)險標記”）。例如，開發(fā)產(chǎn)品用戶界面時出現(xiàn)的需求風(fēng)險可能會鼓勵團隊使用結(jié)對編程——一種兩個個體協(xié)同工作的敏捷技術(shù)—— 來執(zhí)行所有這類用戶故事。因此，在稍后的迭代過程中，團隊會識別所有受影響的活動，并將其標記以關(guān)聯(lián)與該風(fēng)險處理決策（例如，可能使用一個雙頭的圖標作為視覺提示，以使用如 圖 2 所示的結(jié)對編程）。
風(fēng)險緩解看板會讓人想到對風(fēng)險相關(guān)任務(wù)進行顏色編碼（例如，綠色為契機，紅色為威脅），以支持風(fēng)險的可視化。順帶地，這些做法也可以延伸到其他的敏捷工件，包括描述Epic和構(gòu)成它們的用戶故事之間關(guān)系的敏捷故事地圖，如 圖 2 所示。這使得風(fēng)險分布展示出優(yōu)質(zhì)的可視化效果，甚至能檢測出風(fēng)險分析可能不足的地方（例如，沒有明顯的上行或下行風(fēng)險的用戶故事集）。
風(fēng)險監(jiān)控
在風(fēng)險評估期間，用于衡量固有風(fēng)險的分數(shù)可以用來構(gòu)建跟蹤總體風(fēng)險管理工作的風(fēng)險燃盡圖。這個設(shè)置類似于故事點燃盡圖，也向團隊昭示存在一種無法完全消除的迭代剩余風(fēng)險（由用戶故事的累積剩余風(fēng)險、策略轉(zhuǎn)變、策略共享相關(guān)的風(fēng)險構(gòu)成）。此外，它清楚地顯示出風(fēng)險管理中的動態(tài)，而其他方式則可能不會如此清楚（例如，次級風(fēng)險可能會導(dǎo)致圖表上升而非下降）。在一種被稱為“風(fēng)險墻”的實踐中，建議同時尋找風(fēng)險燃盡和其他風(fēng)險相關(guān)制品（如風(fēng)險登記表、風(fēng)險緩解看板或用戶故事地圖），以提高透明度，并積極征求團隊反饋。
結(jié)論
敏捷得到比以往任何時候都更加廣泛的應(yīng)用，而其在風(fēng)險管理、治理和相關(guān)事項中的位置仍然是一些組織的障礙。但是，隨著這些挑戰(zhàn)的應(yīng)對措施被發(fā)現(xiàn)并融入敏捷方法論和項目實踐中，這一點正在開始改變。這不僅提供了有關(guān)風(fēng)險管理的監(jiān)督和問責(zé)制，同時也保證了敏捷在就其提供的價值而言的好處方面不會受到損害。
