Disciplined Agile（DA）的發布驗證（Validate Release），需要確認部署內容符合預期、新版本已提供給預定使用者，以及使用者對更新的感受。
團隊可依部署風險、環境限制與回饋需求，搭配正式環境部署測試、直接交流、使用量測與滿意度調查，並考量蒐集成本、效能負擔與樣本偏差。
省略驗證可能延遲發現問題，發布前應約定檢查項目、時間與負責人，發布後保留結果，追蹤異常的修正與重驗結果，並將漏掉的檢查補入下一次發布安排。
發布驗證（Validate Release）的範圍與判斷依據
從部署解決方案銜接到發布後的確認
Disciplined Agile（DA）的部署解決方案（Deploy the Solution）目標，提供將解決方案發布至正式環境時可採用的策略與活動，涵蓋部署自動化、發布方式與結果確認。
其中，發布驗證（Validate Release）這個決策點，處理的是團隊要如何確認這次發布達到預期結果。
以購物網站更新結帳功能為例，部署程序完成後，工程師可以先確認新版本是否已安裝到預定的服務，再檢查功能是否開放給這次預定使用的會員。如果結帳頁面已更新，付款服務仍停留在舊版本，使用者就可能在送出訂單時遇到錯誤，發布後的檢查就該找出這類更新遺漏。
除此之外，驗證範圍還包括使用者的操作與感受。會員能否進入新版結帳頁面、是否順利完成付款，以及對操作方式是否滿意，都需要取得對應的證據。
DA 建議團隊依發布內容與使用情境選擇驗證做法，例如先核對結帳功能的部署結果，再觀察交易紀錄，並邀請實際使用新版功能的會員提供回饋。
部署內容、使用對象與滿意度的驗證證據
發布成功的判斷需要對應明確的驗證範圍。團隊可以從部署內容、使用對象與滿意度三個面向整理證據，分別確認系統更新了哪些內容、誰能使用，以及使用後的感受。
部署內容的確認，要核對實際更新與這次預定發布的範圍是否一致，包括應該更新的項目有沒有遺漏，並檢查是否混入預期外的變更。
例如這次預定更新結帳頁面與付款服務，就需要確認兩者的版本與必要設定，也要留意尚未準備開放的功能是否被一併啟用。部署紀錄與部署後的測試結果，可以用來核對這些項目。
使用對象的確認，則要檢查新版本是否已提供給預定的使用者。如果新版結帳功能透過功能旗標（Feature Flag）或金絲雀發布（Canary Release）只開放給特定會員，團隊需要確認這些會員能看到並操作新功能，其他會員仍維持原定的使用安排。
接著可以透過使用紀錄了解實際操作情況，例如會員登入成功後，還需要查看付款結果與訂單建立紀錄，才能確認結帳是否順利。
滿意度要從使用者對新版本的回饋判斷。交易完成的紀錄能顯示會員成功下單，操作過程是否令人困惑、是否願意再次使用，則可透過直接交流或調查了解。
例如會員順利完成付款，卻反映確認按鈕的位置難找，團隊就能進一步查看該操作步驟，確認是否需要調整畫面配置，並將問題列入後續迭代的修正或改善項目。
發布驗證的五個選項與取捨
正式環境部署測試：核對實際部署內容
正式環境部署測試（Production Deployment Testing）是在部署完成後執行自動化檢查，確認實際部署的內容符合預期，應更新的項目沒有遺漏，也沒有加入預定範圍之外的變更。
團隊可以將這些檢查接在部署程序之後，以在版本或設定出錯時留下明確的檢查結果。
例如購物網站這次預定更新結帳頁面與付款服務，測試可以核對兩者的版本、必要設定，以及服務之間能否正常連線。如果其中一項服務仍使用舊版，檢查結果就能指出需要處理的位置。
部署後的測試要對照這次發布的預期內容設計，例如結帳頁面可以開啟，付款服務也需要檢查是否完成更新。
運作環境會影響測試的執行難度。系統分布在多個環境時，執行測試與取得結果都會受到限制。系統若具備自我測試功能，就能在更新後檢查部分內部狀態，提供部署驗證所需的結果。
團隊仍需確認自我測試涵蓋哪些項目，例如內部元件檢查通過後，對外連線是否還需要另外驗證。
主動式利害關係人參與：直接了解使用經驗
主動式利害關係人參與（Active Stakeholder Participation）透過聯絡可能正在使用系統的人，了解他們是否已使用新版本，以及如何操作新功能。
聯絡時可以先確認對方是否接觸過這次更新，再請對方描述實際工作過程，確認回饋來自實際使用過新功能的人。
例如客服人員開始使用新版訂單查詢功能後，團隊可以請他示範如何找到一筆訂單、查看付款狀態，再回覆客戶。如果客服仍會另外開啟舊系統查詢，就追問新版是否缺少資訊、欄位是否難找，或客服是否尚未熟悉操作。
直接交流能補充操作紀錄未記載的細節，例如客服需要同時查看退款原因與付款時間，才能回答客戶的問題，光憑單純的操作紀錄並無法完整推敲出實際的使用情境。
為了讓訪談取得的內容豐富，蒐集與分析也需要投入時間。從邀約、安排操作示範，到整理不同人的說法，都需要有人負責。
團隊可以先聚焦這次變更影響的工作，請使用者示範一個完整情境，並在紀錄中保留卡住的步驟、當時需要的資訊，以及後來採用的處理方式。
使用量測：觀察正式環境中的操作結果
使用量測（Measure usage）透過系統運作時產生的資料，了解新版本是否被使用，以及使用後產生哪些結果。
量測內容可以包含商業數據指標，例如功能被呼叫的次數、商務系統產生的銷售金額，或使用者提交的資訊量。也可以觀察系統穩定性與效能指標，例如 API 回應延遲（Latency）或系統錯誤率（Error Rate），選擇時需配合功能用途。
以新版結帳為例，團隊可以觀察進入結帳頁面、送出付款與成功建立訂單的紀錄。如果進入頁面的人數增加，成功建立的訂單數量沒有相應增加，就可以進一步查看付款失敗或中斷的紀錄。
這些資料能呈現最新的使用情況，協助團隊找出需要追查的操作步驟。團隊也可以詢問使用者在該步驟遇到的困難。
量測需要在系統中加入資料蒐集機制，例如在付款完成時記錄結果。每次操作額外寫入資料或傳送紀錄，都可能增加處理負擔，因此需評估蒐集方式對效能的影響。
團隊可先確認哪些資料會用來判斷這次發布的結果，再檢查記錄頻率與內容，避免同一筆付款事件被重複記錄，或因紀錄過多拖慢結帳。
利害關係人滿意度調查：蒐集對新版本的評價
利害關係人滿意度調查（Stakeholder satisfaction survey）透過問卷，了解使用者對新版本的感受，也能為利害關係人滿意（Delighted Stakeholders）里程碑提供判斷依據。
問卷需要簡短、聚焦，讓填答者清楚知道正在評價哪項更新。例如新版查單功能發布後，可以針對這項功能詢問使用感受，讓回答與此次變更對應。
淨推薦分數（Net Promoter Score，NPS）使用的推薦意願問題，是可採用的提問方式之一。例如詢問「你有多大意願向同事推薦這項新功能？」，讓使用者從零分的完全不願意，到十分的非常願意之間選擇。
評分能呈現推薦意願，若要了解原因，可以再提供簡短的文字欄位，請使用者描述最希望調整的地方。之後判讀時需連同回答內容與使用情境一起查看。
問卷也有回覆不足與樣本偏差的問題。使用者可能覺得填寫麻煩，或在忙碌時直接忽略邀請。
團隊可以鎖定新版的活躍使用者、從使用資料中發現遇到問題的人，或過去曾回覆問卷的人，提高取得回覆的機會。這些邀請條件會影響樣本組成，例如集中邀請遇到問題的人，結果就會偏向這一群人的經驗。
滿意度結果需要連同受邀對象與回覆情況一起解讀，整理時應保留邀請條件、受邀人數與實際回覆人數。
不進行驗證：接受問題較晚被發現的風險
不進行驗證（None）代表團隊直接相信這次發布成功，省去額外安排測試、蒐集使用資料或詢問回饋的工作。
這個選項執行簡單，團隊也因此缺少主動確認發布結果的證據，正式環境的問題可能要等到使用者回報才會被發現。
例如新版訂單查詢功能已經部署完成，部分客服帳號卻因權限設定錯誤而無法使用。如果發布後沒有檢查這些帳號，錯誤就可能一直留到下一次客服交班時才被發現。在客服回報、工程師確認問題並修正設定之前，受影響的人需要改用其他方式查詢訂單，客戶也得繼續等待。
延後發現問題的這段時間，還可能讓更多使用者遇到相同錯誤。
依發布情境選擇驗證組合
依部署風險與環境限制安排檢查
選擇驗證組合時，可以先從這次變更出錯後會影響哪些操作開始。調整畫面文字時，可以聚焦畫面是否正確。同時更新結帳、付款及訂單服務時，就得確認服務間的版本、設定與交易流程。多個服務需要相互配合，任何一處版本或設定不一致，都可能讓交易中斷。
團隊需要先釐清這次更新涉及哪些服務，以及哪些操作一旦失敗，就會讓使用者無法完成工作。
以結帳流程更新為例，可以透過正式環境部署測試（Production Deployment Testing）核對各項服務的版本、設定與連線，再搭配使用量測（Measure usage）觀察付款與訂單建立的結果。
如果這次也改動了操作步驟，就可以邀請使用者回饋填寫資料或確認付款時遇到的困難。這幾項檢查能取得部署狀態、實際交易與操作經驗的證據，團隊應依本次變更調整檢查範圍。
運作環境也會限制能執行的檢查。例如系統分布在多個據點，部分設備只有特定時段能連線，團隊就需要分清楚哪些結果能立即取得，哪些需要等待設備回傳。
若設備具備自我測試功能時，可將回傳結果納入判斷，同時確認檢查涵蓋的元件與狀態。
尚未取得結果的項目，應保留為待確認事項。例如某據點尚未連線，就應記錄該據點的版本尚待核對，以及預計取得結果的時間。
依使用人數與回饋需求安排蒐集方式
使用人數與聯絡方式，會影響回饋蒐集所需的時間。只有十幾位客服使用的內部工具，可以透過主動式利害關係人參與（Active Stakeholder Participation），邀請負責不同業務的人操作新版功能。
例如新版訂單查詢畫面發布後，請處理一般訂單與退款案件的客服各示範一次工作過程，就能了解相同畫面是否提供了各自需要的資訊。
面向大量外部使用者的服務，若要逐一聯絡，會需要投入較多人力。團隊可以先查看使用資料，找出需要進一步了解的情境。
若新版結帳在選擇付款方式後出現較多中斷紀錄，就可以邀請曾在這個步驟中斷的使用者，了解當時發生什麼事。邀請時也可納入順利完成操作的人，確認不同使用經驗涉及的條件，例如裝置、付款方式或操作習慣。
需要蒐集使用者對新版本的整體評價時，可搭配利害關係人滿意度調查（Stakeholder satisfaction survey）。團隊可以透過直接訪談追問操作細節，也能用相同問卷題目蒐集不同人的評價。
選擇時還需考慮團隊是否有時間整理回答，以及使用者是否願意回覆。若問卷回覆有限，可以先縮小想了解的範圍，聚焦這次新增或調整的一項功能。
回饋來自哪些人，會限制結果能代表的範圍。內部工具若只邀請白天班客服，就需要補足夜間班的工作情境是否相同。外部服務若只收到活躍使用者的回答，也應記錄這項限制，另行了解曾嘗試新版功能，但後來停止使用的人。
整理回饋時，可以保留使用者類型、是否使用過新版本，以及受邀與實際回覆的人數。
將驗證工作納入發布安排
發布前約定檢查項目與負責人
驗證需要的測試、使用紀錄與回饋邀請，都可以在發布前準備好。
以結帳功能更新為例，團隊決定檢查付款與訂單建立的結果後，就需要確認系統是否會留下對應紀錄，以及誰能取得這些資料。發布後若才發現系統沒有記錄付款失敗原因，當次操作的細節就可能無法還原。
分工可以依團隊的人力與職責安排。例如工程師準備部署後的自動化檢查，產品人員與工程師一起確認要觀察的交易結果，熟悉使用者的客服或業務人員則協助邀請回饋。
每項工作都應指定能確認結果的人，並讓對方知道需要查看什麼。例如負責核對交易的人，要能確認付款成功後是否建立訂單，以及查看失敗時留下的可追查紀錄。
每項驗證都應約定檢查內容、確認時間、負責人與結果保存位置。部署內容可以在更新完成後立即檢查，實際使用情況需要在目標使用者開始操作後確認。若功能預定隔天早上開放給客服，就可以把操作回饋安排在該班次開始使用之後，並在發布紀錄中保留尚待確認的項目。
檢查結果也需要清楚的判讀條件。例如版本核對以預定版本為準，付款檢查則需確認交易結果與訂單狀態能對應。若資料不足以判斷，就記錄缺少哪些證據與下一次查看的時間。
發布前也應約定異常要通知誰，例如付款成功卻沒有訂單時，由誰接手查明交易狀態，並聯絡處理受影響訂單的人。
發布後記錄異常並安排後續處理
發布後，可以將部署檢查結果、使用資料與回饋連結整理在同一份版本紀錄中，註明各項結果的取得時間與涵蓋對象。
例如部署檢查在上午完成，客服到下午才開始使用新版功能，兩項驗證就應分別保留確認時間，讓查看紀錄的人知道哪些操作已經驗證，哪些仍在等待回饋。
如果部署測試通過後，使用紀錄出現結帳中斷，團隊可以先核對事件時間、使用版本、受影響對象與操作步驟，再查看相同條件下的其他交易。
假設中斷集中在某一種付款方式，就可沿著該付款流程查找錯誤紀錄，並詢問回報者停在哪個畫面。這些資訊應附在待處理事項中，讓接手的工程師能重現或追查問題。
確認影響範圍後，負責人需要安排修正與再次驗證。若問題已造成付款成功卻沒有訂單，處理時還需追查受影響的交易，確認哪些訂單需要補建或交由相關人員處理。
修正發布後，需要重新執行相關檢查，核對原先出錯的付款情境，並觀察後續交易是否仍出現相同異常。
驗證紀錄應保留異常、處理人與再次確認的結果。例如紀錄中可註明某種付款方式發生訂單建立失敗、由哪位工程師處理、修正版本為何，以及重新驗證後取得的交易結果。
尚未完成的受影響訂單處理，也應留下負責人與待辦事項，讓下一位接手者能沿著紀錄繼續查核。
結語：從下一次發布落實發布驗證（Validate Release）
選定一項功能建立驗證安排
要將發布驗證納入下一次發布，可以先選定一項使用者會直接操作的功能，寫下這次預定更新的內容、開放對象，以及發布後需要確認的使用結果。
例如新版結帳功能，可以從頁面與付款服務的版本核對開始，再確認預定會員能否使用，以及付款成功後是否建立訂單。
接著依團隊現有的測試、使用紀錄與聯絡管道，選擇能取得這些證據的做法，約定檢查時間與負責人。如果還需要了解操作感受，就安排使用者實際操作後提供回饋。
下一次發布前，先完成一項功能的驗證安排，讓每位負責人都能指出自己要檢查的項目，以及結果會保存在哪裡。
用一次發布的結果調整後續檢查
完成一次發布驗證後，可以回頭查看哪些問題被預定的檢查發現，哪些在使用者回報後才發現。
若結帳失敗的紀錄只有一個錯誤次數，工程師仍需反覆詢問使用者提供額外資訊才能查明原因，就可以把這次缺少的資訊列為下一版要補上的項目。
也要檢查蒐集的資料能否支持判斷。相同付款事件若被重複記錄，整理時就需額外排除，團隊可以確認重複來源，並且調整蒐集方式。
將這次發現的缺口寫成具體修改工作，例如補入付款失敗原因與發生步驟，並在下一次部署後檢查這些欄位是否正確留下紀錄。
- Release Strategy 發布策略：從 Disciplined Agile 看上線風險與部署選擇
- 發布至正式環境（Release Into Production）：資料處理、部署與失敗復原
- Deploy the Solution
