軟件需求是一個溝通問題
不要在項目開始時就做一套包羅萬象的決策劫狠，我們要把各個決策分散在項目過程中夸研。為此，我們要確保有一個獲取信息的過程，越早越好黄橘，越頻繁越好兆览。
什么是用戶故事
描述了對用戶、系統(tǒng)或軟件購買者有價值的功能塞关。包含：卡片（Card）抬探、對話（Conversation）、確認(rèn)（Confirmation）帆赢。
卡片代表客戶需求而不是記錄需求小压。卡片包含故事的文字描述椰于，然而需求細(xì)節(jié)要在“對話”中獲得怠益，并在“確認(rèn)”部分得意記錄。
細(xì)節(jié)在哪里瘾婿？
并不需要不斷的分解故事蜻牢，直到有一個故事能夠覆蓋每一個細(xì)節(jié)。與其寫下這些故事細(xì)節(jié)偏陪，不如讓開發(fā)團(tuán)隊和客戶討論這些細(xì)節(jié)抢呆，即在這些細(xì)節(jié)變得重要時討論。
故事并不具有契約性質(zhì)竹挡。達(dá)成的協(xié)議將有測試來記錄镀娶，測試將演示故事是否被正確開發(fā)。
必須多長時間完成揪罕？
用戶的期望做好以驗收測試的形式被記錄下來梯码。
測試描述的目的是傳遞故事的額外信息，以便于開發(fā)人員指導(dǎo)故事于什么時候結(jié)束好啰。
客戶團(tuán)隊
使用故事的過程是怎么樣的轩娶？
編寫用戶故事的過程最好從考慮系統(tǒng)的用戶類別開始。
規(guī)劃發(fā)布和迭代
什么是驗收測試框往？
用來驗證實現(xiàn)的用戶故事是否符合客戶團(tuán)隊的期望鳄抒。
為什么要變？
對話》書面溝通
同時被你和開發(fā)理解
大小合適于做計劃
適用于迭代開發(fā)
推遲考慮細(xì)節(jié)椰弊，知道非常清楚的了解自己的真正需求
用戶故事的重點從文檔轉(zhuǎn)移到對話许溅。
疑問
1. 交互文檔、界面設(shè)計秉版，與故事的關(guān)系
