軟件需求是一個溝通問題
不要在項目開始時就做一套包羅萬象的決策，我們要把各個決策分散在項目過程中。為此，我們要確保有一個獲取信息的過程，越早越好，越頻繁越好。
什么是用戶故事
描述了對用戶、系統或軟件購買者有價值的功能。包含：卡片（Card）、對話（Conversation）、確認（Confirmation）。
卡片代表客戶需求而不是記錄需求。卡片包含故事的文字描述，然而需求細節要在“對話”中獲得，并在“確認”部分得意記錄。
細節在哪里？
并不需要不斷的分解故事，直到有一個故事能夠覆蓋每一個細節。與其寫下這些故事細節，不如讓開發團隊和客戶討論這些細節，即在這些細節變得重要時討論。
故事并不具有契約性質。達成的協議將有測試來記錄，測試將演示故事是否被正確開發。
必須多長時間完成？
用戶的期望做好以驗收測試的形式被記錄下來。
測試描述的目的是傳遞故事的額外信息，以便于開發人員指導故事于什么時候結束。
客戶團隊
使用故事的過程是怎么樣的？
編寫用戶故事的過程最好從考慮系統的用戶類別開始。
規劃發布和迭代
什么是驗收測試？
用來驗證實現的用戶故事是否符合客戶團隊的期望。
為什么要變？
對話》書面溝通
同時被你和開發理解
大小合適于做計劃
適用于迭代開發
推遲考慮細節，知道非常清楚的了解自己的真正需求
用戶故事的重點從文檔轉移到對話。
疑問
1. 交互文檔、界面設計，與故事的關系
