user story概覽——承上啟下的重要一環
軟體開發是乙個從捕獲客戶需求到編碼實現的過程。在我們傳統的印象中，需求是厚厚的軟體規格說明書，實現則是無窮無盡的bug產生器。需求是在實現之前寫好的，客戶簽字確認的。實現是程式設計師拿著需求不斷猜測這該怎麼做，那該怎麼做的重新發現的過程。在需求與實現之間橫亙著乙個巨大的鴻溝，做需求的人和寫**的人總是互相推諉責任，到最後客戶總是得不到自己想要的功能。
敏捷軟體開發方法有一整套實踐，來促進客戶與開發團隊之間的交流與反饋。而user story則是這些實踐中比較具有啟發意義的乙個主要實踐，我認為它是承上啟下的重要一環。因為在其上，它是具體使用者角色完成具體目標的過程組成部分。而在其下，它是編寫驗收標準（acceptance criteria）的具體上下文。它就像一條鎖鏈一樣，在需求與實現之間架起了一座危橋。
之所以稱之為危橋，是因為一旦人們把user story當做軟體規格說明書一類的文件來看待的話，user story很快就不能反映客戶的需求，同時也無法指導實現的開發。我們必須要把它當做危橋一樣來對待，經常去重新評估實現難度，根據給客戶帶來的價值排優先順序。當發現它所覆蓋的內容不再準確或者過時了的時候，對於危橋我們就不用猶豫，該炸掉重來就炸掉重來。
不嚴格地說，敏捷開發從需求到實現的單向流程（反饋的路徑未包括其中）大概是這樣的：
?這個過程沒有暗示任何瀑布式的開發風格，其實這個過程是反覆的，不斷有反饋回顧。畫出這麼乙個流程性的圖只是為了表明user story是如何承上啟下的。
要知道它是如何承上啟下，還是要知道它自身是什麼樣的。明確的答案是：user story應該small（小規模），testable（可測試），valuable（有價值）。
valuable是說user story能夠給利益相關人員提供明確的商業價值。往往表現為滿足了使用者某方面的預期。
testable是說user story可以給驗收標準提供明確的上下文。也就是說這個user story能夠對程式的外部行為產生影響，比如介面，日誌檔案等使用者看得見摸得著的東西。
small是說user story應該足夠小，在商業過程中也就一步或者相關聯的幾步。小的目的是更好地符合迭代式開發的風格，能夠在乙個迭代內完成。
這三個特性直接支撐了敏捷開發的一些核心價值：給客戶提供價值（對應valuable），保證質量（對應testable）和快速響應變化（small）。
user story與傳統的use case有一些不同。某些use case的書籍中提倡寫出不同層次的use case，有high level的，有medium level的，也有low level的。從某種程度上來說，high level相當於goal，medium level相當於user story，而low level相當於acceptance criteria。但是由於use case的寫法缺乏統一的習慣和明確的指導。初學者在寫use case的時候往往缺乏明確的目標，無法有效地把需求與實現貫穿起來。
因此，若把需求到實現看做從天空到湖底的話，user story就恰好浮在水面上。可以說user story是文件能夠達到的最細節的層次，若在往下就陷入了實現的細節之中，與具體實現方式相關而且經常變動，維護起來非常困難。更重要的是，寫出那樣的細節文件又不能執行，無法給客戶帶來價值，只是對**的無味重複。
這裡只是概覽了user story在整個開發過程中的位置和作用，以及其自身的的一些屬性和它能提供的價值。具體使用user story去實踐敏捷開發可以參閱我同事李默所寫的敏捷需求分析一文。他在文中以乙個業務分析師的角度講述了如何把user story用在敏捷需求分析的過程中去。
旅遊攻略 user story
1 攻略store 1 選擇國家 使用者可以看到按三大洲分類後的國家名稱列表 使用者在歐洲可選擇英國 法國和德國 使用者在美洲可選擇美國和加拿大 使用者在亞洲可選擇中國大陸 港澳台和日本 可以向使用者推薦熱門國家 可以按人氣對國家進行排行 2 選擇城市 使用者可以檢視城市列表 對於英法德日等小國家，...
敏捷開發 User Story
敏捷開發流程 1 我們首先需要確定乙個product backlog 按優先順序排列的乙個產品需求列表 這個是由product owner 負責的 2 scrum team根據product backlog列表，做工作量的預估和安排 3 有了product backlog列表，我們需要通過 spri...
SCRUM和使用者故事（User Story）
user story是一種描述使用者需求 業務價值的最佳實踐，但不是說非要用user story的形式來描述需求，而且通常在乙個sprint backlog中，尤其在最初的若干sprint中會存在一些架構設計 技術調研 介面定義 獲取背景知識這些方面的事項和任務需要處理，這意味著乙個sprint不是...