在 GenAI 快速產出程式碼的時代，Scrum 團隊面臨更大的需求澄清與驗證挑戰。「Specification by Example（SBE）」不再只是測試技巧，而是一種讓需求、測試與實作同步對齊的策略。
本篇將深入探討 SBE 如何具體融入 Scrum 各個事件（Events）與活動（如 Backlog Refinement），透過真實範例與步驟，展現 SBE 的實用價值與潛在效益。

產品待辦清單梳理（Product Backlog Refinement）

(1) 角色與目的

• 參與角色：產品負責人（Product Owner）、Scrum 團隊（開發者、測試者）、Scrum Master、領域專家（視需要）。
• 目的：梳理產品待辦清單（Product Backlog）中的用戶故事（User Stories），確保故事清晰、可估計、可實現。SBE 在此用於將抽象的用戶故事轉為具體的例子，作為驗收標準（Acceptance Criteria）。

(2) 實例化需求如何搭配？
A. 做法：

• 在梳理會議中，針對每個用戶故事，團隊使用 SBE 撰寫 Given-When-Then 格式的範例，明確故事的業務規則和期望行為。
• 採用「三方會議」（Three Amigos）模式：產品負責人提供業務視角，開發者確認技術可行性，測試者確保範例可作為測試基礎。
• 範例涵蓋正常場景、邊界條件和異常情況，確保故事全面。
• 討論完畢後，將範例記錄在用戶故事的驗收標準中，存入工具（如 Jira）。

B. 步驟：

• 產品負責人介紹用戶故事（例如：「作為顧客，我希望結帳時得到折扣」）。
• 團隊討論並提出問題，澄清模糊點（如：「什麼條件觸發折扣？」）。
• 使用 SBE 撰寫範例，例如：

Given：購物車總額 1000 元，普通會員；
When：結帳；
Then：總額 900 元（10% 折扣）。

Given：購物車總額 500 元；
When：結帳；
Then：總額 500 元（無折扣）。

• 測試者確認範例是否可轉為自動化測試，開發者確認技術可行性。
• 將範例添加到用戶故事的驗收標準，產品負責人審核。

C. 工具：

• 協作工具：Miro（白板討論）、Google Docs（即時編輯）。
• 規格工具：Jira（記錄故事和驗收標準）、Cucumber（Gherkin 格式）。
• 文件工具：Confluence（存儲最後討論結果）。

D. 注意事項：

• 保持範例簡單，非技術人員也要能看懂。
• 避免過多範例，聚焦高價值場景。
• 確保所有角色參與，防止單方主導。
• 定期檢視規格庫，移除過時範例。

E. 效益

• 讓用戶故事更具體，減少 Sprint 內的誤解。
• 為後續的 Sprint 規劃和測試提供清晰的驗收標準。
• 促進跨角色協作，確保業務、技術和測試視角一致。

Sprint Planning

(1) 角色與目的

• 參與角色：產品負責人、Scrum 團隊、Scrum Master。
• 目的：決定當前 Sprint 要完成的用戶故事，並制定 Sprint 目標。SBE 在此用於確認選入的故事已準備好，並補充必要的範例。

(2) SBE 如何搭配？
A. 做法：

• 在 Sprint 規劃會議中，團隊回顧選入的用戶故事，檢查是否已有 SBE 範例作為驗收標準。
• 如果故事的範例不足（例如：缺少邊界或異常場景），現場補充或標記為待梳理。
• 開發者和測試者根據範例估計工作量，確保任務可實現。
• 將範例作為 Sprint 內開發和測試的參考，明確「完成定義」（Definition of Done）。

B. 步驟：

• 產品負責人介紹 Sprint 目標和選入的用戶故事。
• 團隊檢查每個故事的 SBE 範例，確認是否足夠清晰。
• 若範例不完整，快速討論並補充，例如：

Given：購物車總額 1000 元，VIP 會員；
When：結帳；
Then：總額 850 元（10% + 5% 折扣）。

• 開發者拆分任務，測試者確認範例可轉為測試用例。
• 將範例與任務關聯，記錄在 Jira 或類似工具。

C. 工具：

• 任務管理：Jira、Trello。
• 規格工具：Cucumber、Excel。
• 協作工具：Miro、Zoom。

D. 注意事項：

• 避免在 Sprint 規劃花太多時間補充範例，應在梳理階段完成大部分工作。
• 確保範例與 Sprint 目標相關，聚焦當前價值。
• 若故事未準備好（無足夠範例），考慮推回待辦清單。

E. 效益

• 確保選入的故事有清晰的驗收標準，降低開發中的歧義。
• 幫助團隊更準確估計工作量，提升 Sprint 計劃的可行性。
• 為「完成定義」提供具體依據，確保交付品質。

Daily Scrum

(1) 角色與目的

• 參與角色：Scrum 團隊、Scrum Master（協調）。
• 目的：檢視進度、識別障礙、調整計劃。SBE 在此用於快速確認開發進度是否符合驗收標準。

(2) SBE 如何搭配？
A. 做法：

• 開發者在報告進度時，參考 SBE 範例，確認當前任務是否符合預期行為。
• 如果遇到技術挑戰或需求歧義，團隊快速回顧相關範例，決定是否需要澄清。
• 測試者可根據範例，提前準備測試用例或自動化腳本。

B. 步驟：

• 開發者報告進度，例如：「我正在實現折扣功能，已完成普通會員場景。」
• 測試者或產品負責人提問，參考範例確認是否涵蓋所有場景（例如：VIP 會員折扣）。
• 若發現偏差，Scrum Master 安排短暫討論或標記為待澄清。
• 更新 Jira 或任務板，確保進度與範例對齊。

C. 工具：

• 任務管理：Jira、Trello。
• 規格工具：Cucumber（快速查看範例）。

D. 注意事項：

• 每日 Scrum 時間短（15 分鐘），避免深入討論範例，必要時安排額外會議。
• 確保範例隨手可得（例如：Jira 內連結）。
• 鼓勵開發者主動參考範例，減少依賴即席澄清。

E. 效益

• 保持開發方向與驗收標準一致，減少偏離。
• 快速識別需求誤解，及時調整。
• 讓測試者與開發者同步，提升協作效率。

Sprint Review

(1) 角色與目的

• 參與角色：產品負責人、Scrum 團隊、Scrum Master、利害關係人（Stakeholders）。
• 目的：展示 Sprint 成果，收集反饋，調整產品待辦清單。SBE 在此用於驗證成果是否符合驗收標準，並收集反饋以改進範例。

(2) SBE 如何搭配？
A. 做法：

• 在展示功能時，團隊參考 SBE 範例，演示系統如何滿足每個場景。
• 利害關係人根據範例驗證功能是否符合期望，提出反饋。
• 如果反饋揭示新場景或需求，記錄下來並在下次梳理時補充新範例。
• 將通過驗收的範例存入規格庫，作為未來參考。

B. 步驟：

• 團隊展示功能（例如：折扣功能），逐一對應 SBE 範例。
• 利害關係人提問或反饋，例如：「VIP 會員折扣是否支援多商品？」
• 如果需要新範例，記錄為新故事或待梳理任務。
• 更新規格庫，標記已驗收的範例。

C. 工具：

• 展示工具：系統 Demo、PowerPoint。
• 文件工具：Confluence、Jira。
• 規格工具：Cucumber。

D. 注意事項：

• 確保演示直接對應範例，讓利害關係人清楚驗收依據。
• 避免在檢視中大幅修改範例，應記錄反饋並在梳理階段處理。
• 管理利害關係人期望，聚焦當前 Sprint 成果。

E. 效益

• 提供明確的驗收依據，讓利害關係人信任成果。
• 反饋直接與範例關聯，方便後續梳理。
• 增強規格庫的完整性，作為長期資產。

Sprint Retrospective

(1) 角色與目的

• 參與角色：Scrum 團隊、Scrum Master。
• 目的：檢討 Sprint 過程，找出改進點。SBE 在此用於評估範例撰寫和使用的效果，優化未來流程。

(2) SBE 如何搭配？
A. 做法：

• 團隊回顧 SBE 在本 Sprint 的應用，討論範例的清晰度、覆蓋率和實用性。
• 分析問題根因，例如：範例是否遺漏關鍵場景？是否過於複雜？
• 提出改進建議，例如：更早涉及測試者、簡化範例格式。
• 更新 SBE 流程或規範，應用於下個 Sprint。

B. 步驟：

• 團隊分享 SBE 相關經驗，例如：「範例太籠統，導致開發中需要多次澄清。」
• 討論改進點，例如：「在梳理時多考慮異常場景。」
• 制定行動計劃，例如：「下個 Sprint 在梳理會議增加 30 分鐘討論邊界條件。」
• 更新團隊規範，記錄在 Confluence 或回顧筆記。

C. 工具：

• 回顧工具：Miro（白板）、FunRetro。
• 文件工具：Confluence。

D. 注意事項：

• 聚焦流程改進，避免陷入個別範例的細節。
• 鼓勵全員參與，特別是測試者和開發者的視角。
• 確保改進計劃具體可執行，並在下個 Sprint 驗證效果。

E. 效益

• 持續優化 SBE 應用，提升範例品質和團隊效率。
• 增強團隊對 SBE 的認同感，促進長期採用。
• 解決跨角色協作的痛點，改善溝通。

簡單的案例

假設你是一個 Scrum 團隊的 Scrum Master，負責開發一個電商平台的「折扣功能」。團隊包含產品負責人（小美）、開發者（小強）、測試者（小花）和你。以下是如何在一個 Sprint 中應用 SBE：

(1) 產品待辦清單梳理：
小美提出用戶故事：「作為顧客，我希望結帳時自動獲得折扣，提升購物體驗。」
團隊開 1 小時梳理會議，使用 SBE 撰寫範例：

Given：購物車總額 1000 元，普通會員；
When：結帳；
Then：總額 900 元（10% 折扣）。

Given：購物車總額 1000 元，VIP 會員；
When：結帳；
Then：總額 850 元（10% + 5% 折扣）。

Given：購物車總額 500 元；
When：結帳；
Then：總額 500 元（無折扣）。

範例記錄在 Jira，小美確認無誤。

(2) Sprint 規劃：
團隊選入折扣故事，檢查範例完整性，估計 5 個故事點。
小強拆分任務（實現折扣邏輯、更新 UI），小花確認範例可轉為 Cucumber 測試。
範例與任務關聯在 Jira。

(3) 每日 Scrum：
小強報告：「昨天完成普通會員折扣，測試通過第一個範例，今天處理 VIP 折扣。」
小花提問：「VIP 折扣是否考慮多商品場景？」小強確認範例已涵蓋。
若有歧義，安排短暫澄清會議。

(4) 測試驅動開發：
小花將範例轉為 Cucumber 腳本，實現自動化測試。
小強使用 TDD，先寫單元測試，確保程式碼通過所有範例。
測試失敗時（例如：VIP 折扣計算錯誤），小強修復程式碼。

(5) Sprint 檢視：
團隊展示折扣功能，逐一演示三個範例。
利害關係人提問：「如果購物車為空呢？」團隊記錄新場景，計劃下次精煉。
範例存入 Confluence 。

(6) Sprint 回顧：
團隊討論：「範例幫助澄清需求，但異常場景不足，導致開發中需要澄清。」
改進計劃：「下個 Sprint 在精煉時多討論邊界條件。」
最終，折扣功能順利上線，自動化測試確保品質，小美和利害關係人滿意成果。

在敏捷團隊中，我們常以為「大家都有共識」，但 Sprint 中的返工與誤解卻層出不窮。SBE 就像是一面鏡子，讓我們從不同角度檢視需求的真實意圖。它不是一套工具而已，而是一種 讓人說清楚、讓系統做對 的文化實踐。

如果你希望：

• 減少返工與誤解
• 強化產品驗收的一致性
• 讓 PO / Dev / QA 不再是各說各話
  那麼，把 SBE 融入 Scrum，就是邁向高效協作團隊的第一步。