面對眾多需求方法，為什麼要選擇 User Story？本章探討 Story 的核心優勢以及潛在的局限性。

強調口頭溝通#

書面文字容易製造精確的假象。人們以為把需求寫下來就能消除歧義，但實際上書面文字充滿多義性。

Story 的目標不是鉅細靡遺地記錄功能需求，而是寫下幾句簡短的佔位句，提醒開發者和客戶之後需要進行的對話。

口頭對話的優勢：

• 提供即時的回饋循環，減少誤解
• 不會產生書面文件「虛假的精確感」
• 促進相互理解，而非單方面的文件傳遞

人人都能理解#

IEEE 830 文件常包含過多的技術術語，讓使用者難以閱讀。Use Case 雖然比較好，但初次接觸的人仍需學習其格式（前置條件、延伸情境等）。

Story 因為簡短且以使用者價值為導向，任何人——業務人員和開發人員——都能輕鬆理解。

研究發現，人們對以「故事」形式組織的資訊有更好的記憶力，連未明確提到的行動都更容易回想起來。

大小恰到好處#

• IEEE 830 的需求陳述：太小（數千條「系統應…」的陳述難以排定優先順序）
• Use Case 和情境：太大（只有幾十個，排序意義不大）
• User Story：恰到好處——適合規劃、開發和測試

適合迭代開發#

Story 天生適合迭代開發：

• 可以先寫出粗略的 Epic Story，之後再逐步拆分
• 不需要在開始寫程式前就寫完所有 Story
• 容易隨著專案的演進增刪和修改

鼓勵延遲細節#

Story 鼓勵團隊在適當的時機才深入細節：

• 初期只需要高層級的 Story 來估算和規劃
• 接近開發時才透過對話補充具體細節
• 避免過早投入時間在可能被捨棄的功能上

支援機會主義開發#

Parnas 和 Clements 早在 1986 年就指出，軟體開發不可能完全自上而下，因為：

• 使用者通常不完全知道自己要什麼
• 許多細節要在開發過程中才會浮現
• 即使所有細節都已知，人類也無法理解那麼多資訊
• 人會犯錯

Story 承認這個現實，讓團隊能在高層級需求和低層級細節之間自由切換。

鼓勵參與式設計#

Story 讓使用者成為設計軟體行為的積極參與者，而非被動的需求提供者。這與經驗式設計（Empirical Design）形成對比——後者透過觀察使用者來設計，但使用者不直接參與。

累積默會知識#

面對面的對話促進團隊內默會知識（Tacit Knowledge）的累積。開發人員和客戶越常交談，彼此的理解就越深。

Story 的局限性#

Story 並非萬能，以下情境需要注意：

• 大型專案：數以百計的 Story 可能難以管理其關聯性。可使用角色分類和保持高層級 Story 來緩解
• 追溯性需求：如果組織要求從需求到測試的追溯性，Story 需要額外的文件補充
• 大型團隊：面對面對話無法完全取代書面文件的規模化優勢