選擇風險策略（Choose Risk Strategy）的重點，是讓團隊在風險發生前，先釐清可接受的不確定性、判斷基準與升級界線。
在 Disciplined Agile（DA）中，風險同時涵蓋威脅與機會。團隊需要處理可能拖慢交付、影響品質或增加營運壓力的威脅，也需要辨識值得主動承擔的機會，例如提前驗證新技術、探索市場需求，或取得交付上的彈性。
風險承受能力（Risk Appetite）、風險態度（Risk Attitude）與風險門檻（Risk Threshold）會形成團隊判斷風險的共同基準。風險價值生命週期（Risk-Value Life Cycle）則提醒團隊，把高風險工作提前放入產品待辦清單、架構技術試驗、概念驗證與交付檢查點中，避免風險只停留在會議討論或文件紀錄。
風險策略若能連到產品待辦清單（Backlog）排序、架構技術試驗（Spike）、概念驗證、里程碑檢查與上線前確認，風險討論就能進入日常決策，成為團隊排序、取捨與升級處理的依據。
選擇風險策略（Choose Risk Strategy）在 Disciplined Agile（DA）中的定位
風險策略會影響團隊如何安排工作、何時升級問題，以及哪些不確定性需要在專案早期先處理。
在 Disciplined Agile（DA）中，選擇風險策略（Choose Risk Strategy）屬於應對風險（Address Risk）流程目標的一部分。這個決策點會把討論拉到交付原則：團隊準備用什麼方式面對交付過程中的不確定性。
這個決策點會要求團隊與關鍵利害關係人先釐清風險處理方式。
團隊如果等到風險發生後，才討論責任歸屬、升級路徑與可接受範圍，決策就會受到時程壓力、交付成本與部門立場牽動，難以做出合適的風險處理判斷。
應對風險（Address Risk）處理的管理問題
應對風險（Address Risk）處理的是團隊如何辨識、評估與回應風險。
DA 將風險視為會影響一個或多個目標的不確定事件或條件。
這種影響可能帶來損失，也可能創造機會。造成負面影響的是威脅，帶來正面影響的是機會。
例如團隊準備導入一套新的金流服務。技術介接不熟悉、資安審查時間不明、供應商支援能力有限，這些都屬於威脅。如果新金流服務能縮短付款流程、提高訂單完成率，就可能形成機會。
團隊需要同時看見這兩種情況，才知道哪些工作需要提早驗證，哪些機會值得保留投入空間。
應對風險是為了讓團隊把注意力放在威脅與機會的實際處理上。
風險討論如果只停在管理表單、審查程序或定期報告，團隊即使看見風險存在，後續仍是缺少足夠的行動來降低威脅或掌握機會。
選擇風險策略（Choose Risk Strategy）聚焦的決策時機
選擇風險策略（Choose Risk Strategy）聚焦在專案開始，或重大方向改變時，團隊準備如何面對風險。
這個決策點要求團隊與關鍵利害關係人公開討論風險處理方式。
討論內容包含風險如何被發現、如何分類、如何回應、誰需要參與判斷，以及哪些情況需要升級處理。
這些共識需要在風險發生前建立。當系統已經接近上線、供應商交付延遲，或架構整合出現問題時，團隊才開始爭論可接受範圍，決策品質就會受到時間壓力影響。
DA 強調團隊依情境選擇工作方式（Way of Working，WoW），風險策略也需要依情境調整。
小型內部工具可以採用簡化的風險清單與定期檢查。跨部門、高能見度或涉及法規的系統，需要更清楚的風險分類、升級規則與利害關係人參與方式。
風險透明度對團隊協作的影響
風險透明度會影響團隊能否及早取得協助。
有些風險可以在團隊內處理，例如補上自動化測試、安排架構技術試驗（Spike），或重新拆分產品待辦清單（Backlog）中的工作項目。
有些風險需要團隊外部支援，例如資安審查、法務判斷、供應商協調、預算調整，或高階利害關係人決策。
風險如果只停留在個人判斷中，其他人就無法判斷該投入哪種協助。
產品負責人可能不知道需求順序需要調整，架構師可能太晚得知整合風險，管理者也無法在適當時間協調資源。
DA 在應對風險中強調，風險需要反覆被辨識、評估與處理。
利害關係人願景（Stakeholder Vision）里程碑需要確認團隊是否理解自己面對的風險，並確認團隊是否具備可行的回應策略。
進入建構（Construction）階段後，每一次是否繼續前進的判斷，也都需要納入目前的風險水準。
風險透明可以從輕量做法開始。
對交付團隊來說，第一步可以很簡單：把高風險工作標記在產品待辦清單中，將需要驗證的假設安排成架構技術試驗，並在重要檢查點重新確認風險是否已經下降、轉移，或需要升級處理。
在日常看板中，除了標記高風險工作，也可以設立風險泳道（Risk Swimlane），或使用特定顏色的卡片，例如紅色卡片或特殊標籤，凸顯已經觸發門檻、需要緊急升級處理的風險阻礙（Impediment）。
風險承受能力（Risk Appetite）與風險態度（Risk Attitude）：先對齊組織能接受的不確定性
在決定風險策略前要先判斷一件事：組織願意承擔多少不確定性。
同一個風險放在不同團隊面前，可能會得到完全不同的判斷。導入新技術對創新產品團隊來說，可能是值得追求的機會。對處理金流、醫療資料或法規申報的團隊來說，會先被視為需要嚴格控管的威脅。
選擇風險策略（Choose Risk Strategy）要求團隊在風險發生前，先討論風險承受能力（Risk Appetite）與風險態度（Risk Attitude）。
風險承受能力協助團隊定義可接受的不確定性範圍，風險態度協助團隊理解組織面對不確定性時的判斷傾向。這兩者如果沒有先對齊，後續討論風險門檻、工作排序與升級路徑時，就會缺少共同判斷基準。
風險承受能力（Risk Appetite）定義可接受的不確定性
風險承受能力（Risk Appetite）描述組織為了取得回報，願意接受多少不確定性。
它回答的是「我們願意承受到什麼範圍」。這個範圍可以是預算曝險、停機時間、交付延遲、資料品質風險，也可以是新技術試驗失敗的次數或影響範圍。
以資料遷移為例，團隊需要先知道組織能接受多少服務中斷時間，能接受多少資料需要人工補正，以及遷移失敗時，是否有足夠時間回復到舊系統。這些答案會直接影響團隊採用一次性切換、分批遷移，或先安排小範圍試轉的決策。
風險承受能力也會影響團隊追求哪些機會。如果組織願意承擔較高的不確定性，團隊可以提前安排新技術試驗、探索新市場功能，或推出範圍較小的版本取得回饋。如果組織能接受的不確定性較低，團隊就需要先增加驗證、審查與回復機制，再把高風險工作放進交付節奏中。
因此，風險承受能力會定義組織願意追求哪些類型的風險。
團隊需要說清楚哪些風險值得主動承擔，例如新技術試驗、商業模式探索或新市場功能。哪些風險需要先避免或降低曝險，例如合規缺口、資料外洩、正式環境長時間中斷。
有些風險承受能力不容易量化。例如品牌信任、利害關係人接受度、團隊對新技術的熟悉程度，就很難直接換算成金額或固定門檻。
遇到這類質化風險時，團隊需要補上判斷依據，例如過去事故紀錄、專家意見、使用者回饋或治理要求。
這項共識需要在風險發生前建立。風險已經進入處理階段後，團隊才開始討論可接受範圍，決策會受到時間壓力、個人立場與利害關係人焦慮影響。
風險態度（Risk Attitude）影響定性判斷
風險態度（Risk Attitude）描述組織面對不確定性時的整體看法。
它回答的是「我們面對風險時傾向採取什麼姿態」。
不同組織對風險的判斷傾向不同。有些組織重視保守避險，會先確認合規、穩定性與品牌影響。有些組織願意主動承擔風險，會用較短週期試驗新功能，並接受部分嘗試沒有產生預期結果。
風險態度會影響定性風險分析。某個風險不一定能立刻轉成金額或百分比，團隊仍需要判斷它的嚴重度與處理優先順序。
例如若「團隊第一次使用某個雲端服務」，應用在內部管理工具中可以透過概念驗證（Proof of Concept，PoC）先行嘗試。而在處理敏感個資的系統中，資安、稽核與法務角色會要求完整審查。
同一個技術風險會因風險態度不同，產生不同處理方式。
保守型組織會要求較多證據與批准流程。積極型組織會保留試驗空間，並透過小範圍發布、監控與回復機制控制曝險。
風險態度也會隨經驗改變。團隊若曾在某類整合上發生事故，後續面對相同類型的風險時，判斷會變得較謹慎。團隊若已經多次成功處理相似風險，利害關係人也可能願意放寬部分限制。
這種改變都應留下明確記錄評估依據，避免只靠記憶或個人感覺調整風險判斷。
風險承受能力（Risk Appetite）與風險態度（Risk Attitude）的差異
風險承受能力偏向邊界設定，風險態度偏向判斷傾向。
團隊討論風險承受能力時，需要說清楚可以接受多少損失、變動或不確定性。團隊討論風險態度時，需要說清楚面對相同風險時，會採取保守、平衡或積極的做法。
以導入尚未熟悉的新技術為例，組織可以具備較高的風險承受能力，願意投入時間與預算探索新技術。同時採取審慎的風險態度，要求團隊先完成概念驗證、資安檢查與回復方案，再進入正式開發。
另一種情況是組織的風險承受能力較低，仍希望團隊保持積極試驗。這時團隊需要縮小試驗範圍，例如只在非關鍵流程驗證、只讓內部使用者試用，或用功能開關控制影響範圍。這種做法可以保留探索空間，並讓曝險範圍維持在組織可接受的界線內。
把兩者分開討論，可以減少風險會議中的混亂。
有人主張先試，有人要求先審，背後可能牽涉兩個被混在一起的問題：組織能承受到什麼程度，以及組織面對不確定性時想採取什麼姿態。
利害關係人對風險看法不一致時的處理方式
風險承受能力與風險態度都需要取得共識，討論難度也因此提高。
產品負責人可能希望提早推出功能，業務主管可能重視市場時機，資安人員會關注資料保護，維運團隊會在意正式環境穩定性。這些角色面對的是同一個風險，衡量角度卻都不同。
團隊可以透過風險工作坊或交付規劃會議（Delivery Planning Meeting），把這些差異攤開來討論。
討論時需要同時釐清幾件事：這個風險是否偏高、組織願意承受到什麼程度、哪些情況需要升級，以及目前有哪些證據支持這個判斷。
對技術與架構相關風險，團隊可以用架構決策紀錄（Architecture Decision Record，ADR）記錄重要取捨。紀錄內容可以包含採用某項技術的理由、已知風險、接受範圍、回復方案，以及哪些條件發生時需要重新評估。
當利害關係人無法立即取得一致，團隊也可以先設計較小的驗證步驟。
透過概念驗證、架構技術試驗（Spike）或小批量交付（Small Batch Delivery）取得證據後，再回到風險承受能力與風險態度的討論。這能讓團隊跳脫個人的主觀徧好，改用可觀察的事實支持風險判斷。
風險門檻（Risk Threshold）：把升級處理的界線說清楚
風險承受能力說明組織願意接受多少不確定性。風險門檻（Risk Threshold）會把這個範圍轉成更明確的判斷界線。
在專案進行中，團隊需要知道哪些風險可以自行處理，哪些風險已經超出團隊能承擔的範圍。這條界線如果沒有先說清楚，風險升高時，團隊會花時間爭論責任、權限與通報對象。
風險門檻也可以被理解為風險範圍（Risk Range）。它會受到風險承受能力與風險態度影響。組織如果偏向保守，門檻會設得較嚴。組織如果願意承擔較高的不確定性，門檻就會留出較大的操作空間。
風險門檻（Risk Threshold）提供升級判斷基準
風險門檻提供的是升級判斷基準。
團隊可以用它定義何時需要把風險納入風險登錄表，何時需要請管理層介入，何時需要暫停某項工作，或何時需要調整交付計畫。
例如財務曝險低於某個金額時，產品團隊可以自行判斷是否接受。高於該金額時，就需要財務主管或贊助人參與決策。系統停機時間低於某個範圍時，維運團隊可以依既有程序處理。一旦超過約定時間，就需要啟動事故升級與對外溝通流程。
資安與法規風險也需要類似界線。掃描工具如果發現低嚴重度缺陷，團隊可以排入後續修補。缺陷如果涉及敏感資料外洩或法規義務，團隊就需要立即通知資安、法務與治理角色。
這些門檻可以減少團隊在風險升高時的決策時間。當風險狀態改變時，團隊可以依照事先約定的界線行動，降低臨時協調造成的等待。
定量與定性風險門檻的差異
有些風險門檻可以用數字表達，例如金額、停機時間、錯誤率、資料筆數、延遲天數或效能指標。
這類門檻適合放進風險登錄表、上線檢查表或事故處理流程中。團隊可以在事前約定，例如「正式環境錯誤率超過某個比例就停止發布」、「資料遷移失敗筆數超過某個數量就啟動回復方案」、「供應商延遲超過幾天就重新規劃範圍」。
有些風險較難量化。品牌信任、利害關係人接受度、團隊對新技術的熟悉程度，以及跨部門合作成熟度，都需要定性判斷。
這類風險無法只靠一個數字決定嚴重程度，團隊需要結合專家判斷、過去事故紀錄、使用者回饋與治理要求。
以上線前風險評估會為例，團隊可以把兩種資訊放在同一張風險表中。
可量化的部分記錄指標與門檻，例如缺陷數量、效能測試結果與回復時間。
定性部分記錄判斷依據，例如架構師對整合風險的評估、資安人員對資料處理的意見，以及產品負責人對利害關係人接受度的觀察。
這樣做的目的，是讓升級判斷有跡可循。當團隊決定繼續前進、暫停發布或調整範圍時，相關的利害關係人都能看見判斷依據。
門檻變動帶來的隱性風險
風險門檻會隨著經驗改變。
團隊處理某類風險的經驗增加後，可能會願意放寬門檻。例如團隊已經多次完成同類資料遷移，並具備穩定的回復腳本與驗證流程，利害關係人可能會接受較大的批次，或較短的驗證時間。
事故經驗也會讓門檻收緊。如果某次上線曾因供應商介接失敗造成正式環境中斷，後續相似工作就可能需要更早完成整合測試、更明確的回復方案，以及更早的管理層檢查點。
門檻變動同樣會帶來風險。團隊如果只因為「做過幾次」就放寬標準，可能會低估情境差異。相同類型的資料遷移，也可能因資料量、系統相依性、客戶能見度與法規要求不同，而需要不同的處理方式。
因此，門檻調整需要留下紀錄。團隊可以在風險登錄表、架構決策紀錄（Architecture Decision Record，ADR）或上線檢查紀錄中，說明調整原因、依據與適用範圍。
當下一次專案面對類似風險時，團隊就能透過紀錄，回頭檢查當時的判斷條件是否仍然成立。
風險價值生命週期（Risk-Value Life Cycle）：將高風險工作提早處理
風險策略落到日常工作時，會直接影響產品待辦清單（Backlog）的排序。
透過風險價值生命週期（Risk-Value Life Cycle）的思維，團隊安排工作時，應要同時看利害關係人價值與風險。
價值高的工作值得關注，風險高的工作也需要提早進入視野。
這種做法背後有一個簡單判斷：風險發現得越晚，團隊可用的時間、預算與方案空間就越少。
重大風險如果到建構（Construction）後期才被看見，團隊可能已經投入大量設計、開發與協調成本，調整也會變得困難。
以風險和價值共同排序工作
產品待辦清單排序如果只看商業價值，高風險工作可能就會被排到後面。
例如一個新功能能帶來明確營收，因此被排在前面。
同時，這個功能需要介接新的供應商 API、調整資料模型，還要符合資安審查要求。
如果團隊先做畫面與流程，把供應商介接與資料一致性放到後期，真正影響交付成敗的風險就會太晚曝光。
風險價值生命週期提醒團隊，排序時需要把風險納入判斷，形成風險調整後待辦清單（Risk-Adjusted Backlog）。
高價值工作如果伴隨高風險，團隊可以先拆出風險驗證項目，例如供應商介接測試、資料遷移試跑、效能基準測試或資安審查前置工作。
這些工作不一定會立即產生使用者可見功能，卻能提早回答關鍵問題。
系統能不能接上供應商服務、資料能不能正確轉換、架構能不能支撐預期流量，這些答案會影響後續需求範圍、交付時程與技術方案。
用風險與價值共同排序，能讓團隊在產品待辦清單中看見需要優先處理的工作。讓高風險項目安排在合適的位置，團隊才能根據驗證結果決定後續投入方式。
提早處理高風險項目的好處
提早處理高風險工作，可以讓團隊在時間與預算仍較充足時面對問題。
新技術導入、跨系統整合、資料遷移、效能要求與法規審查，都需要在早期安排驗證。
團隊可以用架構技術試驗（Spike）確認技術可行性，用原型（Prototype）驗證使用流程，也可以用小批量交付（Small Batch Delivery）先讓有限範圍的使用者接觸新能力。
以資料遷移為例，團隊可以先選一小批代表性資料試跑，檢查欄位對應、資料清理規則、錯誤處理與回復步驟。這樣做可以提早發現資料品質問題，也能讓產品負責人、資料擁有者與工程師共同確認遷移規則。
以跨系統整合為例，團隊可以先完成最小介接路徑，確認認證方式、錯誤碼、逾時處理與監控事件。如果供應商文件與實際行為不同，團隊仍有時間調整架構，或者與供應商釐清支援方式。
團隊如果發現某個風險無法被處理，就可以在投入過多成本前轉向或停止，避免團隊在不可行的方向上繼續投入。
新團隊面對高風險工作時的壓力
高風險工作常伴隨著較高複雜度，這也是風險價值生命週期需要處理的取捨。
新組成的團隊還在熟悉彼此的工作方式、技術背景與溝通節奏。如果一開始就處理供應商整合、資料遷移或新架構導入，團隊可能同時面對技術未知、角色分工不清與決策路徑不明。
這時團隊可以先建立一個最小程度的討論範圍，再安排高風險工作進入迭代。
團隊可以用技能矩陣（Skills Matrix）確認誰熟悉相關技術，讓成員一起順過流程、設計與失敗情境，再用架構決策紀錄（Architecture Decision Record，ADR）記錄已知限制與決策依據。
例如團隊準備導入新的事件驅動架構，可以先安排一段架構技術試驗，讓後端、維運、資安與產品角色共同檢查事件格式、重送機制、監控方式與失敗補償流程。這段工作不需要涵蓋整個系統，重點是讓團隊先看見最大的未知。
當高風險工作被拆成可討論、可驗證、可回復的小步驟，新團隊就能在建立合作方式的同時處理風險。
風險價值生命週期讓關鍵的不確定性提早被看見，也讓團隊用可控步驟面對複雜工作。
情境調整：讓選擇風險策略（Choose Risk Strategy）符合專案條件
風險策略需要配合專案條件調整。
選擇風險策略（Choose Risk Strategy）沒有固定流程。依據團隊規模、交付範圍、技術未知、供應商數量、客戶能見度與組織重要性的不同，合適的風險處理方式也會不同。
風險處理方式需要符合情境，團隊也需要留意人的判斷偏差。不同利害關係人能接受的風險不同，團隊也可能因為對自己過度有信心，而低估失敗機率。
規模（Size）決定風險策略的正式程度
規模（Size）會影響風險策略需要多正式。
如果工作金額高、客戶能見度高，或牽涉多個部門，團隊需要更清楚的風險登錄、升級規則與利害關係人溝通節奏。
例如一個會影響主要客戶帳務流程的系統改版，就需要超出團隊內部口頭判斷的風險處理方式。團隊需要明確記錄已知風險、負責角色、門檻、回復方案與通報路徑。
規模較小、影響範圍有限的工作，可以採用較輕量的做法。例如內部報表欄位調整、低流量管理工具優化，團隊可能只需要在產品待辦清單（Backlog）中標記風險，在每日協調時確認進展，並在發布前完成簡單檢查。
正式程度需要對應事件影響範圍。做法太輕量，重大風險會缺少可追蹤的處理方式。做法太重，小型工作便會被不必要的流程拖慢。
複雜度（Complexity）決定風險辨識的深度
複雜度（Complexity）會影響團隊需要辨識到多深的風險。
新技術、多個整合點、多家供應商與跨團隊協作，都會增加風險來源。這類工作需要較完整的風險探索。團隊不能只檢查單一功能是否完成，還需要檢查相依系統、資料流、權限、監控、錯誤處理與回復流程。
以導入新支付服務為例，團隊需要同時檢查技術介接、資安合規、營運流程、客服處理與回滾方案。支付成功後，訂單狀態沒有更新、退款流程與會計資料不一致、供應商 API 在高峰時段逾時，這些情況都可能讓功能完成後仍無法穩定上線。
複雜度高的工作也需要更早安排驗證。團隊可以先完成最小介接路徑、安排供應商聯測、建立測試資料，並確認正式環境發生異常時的處理方式。
這些工作能讓風險在開發早期被看見，減少上線前集中爆發的情況。
重要性（Importance）決定治理與盡職調查的程度
重要性（Importance）會影響團隊需要投入多少治理與嚴謹程度。
內部小工具、營收主流程與法規相關系統，需要的風險嚴謹度不同。
內部小工具出錯時，影響可能集中在少數使用者。營收主流程中斷時，會直接影響訂單、客服與品牌信任。法規相關系統出錯時，還可能帶來合規責任。
重要性越高，越需要明確的決策門檻、利害關係人參與、里程碑檢查與風險升級路徑。
團隊也需要確認目前採用的嚴謹度是否足夠，例如是否需要正式審查、資安確認、法務意見、資料保護檢查或管理層批准。
時間跨度也會影響重要性判斷。專案時間越長，技術條件、競爭環境都可能改變。團隊需要在重要檢查點重新確認風險策略是否仍然合適，避免一直沿用啟動時的判斷。
團隊選擇工作方式（Way of Working，WoW）時，需要把規模、複雜度與重要性放在一起看，再決定風險策略要多正式、多深入，以及需要哪些角色參與。
落地做法：把選擇風險策略（Choose Risk Strategy）變成團隊工作方式
選擇風險策略（Choose Risk Strategy）需要進入團隊的日常工作，才會影響真正的決策。
團隊可以在會議上討論風險，也可以寫出一份風險策略文件。這些做法如果沒有連到產品待辦清單、交付規劃、里程碑檢查與升級路徑，風險仍只會停留在討論層次。
風險需要在整個生命週期中被辨識、評估與處理。
落地的關鍵，是讓風險資訊進入團隊正在使用的工作方式，例如產品待辦清單、風險登錄表、架構決策紀錄與交付檢查點。
在專案早期建立風險討論節奏
風險討論需要在專案早期開始。
第一步可以很簡單：團隊先列出主要風險來源。
這些來源可能包含需求不確定性、技術可行性、資料品質、供應商配合、資安合規、利害關係人參與，以及正式環境發布條件。
接著，團隊需要討論風險承受能力（Risk Appetite）、風險態度（Risk Attitude）與風險門檻（Risk Threshold）。
這些討論會決定哪些風險可以由團隊自行處理，哪些風險需要提早讓管理者、資安、法務、架構師或供應商角色參與。
風險討論也需要有明確產出。
團隊可以把已知風險放進風險登錄表，將重要技術取捨寫進架構決策紀錄（Architecture Decision Record，ADR），或在產品待辦清單（Backlog）中標記高風險項目。
這些紀錄不需要厚重，重點是讓團隊在後續規劃時持續看見這些風險。
例如團隊準備導入新的身分驗證服務，可以先記錄三個風險：供應商 API 穩定性、既有帳號資料轉換、正式環境回復方式。接著安排對應的驗證工作，例如介接測試、資料試轉與回復演練。
將風險資訊連回產品待辦清單（Backlog）
風險策略需要影響產品待辦清單（Backlog）的排序與拆分方式，進而形成風險調整後待辦清單（Risk-Adjusted Backlog）。
某項功能如果同時具有高價值與高風險，團隊可以先拆出風險驗證工作。
這類工作可能包含架構技術試驗（Spike）、概念驗證（Proof of Concept，PoC）、最小可行產品（Minimum Viable Product，MVP）、資料試轉、供應商聯測、效能基準測試或資安審查前置工作，以便快速驗證假設。
風險資訊也會影響最小商業增量（Minimum Business Increment，MBI）的切分方式。團隊不需要等到完整功能完成後才驗證風險。當最小範圍的交付已經能驗證關鍵假設時，就可以先交付較小範圍，取得使用回饋與技術證據。
在產品待辦清單精煉（Backlog Refinement）時，團隊可以重新檢查每個高風險項目的狀態。已經透過測試、原型或小批量交付降低的風險，可以調整標記或移出風險清單。仍缺少證據的風險，則需要補上驗證工作或升級討論。
這種做法會讓風險策略從紙上談兵進入實際工作排序。團隊在選擇下一批工作時，能夠同時看到價值、風險、相依性與驗證需求。
透過里程碑與檢查點重新評估風險
風險狀態會隨著專案進展改變，因此團隊需要透過里程碑與檢查點重新評估風險。
在利害關係人願景（Stakeholder Vision）里程碑，團隊需要確認是否已理解目前面對的風險，也需要確認是否具備可行的回應策略。
這個檢查很重要，因為團隊若尚未看清主要風險，就直接進入大量建構工作，後續調整成本將會大幅提高。
進入建構（Construction）階段後，應在早期通過證明架構可行（Architecture Proven）里程碑，確認核心架構能控制高風險項目。
之後每一次前進判斷，都需要納入目前的風險水準。
團隊可以在迭代規劃、交付規劃會議（Delivery Planning Meeting）、發布前檢查或架構檢查時，重新確認風險是否下降、是否轉移，以及是否需要新增回應方式。
以上線前檢查為例，團隊可以重新確認三件事：高風險項目是否已完成驗證、風險門檻是否被觸發，以及發生事故時是否具備明確的回復與通報方式。
只要其中一項仍缺少證據，團隊就需要補上驗證、調整發布範圍，或請合適角色參與判斷。
利害關係人準備度也需要一起檢查。風險不只來自技術，也可能來自訓練、營運流程、法務確認或管理層決策。當這些條件尚未準備好，團隊可以將其視為風險項目，納入交付計畫持續追蹤。
結語：選擇風險策略（Choose Risk Strategy）讓風險討論進入日常決策
選擇風險策略（Choose Risk Strategy）的價值，在於讓風險從抽象提醒轉為具體決策依據。
Disciplined Agile（DA）將風險視為會影響目標的不確定事件或條件。這些不確定性可能帶來威脅，也可能帶來機會。團隊在專案早期說清楚風險承受能力、風險態度、風險門檻與高風險工作的處理方式，後續規劃就能有清楚的判斷依據。
風險策略也需要進入日常工作。產品待辦清單排序、架構技術試驗、供應商聯測、里程碑檢查與上線前確認，都可以成為團隊處理風險的具體位置。
風險策略需要同時處理威脅與機會
風險策略需要同時處理威脅與機會。
威脅需要被降低、轉移、監控或升級。機會則需要被辨識、評估與保留行動空間。
團隊如果只把風險理解為負面因素，就可能錯過新技術、新市場或新交付方式帶來的價值。
選擇風險策略會協助團隊回答幾個基本問題：哪些不確定性值得主動承擔，哪些風險需要先降低曝險，哪些情況一旦超過門檻就需要引入外部角色。
這些答案會影響團隊如何排序工作、安排驗證、拆分交付範圍，以及何時讓管理者或治理角色參與判斷。
風險需要在整個生命週期中被辨識、評估與處理。當團隊把風險納入產品待辦清單、交付規劃與檢查點，風險討論才會進入實際工作安排。
團隊下一步可以從三個問題開始
團隊可以從三個問題開始，把選擇風險策略帶回日常工作。
- 目前最需要提早看見的風險是什麼。
這會協助團隊找出需要安排架構技術試驗（Spike）、概念驗證（Proof of Concept，PoC）、供應商聯測或資料試轉的工作。 - 組織願意承擔風險到什麼程度。
這會連回風險承受能力（Risk Appetite）與風險態度（Risk Attitude），協助團隊判斷哪些風險可以主動承擔，哪些風險需要補上驗證與治理參與。 - 哪些門檻一旦被觸發就需要調整計畫。
這會連回風險門檻（Risk Threshold），協助團隊事先說清楚何時需要升級、暫停、縮小範圍或重新規劃。
這三個問題可以放進專案啟動會議、交付規劃會議、產品待辦清單精煉或上線前檢查。
團隊每次回答時，便能把風險策略連回當前工作，讓風險討論隨著工作的推展一起更新。
