Disciplined Agile（DA）的檢視架構建議依序優先考慮利害關係人展示、非正式審查與正式審查，實際選擇仍需配合待解問題與治理要求。
向利害關係人進行展示透過可運作的軟體呈現使用者體驗與系統行為，內部分工與介面合約則適合用非正式審查討論。正式審查需預留文件閱讀與回饋時間，避免流於簽核，各種檢視方式也都應留意過度設計。
審查後，將尚未確認的技術假設轉成架構技術試驗，或把明確的預期行為寫入使用者故事的驗收條件，再依優先順序排入短衝，指定負責人並追蹤測試證據。
檢視架構在提早驗證架構可行性中的位置
從架構策略的疑問界定檢視範圍
假設團隊準備將訂單系統改用新的付款服務，就需要先決定付款請求如何送出、交易結果如何接收與保存，以及連線中斷時該如何處理。
這些安排構成架構策略的一部分，也就是各個系統如何分工、連接與處理失敗。若等到功能全部完成才發現付款結果無法正確回寫，訂單流程與相關測試都得跟著修改。
Disciplined Agile（DA）的提早驗證架構可行性（Prove Architecture Early）目標，就是協助團隊在開發早期確認架構策略能否成立。
新系統的第一個版本，或既有系統的重要改造，都需要提早處理風險較高的功能，例如付款逾時後的交易狀態確認。
檢視架構（Review the Architecture）是其中一個決策點，協助團隊決定是否邀請關鍵利害關係人檢視架構策略，以及如何取得回饋。
團隊可以根據要討論的問題與組織要求，選擇利害關係人展示、非正式審查或正式審查。
檢視範圍可以從一個尚未釐清的架構問題開始。以更換付款服務為例，團隊可以先畫出付款請求與交易結果的傳遞路徑，邀請熟悉相關系統的人員確認分工。
討論時再聚焦於逾時情境，釐清訂單系統沒有收到回應時，應由誰查詢付款結果，以及畫面要向使用者呈現什麼狀態。
將審查意見與技術驗證證據分別記錄
檢視架構能讓參與者提出設計疑點，協助團隊發現遺漏的情境。
當審查者看到付款逾時後可以重新操作，就可能指出重複扣款的風險。這項意見指出需要補強的處理流程，也帶出一項必須確認的技術假設：同一筆訂單再次送出付款請求時，付款服務能否辨認並避免重複執行。
審查中獲得認同的設計，仍需確認尚未經過測試的技術假設。架構圖與文件描述預期行為，團隊還需要透過實作取得執行證據。
驗證架構（Validate the Architecture）的工作，就是透過具體實作確認策略是否可行。例如團隊可以模擬付款已成功、訂單系統卻未收到回應的情境，再次送出請求，檢查交易紀錄與訂單狀態是否符合預期。
記錄檢視結果時，可以把審查意見與驗證結果分開寫清楚。「需防止逾時重試造成重複扣款」是審查提出的待處理問題，「已在指定的逾時與重試情境中確認只有一筆成功交易」則是測試後取得的證據。
若尚未完成測試，就需保留待驗證狀態，並寫明需要檢查的情境。
檢視架構的三種選項與回饋範圍
利害關係人展示：觀察可見的操作結果
利害關係人展示（Stakeholder demos）的進行方式接近一般功能展示，參與者包含具架構背景的利害關係人。
這種做法呼應敏捷重視可運作的軟體（Working Software）的精神，讓團隊透過實際操作溝通設計。利害關係人能直接觀察架構安排對使用者體驗（User Experience，UX）與系統行為的影響，並根據展示結果提出意見。
以付款服務改造為例，團隊可以展示使用者按下付款後的等待畫面、逾時提示，以及重新查詢付款結果的操作。具架構背景的參與者能從這些行為追問設計細節，例如訂單系統尚未取得付款結果時，畫面是否過早顯示交易失敗，讓使用者誤以為需要再次付款。這類回饋有助於檢查系統狀態與畫面呈現是否一致。
展示適合檢視可見的操作結果，系統內部的處理機制仍需另外確認。同一個「付款成功」畫面，背後可能採用不同的交易紀錄與通知方式。畫面操作提供的資訊有限，團隊還需要檢查重試時如何避免重複扣款，或付款成功後訂單狀態是否可靠地更新。
當檢視重點是內部系統分工與介面合約時，可以優先採用非正式審查（Informal Reviews），用流程草圖與介面說明直接討論設計。
例如檢視訂單系統與付款服務之間的應用程式介面（API）呼叫時，團隊可以沿著請求路徑，確認逾時（Timeout）後由誰查詢交易結果、哪些情況可以重試，以及各系統如何回報目前狀態。
這些問題可以在走查（Walkthrough）草圖時逐項討論並修改，尚未確認的行為再安排測試。
非正式審查：透過草圖走查取得回饋
非正式審查（Informal Reviews）可以從團隊現有的架構草圖、模型或簡短說明開始。
參與者一起進行走查，沿著設計內容逐步確認系統如何運作。團隊可以站在貼有草圖的牆面前討論，也可以用簡短簡報說明一段流程，只需準備足以說明問題的材料。
例如工程師在白板上畫出訂單系統、付款服務與交易紀錄的關係，再沿著一次付款請求說明資料如何傳遞。審查者可以在不清楚的地方停下來，確認付款結果由誰保存、哪個系統負責重試，以及連線中斷後如何查詢交易狀態。參與者能直接指出流程中缺少的處理步驟，團隊也能當場修改草圖。
非正式審查的回饋速度取決於參與者能否及時加入。相關人員就在現場時，可以當場討論並取得意見。如果需要另一個團隊的工程師或架構師參與，仍得協調時間。
即使只準備一張草圖，也要確認對方何時能檢視，避免設計已經開始實作，關鍵意見才送回來。
正式審查：預先閱讀文件再集中討論
正式審查（Formal Reviews）需要團隊先準備架構文件或模型，交給審查者閱讀，並預留整理意見的時間。
回饋可以透過不同形式提供，其中一種做法是召開正式會議，由審查者與團隊逐項討論。組織既有的治理程序也會影響文件格式與審查安排，團隊可能需要為此另外編寫材料。
文件準備、閱讀與會議協調都需要投入時間。若一份架構文件涵蓋訂單、付款、庫存與通知等多個子系統，審查者必須先理解彼此的關係，才能判斷某個設計是否遺漏重要情境。
文件內容過多，會增加審查者完整閱讀與逐項檢查的負擔。準備材料時，可以清楚標示這次需要檢視的範圍與待決問題，讓閱讀者知道應把注意力放在哪些段落。
正式審查的回饋週期可能跨越數週，團隊需要承擔文件準備與等待意見的成本。若付款介面送審後，工程師已依照原設計完成訂單狀態處理，稍後才收到調整系統分工的意見，就得回頭修改程式與測試。安排正式審查時，應確認回饋預計何時取得，以及哪些設計仍在等待決定。
正式審查也要避免流於簽核程序。團隊為了滿足組織治理要求，投入大量時間編寫厚重文件，審查者卻只確認格式與簽核欄位，沒有逐項討論技術風險。最後文件完成簽名，參與者對付實際的處理方式仍各有理解。
簽核時應留下已討論的風險、尚待驗證的假設與後續負責人。例如重複扣款風險尚未完成測試，就在審查紀錄中保留待驗證狀態與預計確認日期。
另一項需要留意的風險是過度設計（Over-engineering），也就是為了處理超出目前需求的情境，加入過多的設計與實作工作。
非正式審查或展示也可能出現這項風險，參與者提出少數邊際情境（Edge case），也就是發生頻率低的特殊狀況，團隊未先評估發生條件與影響，就將建議全部納入架構範圍。
例如原先只需串接一家付款服務，討論後卻擴大成支援多家服務自動切換，連帶增加交易狀態協調與測試工作，導致原定功能延後交付。
正式審查前，可以逐項確認新增設計對應的需求、風險與實作成本。對於發生機率低、後果卻嚴重的情境，團隊仍需安排處理。其餘情境可依影響程度排定後續工作。
例如多家付款服務切換尚無明確需求，就記錄未來需要重新評估的條件，並讓本次審查聚焦於現有付款流程必須處理的失敗情境。
| DA 建議優先順序 | 選項 | 適合取得的回饋 | 準備需求與回饋時間 | 主要限制 |
|---|---|---|---|---|
| 1（優先考慮） | 利害關係人展示 | 可見的操作結果與使用者體驗 | 準備可展示的操作情境，邀請具架構背景的利害關係人參與討論 | 無法充分檢視畫面背後的內部處理機制 |
| 2（優先考慮） | 非正式審查 | 架構草圖、模型與流程中的設計疑點 | 可用草圖或簡短說明開始，準備成本較低，可臨時討論，需協調審查者時則要等待排程 | 回饋速度受參與者時間影響，技術假設仍需實作驗證 |
| 3 | 正式審查 | 審查者預先閱讀架構文件或模型後提出的意見 | 需準備文件、安排閱讀與正式討論，投入成本較高，回饋可能跨越數週 | 文件龐雜會增加閱讀負擔，回饋延遲可能增加返工範圍 |
這個優先順序可作為選擇時的參考，團隊仍需依問題範圍與治理要求調整，可以直接選用符合需求的方式。例如要釐清系統內部的責任分工，可以直接安排草圖討論。組織要求正式審查時，則將文件準備與閱讀時間納入工作計畫。
依問題範圍與組織條件選擇檢視方式
先確認需要哪種回饋，再邀請合適的人
選擇檢視方式前，可以先用一句話寫出這次需要釐清的問題。
例如「付款結果尚未確認時，使用者能否理解目前狀態」，適合透過利害關係人展示（Stakeholder demos）觀察操作結果。若要討論「付款結果應由哪個系統負責查詢」，則可以從非正式審查（Informal Reviews）開始，用草圖說明系統分工，讓相關人員一起檢查流程。
參與者需要能回答這次檢視所涉及的問題。延續付款改造的例子，討論故障後如何查詢與補救時，可以邀請熟悉維運的人員，確認現有紀錄是否足以追查交易。若調整會改變另一個系統接收資料的方式，就需要請負責該系統的工程師參與，確認對方能否配合，以及有哪些使用限制。
團隊可以依待解問題調整參與者與材料，同一項改造也可能需要不同形式的回饋，例如先以草圖釐清系統責任，再展示操作結果，請具架構背景的利害關係人確認畫面呈現是否符合預期。
把等待回饋的時間納入修改成本
安排檢視時，需要先確認這項設計會影響哪些接下來的工作。若付款結果由哪個系統保存尚未決定，交易資料格式、查詢介面與錯誤處理都會受影響。當團隊依照暫定設計繼續開發，之後收到調整意見時，就得逐項檢查已完成的內容。
可以從預計開始實作的日期往前安排回饋時間。例如團隊下週要建立交易資料格式，就應提早邀請相關系統的負責人檢視。如果對方兩週後才有空，團隊需要說清楚等待期間哪些工作可以繼續、哪些工作會依賴尚未確認的決定。若選擇先做，也應保留暫定假設，讓參與開發的人知道哪些地方仍有修改空間。
選擇檢視方式時，要把取得意見之前已投入的工作一起算進去。即使會議只安排半小時，事前排程與文件閱讀仍可能耗費數週。若目前只需確認某項系統責任，例如付款逾時後由哪個系統來保存交易結果，可以先邀請相關負責人安排簡短討論，取得意見後，再依後續審查需求補上文件。
依治理要求安排必要文件與討論時點
組織若要求正式審查（Formal Reviews），團隊需要先確認適用範圍、指定材料與審查時點。
以付款服務改造為例，可以先向負責審查的人員確認，這次要提交整體架構說明，還是只需說明付款流程的變更，以及哪些決定需要在實作前完成審查。這些條件會直接影響文件準備與開發安排。
在組織程序允許的範圍內，團隊可以先用非正式討論釐清設計疑問，再整理正式審查所需的文件。例如付款逾時後由哪個系統查詢交易結果，若仍有不同看法，就先邀請相關工程師討論各自的處理能力與限制。文件再記錄選定的做法、選擇理由，以及尚待測試的情境，供審查者預先閱讀。
這些方式可依工作需要搭配使用，採用時仍需配合組織的審查程序。早期討論取得的意見，可以納入正式材料，尚未解決的分歧則應清楚列出。送出文件前，再確認審查者預計回覆的日期，以及需要哪些人參與後續討論。
將檢視意見轉成可追蹤的工作
檢視前準備情境、假設與待決事項
一次架構檢視可以從一段具體情境開始準備。
例如「使用者送出付款後，系統等待逾時，畫面仍無法確認交易結果」，就能界定這次要討論的範圍。
團隊可以附上付款流程圖，標示訂單系統與付款服務之間的請求、回應，以及沒有收到回應時預計採取的處理方式，讓審查者沿著同一段流程閱讀。
準備材料時，也要寫清楚設計依賴哪些假設。例如團隊預期付款服務能依訂單編號查詢交易結果，就應標示這項能力是否已經確認，以及目前有哪些文件或測試結果可供查看。如果還沒確認，就在流程圖旁註明待查，避免參與者直接以這項能力已經存在為前提討論。
待決事項要寫到審查者能指出缺少哪些資訊，或提出具體處理建議。將籠統的「請確認付款架構」具體寫成「付款結果未知時，應由哪個系統查詢交易狀態」。接著補上目前考慮的做法與限制，例如訂單系統可以發起查詢，但查詢頻率仍需與付款服務確認。參與者就能針對責任分配與使用限制提出意見。
這些準備方式可以依選用的檢視形式調整。展示時可附上操作情境與預期結果，草圖討論可直接標註假設與疑問，正式審查則把相關內容放入指定文件。
送出材料前，再確認圖中的系統名稱、流程步驟與待決事項能互相對應，讓審查者順利找到需要查看的位置。
檢視後指定修改與驗證工作的負責人
檢視中收到「逾時後能否再次付款」的意見時，可以先釐清這項意見涉及哪些工作。畫面提示需要說明交易尚未確認，設計文件需要交代再次操作的處理流程，測試則需要確認重試是否造成重複扣款。
這些工作可以分別建立待辦項目，並連回原本的審查意見，讓負責人知道修改的原因。
每項後續工作都應寫明負責人、處理期限與確認方式。
例如負責畫面的工程師更新逾時提示後，可用操作畫面確認文字與按鈕狀態。負責付款整合的工程師則需補上重試情境的測試，記錄實際產生的交易筆數與訂單狀態。若工作需要另一個團隊提供資料，也要指定由誰聯繫，以及預計何時取得回覆。
如果審查發現的技術假設還缺乏證據，可以建立架構技術試驗（Spike），以有時間限制的探索性任務確認可行性。
例如針對重複扣款風險，建立「確認付款逾時後重試的交易行為」任務，約定探索時間，模擬付款成功但回應遺失的情境，再以同一筆訂單重新送出請求。任務的預期產出可以包含重現步驟、交易紀錄、服務限制與建議做法。
探索結束後，即使假設未獲證實，也應記錄結果與下一步需要決定的事項。
當預期行為已經明確，就可以把審查意見寫入使用者故事（User Story）的驗收條件（Acceptance Criteria）。
例如在「使用者可查詢逾時付款的結果」這項故事中，寫明：「付款已成功但回應遺失時，使用者再次操作後，同一筆訂單仍只有一筆成功扣款，且訂單最終更新為已付款。」團隊可依此設計測試，並連結前述試驗取得的證據。
若試驗發現現有服務無法支援這個行為，就先調整處理方案，再確認故事的範圍與驗收條件。
將探索任務與故事排入短衝（Sprint）時，要一併確認依賴關係與驗證所需的時間。
團隊可以在下一個短衝的規劃中，依風險、優先順序與可用時間，選入需要處理的項目。如果實作方式仍取決於試驗結果，便先安排試驗，待結果明確後再確認後續實作能否納入。
在每日討論中，負責人可回報測試環境是否備妥、已取得哪些結果，以及還需要誰協助。短衝結束檢視成果時，則直接查看任務紀錄與故事驗收結果，確認重複扣款風險目前處理到哪一步。
完成狀態應依約定的確認方式更新。程式已修改且測試尚未執行時，可以註明目前進度與待驗證項目。若測試發現同一筆訂單仍會產生兩筆成功交易，就把結果附回待辦項目，交由負責人繼續處理，並記錄下一次需要重跑的情境。
下一次查看檢視結果時，就能沿著原始意見找到對應的文件、修改內容與測試紀錄。
若團隊決定暫不採用某項建議，也應留下原因與重新評估的條件。例如付款服務暫時無法支援所需的查詢方式，就記錄目前採取的處理安排，以及何時需要再次確認服務能力。
結語：從一個待決問題開始檢視架構
選定下一個需要取得回饋的架構決策
檢視架構（Review the Architecture）可以從手上正在開發的功能開始。挑出一項尚未定案、又會影響後續實作的設計，寫清楚希望取得什麼回饋，再邀請能協助判斷的人參與。
以付款改造為例，團隊可以把「付款逾時後由哪個系統確認交易結果」列為下一次討論題目，準備流程草圖與目前已知的服務限制。
選擇檢視方式時，就依這個問題需要的材料、參與者能提供回饋的時間，以及組織的審查要求安排。
可見的操作結果可以透過展示討論，系統分工可以從草圖開始，另有正式程序時則預留文件閱讀與審查時間。
先選定一個需要決定的問題，再約定取得回饋的時間。團隊可以在本週的工作安排中，直接寫下這次要討論的題目、參與者與預計討論日期。
把尚未確認的假設排入後續驗證
一次檢視結束後，逐項確認尚未解答的問題是否已有負責人，以及需要哪些證據才能判斷。
付款逾時後的處理方式即使已經取得共識，仍要安排重試測試，檢查同一筆訂單是否產生重複交易，以及訂單狀態能否正確更新。
把這些驗證工作放進接下來的工作安排，並約定查看結果的時間。若測試所需的環境或資料還沒備妥，就指定由誰準備，讓測試具備開始執行的條件。
下次查看這項架構決策時，帶上交易紀錄、測試結果與仍待處理的問題，再決定是否需要調整設計。
