為什麼用使用者故事探索需求

在敏捷開發中，需求探索不是一次性的收集，而是一段持續對話的過程。我們不再依賴冗長的規格書來凍結需求，而是透過使用者故事（User Story）這種更簡潔、有溫度的方式，讓團隊與利害關係人用共同語言討論「誰需要什麼，以及為什麼需要」。

在傳統專案中，需求通常以厚厚的文件或長長的功能清單呈現。這種方式看似完整，其實有幾個問題：

1. 缺乏情境與目的

   • 功能清單只告訴團隊「要做什麼」，卻沒有說明「為什麼要做」與「誰需要」。
   • 例如：「系統要提供報表匯出功能」，但是誰要用這個功能？是財務人員、業務主管，還是客服？不同角色的需求細節可能差很多。

2. 容易陷入解決方案導向

   • 客戶或利害關係人常直接提出解決方案，而不是問題本身。
   • 若不先釐清背景與目標，團隊可能會花時間做出沒有人真正需要的東西。

3. 難以促進跨角色溝通

   • 厚重的文件不容易讓非技術背景的成員理解，導致需求誤解、溝通延遲。

使用者故事是一種以「人」為中心的需求表達方式，它的重點不在於詳細規格，而在於引發對話、探索價值。它有三個關鍵價值：

1. 從價值出發，而不是從功能出發

   使用者故事會回答三個問題：

   • 誰需要這個功能？（Who）
   • 做什麼？（What）
   • 為什麼需要？（Why）

   這能幫助團隊聚焦在「解決使用者的真實問題」。

2. 讓需求探索變成持續的對話

   使用者故事不是一次寫完就結束，而是持續與使用者以及產品負責人對話、澄清與細化。這種方式符合敏捷精神，讓需求可以隨著理解加深而演化。

3. 促進跨角色共識

   使用者故事用簡單語言描述需求，不需要懂技術也能理解。團隊和利害關係人都能在同一張卡片上看到相同的需求重點，避免因為專業技術術語造成溝通隔閡。

使用者故事的重點，不是一次寫出「完美規格」，而是提供一個共同探索與對話的起點。它讓需求從「冰冷的功能項目」變成「有溫度的使用者需求」，也讓團隊更容易聚焦在創造價值，而不是只是完成任務。

撰寫高品質使用者故事的技巧

雖然使用者故事不像需求規格文件那樣有嚴格格式，但它有一個基本骨架，能幫助團隊快速抓住重點，不會遺漏關鍵資訊。

三個必備元素

1. 誰（Who）

   • 誰是這個需求的使用者或受益者？
   • 可以是明確角色（例如「財務經理」）、使用族群（例如「新手用戶」），甚至是系統外部的互動對象。

2. 做什麼（What）

   • 使用者希望完成的行為或功能。
   • 這裡描述的是「能力」，而不是技術細節。

3. 為什麼（Why）

   • 背後的目的或價值。
   • 這是判斷需求優先順序的重要依據，如果沒有明確的「為什麼」，這個需求很可能只是「想要」，而不是「需要」。

常用撰寫格式

最常見的表達方式有以下四種：

1. As a <角色>, I can <能力>, so that <目的>
   範例：
   As a customer, I can track my order status online, so that I know when to expect delivery.

2. In order to <目的>, as a <角色>, I can <能力>
   範例：
   In order to submit my tax return on time, as a taxpayer, I can download my annual statement from the portal.

3. As a <角色>, I want <需求>, so that <目的>
   範例：
   As a project manager, I want to export the task list to Excel, so that I can share it with the finance team.

4. As <角色> <何時> <何地>, I want <需求> because <目的>
   範例：
   As an online shopper,
   when I am checking out items in my cart on an e-commerce website,
   I want to pay quickly using a stored credit card,
   because I don’t want to re-enter my payment details every time and risk abandoning my purchase.

不論使用哪種句型，關鍵是讓讀者一眼就能看出需求對象、想做的事，以及背後的價值。

使用者故事不是規格書

• 它只是一個對話的起點，後續還需要透過討論補充細節。
• 它不會一次把所有驗收條件或設計細節寫進去，而是保留空間給團隊去探索與確認。

使用者故事的格式，看似簡單，但正是這種簡潔，讓團隊能在最短時間理解需求的核心。格式是為了對齊思路，不是為了限制創意。

從對話到文字：撰寫高品質使用者故事的步驟

使用者故事的誕生，不是從鍵盤開始，而是從對話開始。高品質的故事，往往源於團隊、利害關係人與使用者之間的反覆交流與澄清。

以下是一個建議的撰寫流程：

1. 步驟 1：蒐集使用者情境

   • 與實際使用者或業務代表對話，詢問他們在什麼情境下需要這個功能。
   • 聚焦在「日常任務」與「痛點」：
     • 他們現在怎麼做？
     • 哪裡最耗時或最困難？
     • 他們最希望改善的部分是什麼？

   例如：「財務經理每月底要花兩天時間手動整合不同系統的報表，才能產出最終月報。」

2. 步驟 2：確認背後的商業價值

   • 問「為什麼」至少兩次，挖掘真正的需求驅動因素。
   • 確定這個需求的價值屬性：
     • 是節省時間？
     • 是降低錯誤率？
     • 還是創造新的收入機會？

   例如：「自動匯出報表可以讓財務經理把時間花在分析數據，而不是整理數據，進而更快提供決策依據。」

3. 步驟 3：提煉成簡潔易懂的故事

   • 用 「誰 + 做什麼 + 為什麼」 的結構，把需求壓縮成一兩句話。
   • 保留適當模糊空間，讓團隊後續能夠討論與細化。

   範例故事：「作為一名財務經理，我可以匯出合併的月度報告，以便更快地向管理層提供見解。」

4. 步驟 4：在團隊內驗證故事

   • 與開發、測試、設計等跨角色成員一起簡單地過一下故事，看大家是否對角色、能力、目的有相同理解。
   • 初步討論可能的實作方向與風險點。

5. 步驟 5：記錄後續要探索的細節

   • 標註需要補充的資訊（例如整合哪些系統、格式要求、非功能性需求）。
   • 這些細節可以在迭代規劃會議（Iteration Planning Meeting）或待辦清單精煉會議（Refinement Meeting）中再補足。

高品質的使用者故事，不是寫得多長，而是能讓所有人用同一種視角看待需求。它從真實的使用者情境出發，經過價值澄清，再用簡單的語句固定下來，為後續的討論打好基礎。

驗收條件的價值

使用者故事告訴我們誰需要什麼功能，以及為什麼需要，但它並沒有明確說明「怎麼判斷做完了」。

這就是驗收條件（Acceptance Criteria）的價值所在，它為團隊提供一組可驗證的依據，用來確認故事是否達到預期成果。

驗收條件是什麼

定義：

• 針對每個使用者故事，列出一組必須達成的條件，只有全部滿足，該故事才算完成。

目的：

• 對齊團隊與利害關係人的期望。
• 提供測試依據，確保功能符合需求。
• 降低模糊與爭議，避免交付後才發現落差。

撰寫驗收條件的原則

• 可測試
  條件必須能用明確的測試或驗證方式檢查。

• 具體
  避免模糊詞彙（如「快速」、「漂亮」、「方便」），改用可量化或具體描述。

• 條列化
  每個條件獨立成項，方便追蹤與測試。

• 涵蓋例外情境
  不只描述理想情況，也要定義錯誤處理或邊界條件。

例如針對這個使用者故事：

作為一名註冊用戶，我可以在線上重設密碼，這樣我就能在不致電客服的情況下重新取得存取權限。

驗收條件可以是：

• 使用者在登入頁面點選「忘記密碼」後，可以輸入註冊的電子郵件地址。
• 系統會寄送含有重設密碼連結的電子郵件，連結有效期限為 24 小時。
• 使用者點擊連結後，可以輸入新密碼並確認。
• 新密碼需符合安全性規則（至少 8 碼，包含大小寫字母與數字）。
• 密碼成功重設後，使用者可以用新密碼登入系統。

驗收條件就像是故事的「驗收清單」，讓團隊知道什麼情況下可以說「這個功能完成了」。它不只是交付的檢查標準，更是需求溝通的重要工具，能有效減少返工與誤解。

「驗收條件」與「完成的定義」的差異

在敏捷開發中，「完成」不能只憑感覺決定。完成的定義（Definition of Done, DoD） 是一組由團隊共同約定的品質標準，適用於所有使用者故事與工作項目，用來判斷某個功能是否可以被視為「完成」，是所有故事共用的品質與交付標準。

而驗收條件則是針對單一故事的特定需求與驗證方式。

舉例來說：完成的定義規定所有程式碼都必須通過自動化測試並合併至主分支。而驗收條件則像是重設密碼的連結只在 24 小時內保持有效，超過時限不得在透過這個連結重設密碼。

從故事到迭代：需求的驗證與調整

使用者故事並不是一成不變的文件，而是一個隨著理解與環境變化持續演化的需求載體。在敏捷中，我們不只是「先寫好再做」，而是透過迭代不斷驗證與調整，讓產出更貼近真實需求。

1. 將故事帶入迭代
   在迭代計劃會議（Iteration Planning Meeting）中，團隊從產品待辦清單（Product Backlog）中，挑選優先度最高、已澄清到足夠程度的故事，放入迭代待辦清單（Iteration Backlog）。

   每個故事在進入迭代前，應該已有明確的驗收條件與適用的完成的定義。

2. 在迭代中持續澄清與驗證
   開發過程中，可能會遇到未預期的情況（技術限制、使用者新想法、法規變動）。團隊應保持與產品負責人及利害關係人溝通的頻率，即時確認調整方向。如果變更會影響驗收條件，必須更新並通知相關人員。

3. 迭代結束時的展示
   在迭代展示會議（Iteration Demonstration / Review Meeting），向產品負責人與利害關係人展示已完成的故事，並驗證是否符合驗收條件與完成的定義。不展示只做一半的半成品，只展示已達到驗收條件和可交付標準的功能。

4. 收集回饋並決定後續動作
   回饋類型包括：

   • 功能可直接接受並進入釋出流程
   • 功能需小幅修正（可留在下一迭代完成）
   • 功能需重大調整（需返回待辦清單重新規劃）

   回饋的重點不是找錯，而是發現「更貼近需求的做法」。需求調整是正常現象，敏捷團隊的任務是快速響應需求變化。

5. 在迭代回顧會中持續改善
   在回顧會議（Retrospective Meeting）中，檢討本迭代需求澄清與驗證的過程：

   • 是否有故事在迭代中才被大量修改？
   • 這些變更能否提前在待辦清單精煉時就發現？
   • 驗收條件與完成的定義是否足夠明確？

從使用者故事到迭代驗證，是一個需求持續驗證與調整的循環：

• 故事提供需求核心
• 驗收條件確保功能正確性
• 完成的定義保障整體品質
• 展示與回饋讓需求在交付過程中不斷貼近真實價值

敏捷強調的不是一次定案，而是透過快速交付、收集回饋、持續調整，讓每一次迭代都更接近「真正有價值的完成品」。

避免常見的需求陷阱

在實務專案中，使用者故事與驗收條件經常因為撰寫不當而失去原本的價值，甚至成為後續開發的障礙。

1. 一次寫太大

   • 反模式：
     「使用者可以完成線上申請並收到批核通知」

     這可能包含十多個功能與流程，會導致估算困難與開發風險增加。

   • 改進建議：
     將故事拆成更小的可交付單位（Minimum Business Increment, MBI），並確保每個故事都有明確價值與可驗收結果。

2. 把故事寫成技術任務

   • 反模式：
     「新增一個 API 端點」
     「重構報表模組程式碼」
     這樣的描述完全是開發觀點，缺乏使用者情境與價值，讓非技術人員無法理解它為什麼存在。

   • 改進建議：
     轉換成「誰、做什麼、為什麼」的使用者故事格式，例如：

     「身為一個銷售經理，我能夠透過 API 存取銷售報表，以便自動與我們的 CRM 系統整合。」

3. 驗收條件過於模糊

   • 反模式：
     「系統要能快速反應」
     「使用者介面要好看」
     這些描述沒有量化或具體標準，導致測試與開發的理解差異很大。

   • 改進建議：
     使用可驗證的描述，例如：

     「查詢結果應在 2 秒內顯示」
     「操作界面需符合公司 UI 指南規定」

4. 缺乏邊界與例外情境

   • 反模式：
     「使用者可以上傳檔案」

     沒有定義檔案格式、大小限制或錯誤處理方式，實作時容易出現爭議。

   • 改進建議：
     在驗收條件中加入例外情況，例如：

     「系統僅接受 JPG、PNG 格式，檔案大小不超過 5MB，超過限制需提示錯誤訊息。」

5. 驗收條件與完成的定義混淆

   • 反模式：
     在驗收條件中寫「程式碼需通過所有單元測試」。

     這其實屬於完成的定義（團隊共用的品質標準），而不是針對故事的特定需求。

   • 改進建議：
     驗收條件專注在「這個故事的功能正確性」，完成的定義負責「所有故事的品質一致性」。

6. 沒有回顧與改進撰寫方式

   • 反模式：
     使用者故事與驗收條件一旦建立，就不再檢視，導致後續積累大量過時或不適用的需求描述。
   • 改進建議：
     在待辦清單精煉會議與迭代回顧會議中，檢查故事與驗收條件的品質，持續優化撰寫習慣與標準。

避免這些反模式，不只是提升需求描述的品質，更能讓使用者故事從實作到驗證這條鏈路更加順暢，減少團隊對需求的誤解與返工的浪費。

整合 DA 工具：探索範疇

在 Disciplined Agile（簡稱 DA）中，撰寫使用者故事與驗收條件並不是孤立的動作，而是「探索範疇（Explore Scope）」這個重要流程目標的一部分。「探索範疇」提供了多種決策點與可選策略，幫助團隊依照情境量身打造最適合的需求與品質描述方式。

在確認我們要交付什麼價值，以及交付的範圍邊界的決策點上，「探索範疇」會引導我們：

• 選擇需求表達方式
  除了使用者故事，也可以搭配用例（Use Case）、使用者故事地圖（User Story Mapping）、史詩（Epic）拆解等。

• 定義優先順序
  依商業價值、風險與依賴關係排序故事。

• 決定粒度
  判斷故事是否需要拆分成更小的最小商業增量（MBI）以便交付。

常見情境與對應策略：

在確保交付的功能在品質層面上滿足使用者與組織的要求的決策點上，「探索範疇」會引導我們：

• 定義品質要求
  效能、安全性、易用性、法規遵循等。

• 設定驗收標準
  以具體、可測試的方式描述品質要求（例如「查詢結果必須在 2 秒內完成」）。

• 考慮例外情境
  錯誤處理、極端使用情況、邊界條件等。

• 確認文件詳細程度
  在需求文件中需要記錄多少細節，要編寫詳細規格或是以結果方式驅動。

常見情境與對應策略：

結語：從對話到價值的交付鏈

在 DA 的脈絡中，使用者故事與驗收條件並不是單純的需求描述工具，而是持續探索、驗證與交付價值的關鍵節點。

1. 使用者故事

   • 以「誰、做什麼、為什麼」建立需求的共同語言，讓團隊與利害關係人能快速對齊目標。
   • 重點不在寫得多詳細，而是促進跨角色的對話與持續澄清。

2. 驗收條件與完成的定義

   • 驗收條件確保每個故事的功能正確性與可驗證性。
   • 完成的定義則確保所有交付物達到一致的品質標準。
   • 兩者結合，既能確認「做對事」，也能確保「把事做好」。

3. 迭代中的驗證與調整

   • 透過展示會議收集回饋，將需求調整成更貼近實際價值的方向。
   • 敏捷的核心不是一次定案，而是快速交付、收集回饋、持續優化的循環。

4. 避免反模式，持續改進

   • 避免將故事寫成技術任務、驗收條件模糊、缺乏例外情境等常見錯誤。
   • 在待辦清單精煉會議與迭代回顧會議中，定期檢視與優化撰寫方式。

5. 整合 DA 工具

   • 透過探索範疇流程目標確定價值範圍、優先順序、明確品質標準與驗收依據。

使用者故事是「價值的入口」，驗收條件是「品質的守門員」。當兩者與 DA 的流程目標結合，需求探索就不再只是文件，而是推動價值落地的引擎。