在敏捷軟體開發的世界裡，團隊常常面臨一個挑戰：如何確保每個人對即將開發的功能有著完全相同的理解？Example Mapping就是為了解決這個問題而生的一種強大而簡單的協作技巧。

本文將介紹Example Mapping的核心概念、執行步驟、參與角色、實際範例以及關鍵的注意事項，幫助您的團隊更有效地溝通需求，提升產品質量。

什麼是Example Mapping？

簡單來說，Example Mapping是一種協作方法，它利用具體、明確的範例來探索、理解和完善使用者故事（User Story）的需求與驗收標準（Acceptance Criteria）。

• 這一切都發生在開始動手開發之前。
• 它的核心目標，是在團隊成員（包含業務、開發和測試人員）之間，圍繞著即將開發的功能，建立起共同的理解（Shared Understanding）。
• 這個過程透過結構化的對話，將抽象的需求轉化為具體的場景，確保大家講的是「同一種語言」。

Example Mapping並非又一場冗長低效的會議，而是一個高度聚焦的工作坊。它的設計初衷，就是為了在開發早期，透過不同視角的碰撞（例如業務方提出需求、開發方考慮實現、測試方設想邊界情況），主動發現並解決潛在的誤解和歧義，從而避免後續開發過程中出現問題。

正如前面所提到，軟體開發過程常常像一場傳話遊戲（Telephone Game）：業務方的原始需求，在傳遞給開發者，再到測試者的過程中，可能因為各自的解讀和假設而逐漸失真。Example Mapping正是要打破這個困境。它強制團隊成員圍繞著具體的範例進行討論，而不是停留在模糊、抽象的需求描述上，從而建立一個基於共同範例的、不易產生歧義的溝通基礎。

起源

Example Mapping這個方法是由 Matt Wynne 提出並推廣的。了解其來源有助於理解其設計理念和在敏捷社群中的脈絡。

傳統的品質保證，往往側重於在程式碼完成之後尋找缺陷。然而，Example Mapping讓測試人員在程式碼產生之前，就深入參與需求的討論。

這個過程明確地旨在揭露模糊不清之處、邊界情況以及潛在的誤解。透過在開發前解決這些問題，可以顯著降低因需求理解偏差，而引入缺陷的可能性。因此，Example Mapping除了能需求釐清外，還是一種預防性的品質保證措施。它將品質的考量，移到了開發生命週期的更前端，實踐了「品質左移」的理念。

Example Mapping 的核心元素

Example Mapping透過四種核心元素來結構化對話，這些元素通常用不同顏色的便利貼，或數位白板上的卡片來視覺化呈現。

範例 1：線上訂票系統的「退票規則」

範例 2：購物車系統的「折扣邏輯」

Example Mapping會議

A. 準備階段
(1) 召集合適的人員：
最基本的是「神勇三劍客」（Three Amigos）組合，即代表業務/產品負責人（PO）、開發者和測試者的角色，他們的視角對於全面理解需求至關重要。
如果特定故事需要其他專業知識（如使用者體驗設計師、運維人員等），也可以邀請他們參加。但為了保持對話效率，建議將人數控制在 3 到 5 人左右。

(2) 選擇一個故事：
每次會議聚焦於一個使用者故事或待辦事項（PBI）。客戶在意的故事通常效果最好。初期可以避免選擇過於技術性的故事，像是償還技術債並不合適一開始就處理。
(3) 準備材料/工具：
如果是實體會議，準備好四種顏色的便利貼（黃、藍、綠、紅）和筆。如果是遠端團隊，選擇一個合適的數位白板工具，如 Miro、或Mural等。

(4) 設定時間限制（Timebox）：
設定一個計時器，通常建議 25 到 30 分鐘。這有助於保持專注，避免會議拖很久。

(5) 指定引導者（Facilitator）：
特別是初期，最好指定一位引導者。引導者的職責是引導對話方向、確保討論內容被記錄下來、控制時間，並防止團隊陷入不必要的細節爭論。

B. 流程步驟

• 從故事開始（黃色）：
  將選定的故事寫在黃色卡片上，放在最上方。確保每個人都理解這個故事的目標和價值。

• 識別規則（藍色）：
  討論並寫下已知的驗收標準或業務規則。將它們寫在藍色卡片上，放在黃色故事卡片的下方。

• 用範例闡釋（綠色）：
  針對每一條規則，構思具體的範例。將範例寫在綠色卡片上，放在對應的藍色規則卡片下方。範例要力求清晰，能夠說明規則。切記：現階段避免編寫完整的 Gherkin 語句，因為重點在釐清需求。

• 捕捉問題（紅色）：
  當討論中出現任何在場人員無法立即回答的問題時，將其寫在紅色卡片上，放在相關規則/範例旁邊或單獨區域。不要卡在試圖解決所有未知問題上，記錄下來繼續前進。

• 迭代與討論：
  持續探索規則和範例，根據需要靈活切換。記住，對話本身才是最重要的。

解讀地圖與評估就緒狀態

• 當時間結束（或對話自然告一段落）時，暫停並一起審視創建出來的範例地圖。
• 大量紅色卡片（問題）： 表明這個故事還存在許多未知數，理解不夠充分，需要獲取更多資訊才能開始開發。需要有人跟進解決這些問題。
• 大量藍色卡片（規則）： 表明這個故事可能過於龐大或複雜，應該考慮將其拆分成更小的故事。
• 某個規則下有過多綠色卡片（範例）： 表明這條規則本身可能過於複雜，或者可以被細分成多條更簡單的規則。
• 詢問團隊： 進行一次快速投票（例如豎起大拇指表示同意，放下表示不同意）：「這個故事準備好可以開發了嗎？」2。如果答案是否定的，則需要安排後續行動（如釐清問題、拆分故事）或安排下一次範例映射會議。

25分鐘時間限制的診斷價值

多個來源都強調設定一個較短的時間限制，通常是 25 到 30 分鐘，並將時間結束時地圖的視覺狀態與故事是否就緒聯繫起來。這個時間限制迫使團隊進行聚焦的對話。最終形成的視覺化地圖（紅、藍、綠卡片的分布情況）提供了關於團隊對故事理解程度和複雜性的即時反饋。

如果一個故事無法在設定的時間內被充分探討（即無法得到一個清晰、紅色卡片很少且藍綠卡片數量可控的地圖），這本身就是一個信號，表明存在問題。問題很可能源於缺乏清晰度（紅色卡片過多）或規模/複雜度過高（藍色/綠色卡片過多）。

因此，這個時間限制不僅僅是為了提高效率，它更像是一個實用的測試或診斷工具。未能在時間內完成映射，就意味著這個故事未能通過「準備就緒可供開發」的檢查。團隊應認真對待這個時間限制，不僅是為了節省時間，更應將其視為評估故事就緒狀態的關鍵指標，並觸發必要行動，如進一步研究或拆分故事。

讓Example Mapping落地的關鍵考量與技巧

了解了範例映射是什麼以及如何做之後，要如何在團隊中成功實施並使其發揮最大價值呢？以下是一些關鍵的考量點和實用技巧：

• 聚焦對話，而非僅僅是產出物： 範例映射最大的價值在於透過討論建立的共同理解。卡片和地圖只是促進這種對話的工具。不要過分糾結於卡片的格式是否完美，而應確保對話是深入且有意義的。

• 保持範例的實用性（避免過早形式化）： 抵制在會議中就試圖編寫完美 Gherkin 語句的衝動。使用簡單的語言、圖畫或簡寫來捕捉範例的核心，確保每個人都能快速理解。等到團隊對需求達成共識後，再由特定成員（例如開發者和測試者結對）將其形式化。

• 有效的引導： 引導者的角色非常重要。他們需要確保會議保持聚焦、管理好時間、捕捉關鍵問題，並防止討論陷入無關的細枝末節。同時，也要鼓勵所有成員積極參與和貢獻。

• 處理問題（紅色卡片）： 確保記錄下來的問題得到跟進。在重要的問題得到解答之前，故事就不算真正準備就緒。這可能需要會議之外的人員提供資訊。

• 常見陷阱：
o 分析癱瘓（Analysis Paralysis）： 過度糾結於細節，試圖映射出所有可能性。善用時間限制和紅色卡片。
o 問題懸而不決： 紅色卡片堆積如山，卻沒有明確的負責人或跟進行動。
o 忽視拆分信號： 儘管地圖顯示故事過大，仍然強行推進。
o 過早形式化： 在會議中編寫 Gherkin，扼殺了探索和發現的過程。
o 流於形式： 只是走個過場，缺乏真正的協作和質疑精神。
o 參與者不當： 缺少了關鍵視角。