Scrum 建立在經驗主義（Empiricism）之上，團隊透過透明（Transparency）、檢視（Inspection）與調適（Adaptation），反覆確認目前的做法能否帶來預期成果。這套運作方式仰賴團隊對目標、工作範圍與完成狀態建立共同理解，也仰賴固定節奏讓問題及早被看見。
AI 讓程式、測試與文件可以在更短時間內出現，原有流程中的模糊處也會提早造成影響。需求拆解不清、待辦事項缺乏驗收條件（Acceptance Criteria，AC）、完成定義（Definition of Done, DoD）過於寬鬆，過去可能要經過幾天才會暴露問題，現在幾個小時內就可能被寫進大量內容。
短衝規劃（Sprint Planning）需要團隊根據產品目標、工作複雜度、可用能力與過往經驗，判斷這個短衝（Sprint）能完成哪些工作。AI 加入開發流程後，團隊容易直接調降程式撰寫時間的估算，認為過去需要三天完成的功能，現在半天就能完成。
這類估算只計入程式生成速度。需求確認、方案討論、環境設定、資料準備、程式碼審查、整合測試與使用者驗證，仍需要團隊投入時間。AI 快速產生第一版內容，也會增加需要確認的假設，包括例外情境是否完整、既有資料是否相容，以及實作是否符合系統限制。
當團隊依照 AI 的生成速度安排短衝，計畫容易放入過多工作。開發者很快完成程式草稿，工作隨後堆積在審查、測試與驗收階段。短衝後半段會出現大量等待與返工，團隊看到的完成比例也會偏離真實的可交付狀態。
短衝規劃需要重新檢視團隊的完整交付能力。估算應涵蓋理解、生成、驗證、整合與回饋所需的時間，也要參考過去符合完成定義的工作量。AI 帶來的速度變化，可以透過多個短衝的交付資料進行校準，避免直接將工具宣傳或個人感受換算成團隊承諾。
AI 能在短時間內提出功能建議、技術方案、錯誤情境、測試案例與改善項目。這些內容容易被直接加入產品待辦清單（Product Backlog），讓待辦清單看起來更豐富完整，也讓團隊擁有更多可選工作。
每一項 AI 建議仍需要確認來源與價值。部分項目來自 AI 對模糊需求的自行補充，部分項目只代表技術上可以執行，未必對應實際的使用者問題。當這些候選想法未經篩選便進入產品待辦清單，產品負責人（Product Owner, PO）就需要投入更多時間閱讀、分類、合併與排序。
產品待辦清單膨脹也會降低透明度。重要的使用者需求可能被大量技術改善、延伸功能與自動生成的邊界案例淹沒。團隊在產品待辦清單精煉（Product Backlog Refinement）時需要處理更多項目，也難以清楚說明哪些工作直接支援產品目標，哪些仍是尚未驗證的想法。
AI 產出的項目適合先放入候選區域，並標示產生背景、待驗證假設與預期成果。項目經過產品判斷、使用者回饋或技術風險分析後，再進入正式產品待辦清單。這樣能保留 AI 協助探索的空間，也能讓產品待辦清單維持可理解、可排序與可行動的狀態。
AI 能快速增加提交次數、程式碼量、測試數量與完成任務數。這些數字容易形成速度提升的印象，也可能被用來評估個人或團隊的工作成果。當管理者與 Scrum 團隊過度依賴活動量，短衝便會被推向「多完成幾項」的方向。
交付能力涵蓋從需求理解到成果實際被使用的完整過程。程式生成完成後，還要經過測試、整合、部署與使用者驗證。功能若未能解決預期問題，或上線後增加支援與修正工作，先前增加的產出量就只是在流程中製造更多待處理項目。
這類誤判也會改變團隊行為。開發者可能傾向拆出更多容易完成的小任務，產品負責人可能繼續加入功能，短衝展示（Sprint Review）也可能變成逐項展示產出。團隊因此缺少機會確認這些變更是否有改善使用者行為、降低營運成本，或推進原先設定的短衝目標（Sprint Goal）。
Scrum 團隊需要把觀察焦點放回可用增量（Increment）與實際成果。完成多少程式碼、產生多少測試，可以作為理解工作量的輔助資料。能否符合完成定義、縮短回饋時間、降低返工，並讓短衝目標取得可驗證的進展，才是反映整體交付能力。
AI 工具多半以個人介面運作。開發者會在自己的編輯器、聊天視窗或終端機中描述需求、補充背景、比較方案，再請 AI 產生程式與測試。工作可以向前推進得更快，需求理解與技術判斷卻可能只留在操作紀錄中。
Scrum 依賴團隊共同承擔短衝目標（Sprint Goal）。成員需要知道目前要解決什麼問題、採用哪些做法，以及哪些風險仍待處理。當工作背景只存在個人與 AI 的對話裡，其他成員多半要等到程式提交後才能看到結果。團隊收到完成品時，常已經錯過需求被解讀、方案被選擇與風險被判斷的過程。
開發者使用 AI 時，會持續補充需求細節，包括既有流程、例外狀況、資料格式與使用者限制。經過多輪對話後，AI 才能產生較符合情境的內容。這些補充資訊也反映開發者如何理解需求，並包含許多尚未寫進待辦事項的假設。
若這段對話只保留在個人工具中，產品負責人和其他團隊成員就無法確認 AI 收到哪些背景。相同的待辦事項交給不同成員處理，也可能因各自補充不同假設而得到不同結果。等到程式完成，需求理解上的差異已經被寫進程式結構與測試案例。
需求討論需要留下可共享的結果。團隊不必保存所有聊天內容，可以整理出重要規則、範例、未確認問題與驗收條件，再放回產品待辦清單項目（Product Backlog Item）、活文件或行為規格。如此下一位使用 AI 的成員，才會拿到相同的需求基準。
AI 可以快速提出多種技術做法，開發者也能在短時間內比較流程、資料結構、API 設計與錯誤處理方式。當開發者直接選擇其中一個方案並完成實作，技術決策速度會提高，團隊參與判斷的機會也可能減少。
部分技術取捨會影響模組責任、資料邊界、部署方式與後續維護成本。這些影響未必會在單一功能中立即出現。個人與 AI 的對話若只聚焦目前任務，容易採用局部合理的方案，其他成員也難以得知當時比較過哪些選項，以及放棄其他方案的原因。
團隊可以依照決策影響範圍建立簡單門檻。局部命名與小範圍實作可由開發者自行處理。牽涉共用介面、資料模型、外部依賴與架構邊界的變更，需要進入共同設計、架構決策紀錄（Architecture Decision Records, ADR）或拉取請求（Pull Request, PR）討論。AI 提出的建議可以作為討論素材，最後的取捨理由仍需要由團隊清楚決策。
程式碼審查（Code Review）多半發生在解法已經成形之後。審查者能看到最後的程式與測試，卻看不到開發者曾嘗試哪些方向、AI 提供過哪些錯誤建議，以及哪些需求假設曾經調整。這些探索過程若沒有留下紀錄，審查只能從結果反推設計意圖。
AI 也可能經過多次修正，才產生目前的版本。某個看似多餘的判斷，可能是為了處理先前發現的失敗案例。某個特殊資料轉換，也可能來自既有系統限制。缺少這些背景時，審查者需要重新探索一次，或在不了解原因的情況下接受變更，審查的認知負擔也會增加。
團隊可以要求變更附上簡短的解法說明，內容包括需求目標、採用方案、重要限制、已驗證風險與仍待確認事項。大型或高風險變更也可以保留關鍵提示詞、測試失敗紀錄或方案比較。審查者有了這些線索，就能把時間放在判斷方案是否合理，不必從程式碼重新猜測整段設計過程。
當 AI 能快速做出功能，團隊容易用可執行結果取代討論。畫面可以操作、測試已通過、程式也已提交，便被視為團隊已經理解需求與方案。這種共識可能只停留在表面，成員對功能目標、設計理由與風險範圍仍有不同理解。
這些差異會在後續修改時浮現。另一位成員接手功能後，可能依照自己的理解調整程式。產品負責人在短衝展示看到結果時，才會發現功能行為與原先期待不符。前期省下的對話時間，後續會轉成返工、補文件與重新確認。
Scrum 團隊需要把共同理解納入工作成果。重要需求要經過實例映射（Example Mapping）的範例確認，技術取捨要留下必要紀錄，AI 產出也要拆成可討論的小批次，讓團隊能在結果定型前修正方向。最終產出只能證明工作已經完成，接手者還需要知道當初為什麼這樣做。
Scrum 事件用來建立固定的檢視與調整節奏。團隊透過短衝規劃對齊目標，透過每日立會（Daily Scrum）同步工作進展，透過短衝展示驗證增量，並在短衝自省會議（Sprint Retrospective）改善合作方式。這些事件需要讓真實工作進入討論，才有機會協助團隊調整方向。
AI 讓個人手上的任務變多後，Scrum 事件容易被產出清單占滿。會議時間被用來說明完成多少工作、產生多少程式碼，以及還有多少任務等待處理。事件看起來照常進行，討論內容卻開始偏離短衝目標、使用者回饋與團隊協作。
每日立會原先用來檢查團隊朝短衝目標前進的狀況，並為接下來的 24 小時制定計劃。成員需要共同確認目前計畫是否仍然合理、哪些工作彼此依賴，以及接下來一天要如何調整合作方式。
AI 能快速拆解與完成任務後，每位成員手上的活動數量容易增加。每日立會可能因此變成逐人回報任務，例如生成幾支程式、補了多少測試，以及準備開始哪些新項目。會議時間被大量細節占據，成員也難以從眾多活動中看出整體進展。
這種運作方式會讓團隊誤判工作狀態。某位開發者可能已經產生數個功能草稿，這些內容仍等待需求確認、審查或整合測試。若只看個人完成的活動，團隊會覺得進度順利，實際價值流可能已經堵在後段流程。
每日立會可以把討論焦點放回短衝目標與工作流動。團隊需要說清楚哪些工作已經形成可驗證增量，哪些項目卡在確認、審查或測試，以及今天需要哪些成員共同處理。個人與 AI 的互動可以作為背景資訊，會議主要用途是調整接下來一天的合作方式。
短衝展示用來確認這個短衝產生的增量，並與利害關係人共同判斷目前的產品方向。團隊需要觀察哪些假設已經得到驗證、使用者如何回應，以及產品待辦清單接下來應該如何調整。
功能生成速度提高後，團隊可能在一個短衝內完成更多畫面、流程與技術項目。短衝展示容易變成只有逐項展示成果，團隊依序說明新增哪些功能、修改哪些介面，以及 AI 協助完成多少工作。在時間盒的限制下，展示內容增加後，留給回饋與討論的時間就會減少。
產出清單也可能掩蓋增量的實際完成狀態。某些功能可能只完成主要流程，例外處理、資料相容與營運支援仍未準備。利害關係人看到畫面已經可以操作，可能因此認為功能接近上線，團隊對完成狀態的理解也會出現差距。
短衝展示需要圍繞產品目標與驗證結果安排內容。團隊可以說明這次增量解決了哪些問題、取得哪些使用者回饋，以及哪些假設仍待確認。AI 產生的功能數量可以留下紀錄，展示現場要判斷的是產品成果是否真的帶來價值。
短衝自省會議用來回顧團隊的工作方式，包括合作關係、流程、工具與完成定義。團隊需要從這個短衝的經驗中找出可改善之處，並選擇少量行動帶入下一個短衝。
當大量工作發生在個人與 AI 的對話中，回顧會少掉許多關鍵線索。需求假設何時被補上、技術方案如何選擇、AI 產出經過幾次修正，以及哪些錯誤由個人自行處理，這些資訊都可能沒有進入團隊視野。
短衝自省會議若只依據任務完成率、速度或缺陷數量進行回顧，團隊很難辨識協作斷點。某項功能最後順利完成，過程中仍可能發生多次需求誤解與重複探索。這些成本若沒有留下紀錄，團隊便容易將結果視為流程正常。
團隊需要在回顧中加入 AI 使用方式的觀察，例如哪些重要背景只留在個人對話、哪些變更太晚進入審查，以及哪些工作因生成量過大而卡在驗證階段。後續行動可以落在提示詞分享、共同設計、變更批次與完成定義調整。
Scrum 事件能否發揮作用，取決於團隊是否願意把真實工作帶進共同討論。AI 產出速度提高後，事件要檢查目標、理解與回饋，避免固定節奏只剩形式上的進度回報。
產品負責人會更常面對產品待辦清單快速膨脹的問題。AI 可以在短時間內提出大量功能想法、例外情境與延伸需求，產品負責人需要判斷哪些內容值得進入待辦清單，並提早把需求範圍與限制條件寫清楚。
AI 可以協助產品負責人整理使用者故事（User Stories）與驗收條件。產品負責人可以先提供使用者目標、業務規則、限制條件與已知例外，再請 AI 找出缺少的情境、整理驗收條件，或把模糊描述改寫成可驗證的行為。
提示詞（Prompt）也會成為需求控制的一部分。產品負責人可以在提示詞中明確指定角色、使用情境、業務規則、限制條件，以及哪些內容不得由 AI 自行補充，減少需求被任意延伸。這些限制也能協助團隊提早找出規格中尚未確認的問題。
AI 產生的使用者故事與驗收條件仍需要由產品負責人、團隊與相關利害關係人共同確認。確認後的內容應回到產品待辦清單，讓後續使用 AI 的成員取得一致的需求背景，也讓需求決策與修改原因保留在團隊共同使用的工作流程中。
Scrum Master（SM）需要重新觀察團隊的阻礙（Blockers）。AI 提高個人產出速度後，開發速率（Velocity）、完成的故事點數（Story Point）與工作項目數量都可能快速上升，這些數字已不足以單獨判斷團隊的交付是否順暢。
Scrum Master 可以把注意力放在工作停留的位置。例如大量拉取請求是否卡在審查、測試環境是否開始排隊、同一項需求是否因 AI 產生不同理解，以及重要背景是否只留在某位成員的 AI 對話中。
這些問題會形成新的溝通障礙與驗證瓶頸。開發速度提高後，審查、測試、需求確認與跨角色溝通若無法承接新增的工作量，工作就會堆積在流程後段。Scrum Master 需要協助團隊辨識阻塞位置，釐清形成原因，並把改善行動帶回短衝的工作方式。
短衝自省也可以加入這類觀察。團隊可以回顧哪些工作因 AI 加快、哪些階段開始出現等待、哪些資訊沒有順利傳遞，以及哪些工作因需求理解不同而反覆修改。Scrum Master 的關注範圍也因此延伸到整條價值流，持續觀察 AI 對協作、驗證與交付節奏造成的影響。
開發者的工作會從大量親自撰寫程式碼，轉向系統設計、審查與驗證。AI 可以快速完成程式碼撰寫、測試草稿、資料轉換與部分重構，開發者需要把更多時間放在需求意圖、架構邊界、資料正確性、例外流程與安全風險的判斷。
審查者（Reviewer）與驗證者（Validator）的能力也會被更頻繁地使用。開發者需要讀懂 AI 修改了哪些內容，確認變更是否符合系統設計，再透過測試、靜態分析與實際執行結果驗證行為。當 AI 一次修改多個檔案時，也需要檢查變更範圍是否超出原先任務，避免額外修改一起混入。
系統設計能力也會占據更多工作時間。AI 可以快速提出多種實作方案，開發者需要判斷方案是否符合既有架構、引入的新依賴是否合理，以及這些修改會不會增加後續維護與理解成本。
程式碼撰寫仍是開發工作的一部分，只不過投入時間的比例會改變。開發者會把更多時間放在設計、審查、驗證與控制修改方向，角色也會更接近系統設計者、審查者與驗證者。
完成定義用來說明一項工作達到哪些條件，才能成為可用增量的一部分。它多半涵蓋程式完成、測試通過、程式碼審查、文件更新、安全檢查與部署準備。團隊透過共同標準，建立對「完成」的一致理解。
AI 加快程式與測試的產生速度後，工作會更早進入完成狀態的判斷。開發者在短時間內產生多個變更，容易將「內容已生成」視為接近完成。需求行為、整合結果、錯誤處理與正式環境影響還沒確認時，這些變更只是在等待下一關檢查。
產出外觀看起來完整時，開發者可能認為工作已符合完成定義，接著將項目移到完成欄位或提出拉取請求。部分檢查也可能只停留在程式能編譯、單元測試能執行，以及主要流程可以操作。
完成定義多半還包含跨模組整合、例外情境、資料相容、安全掃描、文件更新與部署驗證。AI 未必知道團隊所有隱性規則，也未必掌握正式環境中的資料狀態與營運限制。完成定義若沒有轉成清楚規則，生成內容就可能通過局部檢查，風險則留到後續流程處理。
團隊可以把完成定義轉成可執行檢查。例如在持續整合（Continuous Integration, CI）流程中加入靜態分析、安全掃描、契約測試與測試覆蓋檢查。在拉取請求範本中要求說明需求依據、影響範圍與驗證結果。AI 使用聲明也可以納入變更紀錄，讓審查者知道哪些內容需要投入更多注意力。
完成定義也需要配合 AI 使用情境調整。團隊可以增加生成內容的驗證要求，例如由開發者說明關鍵邏輯、確認測試案例涵蓋需求行為，以及確認提示詞中的假設已經回到需求或文件。這些條件能讓完成狀態更貼近可交付品質。
前段產出加快後，更多工作會在短時間內進入程式碼審查、測試與驗收流程。團隊若沒有調整後段處理能力，待審查與待驗證項目就會開始排隊。看板上可能出現大量「開發完成」的在製品（Work in Progress, WIP），符合完成定義的任務仍然有限，反而讓任務的週期時間（Cycle Time）變得更長。
審查壓力增加時，審查者容易先處理容易理解的小型變更，大型或高風險內容則需要等待更長時間。等待期間，開發者已經開始處理下一批工作，收到回饋後又要重新載入先前脈絡，需要付出極高成本重新喚醒上下文記憶。除了會增加工作切換成本，也會讓修正工作與新工作互相干擾。
測試流程也會受到相同影響。AI 可以快速生成大量測試，測試資料、整合環境、外部服務與人工驗收能力仍有固定容量。測試項目增加後，失敗訊號也跟著增加，團隊需要判斷錯誤來自產品程式、測試實作、環境狀態或需求假設。
團隊需要限制同時進入驗證流程的工作量，並把變更拆成較小批次。開發者完成一段可檢查的內容後，就讓審查與測試提早介入。低風險檢查可以交由自動化處理，高風險邏輯與架構影響則保留人工判斷。短衝後半段才不會集中處理一整批難以消化的變更。
Scrum 要求每個短衝（Sprint）產生具備使用價值的增量。AI 介入後，增量除了符合既有品質標準，也需要檢查生成過程帶來的風險，包括需求假設是否正確、生成內容是否引用不適合的套件、敏感資料是否進入提示詞，以及程式是否產生未預期的外部操作。
不同變更需要不同程度的檢查。一般介面調整可以沿用既有測試與審查流程。涉及權限、付款、個人資料、法規或核心營運規則的功能，則需要加入更嚴格的人工審查、安全測試與發布控制。團隊也要確認 AI 是否改動共用模組、資料結構與系統契約，避免局部功能通過測試後影響其他服務。
AI 風險檢查可以納入完成定義。團隊可要求高風險變更留下提示詞摘要、人工決策紀錄、測試證據與回退方式。若使用 AI 產生資料遷移、部署腳本或基礎設施設定，也需要先在隔離環境中演練，並確認失敗時能恢復到安全狀態。
可交付增量代表團隊願意共同承擔品質與後果。AI 能協助完成大量工作，品質責任仍需要由 Scrum 團隊承擔。完成定義提供共同門檻，風險檢查則補上生成過程帶來的新變數，讓每個短衝產生的增量具備可使用、可理解與可維護的條件。
個人與 AI 的對話常包含需求解讀、方案比較、錯誤修正與測試結果。這些內容若只留在個人帳號或本機工具中，其他成員只能看到最後提交的結果，也很難理解解法形成時經過哪些判斷。
Scrum 團隊可以重新檢查各項事件、文件與完成定義，確認它們是否有助於建立共同理解。AI 加入工作流程後，原本會在需求討論、共同設計、程式碼審查或測試過程中被說明的資訊，有一部分進入提示詞、AI 代理人（AI Agent）指令與個人工具設定。團隊需要把會影響後續工作的內容帶回共同討論。
團隊可以先定義哪些 AI 使用資訊值得分享。一般語法查詢或局部重構不需要保留完整紀錄，牽涉需求假設、架構取捨、資料模型、外部套件與高風險邏輯時，開發者應整理關鍵背景、採用理由與尚未確認的問題。這些內容可以在產品待辦清單精煉、共同設計、每日立會或拉取請求審查中提出，讓其他成員補充脈絡並檢查假設。
共用提示詞（Shared Prompts）、自訂指令（Custom Instructions）與專案層級的上下文規則檔案（Context Files），也可以支援這類共同協作。團隊在討論架構規範、測試要求與完成定義時，可以把已形成共識的內容整理進共用設定，讓不同成員在個人端使用 AI 時取得相同的基本背景。這些設定也需要隨後續討論繼續檢查與調整。
例如，團隊在審查中發現成員對模組邊界有不同理解，可以先一起確認規則，再把結論補進專案級 AI 設定。下一次 AI 產生相關程式碼時，成員就能依照相同規則進行探索。後續若發現規則不適合目前情境，也可以再次回到團隊討論，避免個人私下調整提示詞後形成不同做法。
分享方式可以保持精簡。產品待辦清單項目可以補上新增的業務規則，拉取請求可以說明方案、限制與重要假設，架構決策紀錄則用來保存影響時間較長的設計決策。團隊需要留下足以支援討論與後續理解的資訊，不需要保存每一次 AI 對話。
這些做法能讓 AI 探索過程回到團隊視野。成員可以看見彼此如何理解需求、如何選擇方案，以及哪些問題仍待確認。個人使用 AI 的效率可以保留，重要判斷也會回到 Scrum Team 的共同檢視與學習中。
AI 能快速完成多個功能草稿，短衝規劃容易因此加入過多工作。當短衝目標只描述要完成哪些功能，討論會被項目數量與產出速度牽著走，也會忽略這次短衝希望確認的產品成果。
短衝目標需要更清楚描述需要驗證的改變，例如確認使用者能否用較少步驟完成申請、驗證新的審核規則能否降低人工處理量，或確認某項技術方案能否承受預期流量。這類目標能幫助團隊判斷哪些 AI 產出值得投入後續驗證。
當生成結果偏離短衝目標，團隊可以提早停止延伸。某個功能即使已經產生完整程式，只要無法協助驗證本次目標，就不需要急著納入增量。產品負責人也能依照驗證結果調整產品待辦清單，避免尚未確認價值的功能繼續擴大。
短衝展示應回到成果與證據。團隊可以展示功能、測試結果、使用者行為與營運資料，並與利害關係人共同判斷目標是否取得進展。AI 完成多少工作只作為背景資訊，後續調整仍應依照已驗證的產品結果進行。
AI 常能一次產生完整模組、數十個測試或大範圍重構。大型變更會增加審查者的理解負擔，也會讓需求錯誤與設計問題延後到整批內容完成後才被發現。
團隊可以要求 AI 依照可驗證的工作切片產生內容。先建立一條主要流程，再補上例外情境。先完成介面契約，再進行內部實作。先提交資料結構調整，再加入使用該結構的功能。每個批次都需要有清楚目的與檢查方式。
小批次能讓程式碼審查提早介入。審查者可以先確認需求理解、模組責任與依賴方向，開發者再沿著已確認的方向擴充。發現問題時，修改範圍也較容易控制，避免 AI 在錯誤基礎上產生更多內容。
團隊也要限制等待審查與測試的工作量。當驗證區域開始排隊，成員可以先協助審查、補測試或處理整合問題，再啟動下一批生成工作。看板上的重點會從「誰又開始新工作」轉向「哪些工作已經通過完整檢查」。
生成速度變快後，團隊容易把開發起點當成工作節奏。每位成員不斷開啟新任務、提出新方案與產生新程式，審查、測試與使用者驗證則處理前面累積的內容。
Scrum 的節奏可以圍繞回饋點重新安排。開發者完成一個小批次後，立即進入自動化測試、程式碼審查與需求確認。高風險功能也可以提早安排安全檢查、整合驗證與小範圍試用，讓問題在短衝內被看見並處理。
短衝展示提供利害關係人的產品回饋，短衝自省會議則檢查團隊如何使用 AI、哪些資訊沒有共享，以及哪些工作長時間停在驗證階段。這些觀察需要轉成下一個短衝可執行的調整，例如縮小變更批次、增加共同設計，或補強完成定義。
當回饋成為團隊的工作節奏，AI 產出就能更早接受檢查與修正。Scrum 團隊也能從每次生成、驗證與調整中整理共同經驗，建立符合產品、技術與風險條件的 AI 協作方式。
iThome鐵人賽
看影片追技術