使用者故事是敏捷開發中一種常用的需求捕獲手段，本文會先對它做個簡要介紹，再比較其和用例的不同，最後附上我的一點小體會。不想看介紹的可以直接跳到比較部分。

一、使用者故事

1. 使用者故事（User Story）：描述對軟體（或系統）使用者或客戶有價值的功能,只是需求描述，而不是詳細的需求規範。一種敏捷開發常用的需求捕獲手段。

2. 3C原則：

卡片（Card） – 使用者故事一般寫在小的卡片上。卡片正面寫上故事的簡短描述，格式為：作為一個<角色>, 我想要<活動>, 以便於<商業價值>。卡片背面協商測試點，可隨時補充。

交談（Conversation）- 使用者故事背後的細節來源於和客戶或者產品負責人的頻繁的交流溝通。

確認（Confirmation）- 通過驗收測試確認使用者故事被正確完成。

可能是在這樣的卡片上寫下使用者故事

寫完故事貼到牆上，確保所有人都能時刻查閱

3. Invest原則：

獨立性（Independent）—
要儘可能的讓一個使用者故事獨立於其他的使用者故事，可以獨立被開發、驗收、測試。使用者故事之間的依賴使得制定計劃，確定優先順序，工作量估算都變得很困難。

這裡我犯過一個錯誤，今年8月時我接了一個物料管理的Meidum級的開發需求。因我將該需求拆成小isssue時拆得太細了，導致後續的開發互相摯肘，不能獨立完成開發、完成驗收測試。開發、BA、測試、項管都覺苦不堪言。但當時拆完後，也沒有人有異議，可見大家並未對獨立性引起重視。

比如以下兩個小issue：

1. 配置表增加【入倉屬性】欄位，業務可以在配置表維護【入倉屬性】值。

2. 完成單據後，單據上的【入倉屬性】自動賦值。

issue2依賴issue1的開發，若issue1未開發好會影響issue2進入開發。這時我可以將在卡片背面將其合併為一個使用者故事：

作為一個倉庫作業員，我想要在完成單據時讓系統告訴我這個物料進哪個倉庫，這樣我可以把物料入到正確的倉庫裡。在卡片背面寫上測試條件：可以配置入倉。

可協商性（Negotiable）—
一個使用者故事的內容要是可以協商的，使用者故事不是合同。一個使用者故事卡片上只是對使用者故事的一個簡短的描述，不包括太多的細節。具體的細節在溝通階段產出。一個使用者故事卡帶有了太多的細節，實際上限制了和使用者的溝通。

我理解，如果在整個流程中始終採用使用者故事，則使用者故事永遠可協商，甚至直到功能上線、卡片被棄。但若已產出用例或需求文件準備交付給開發時，請BA讓stakeholder對文件進行評審，讓其確認和sign off。（下文會詳細講）

有價值（Valuable）—
每個故事必須對客戶具有價值（無論是使用者還是購買方）。一個讓使用者故事有價值的好方法是讓客戶來寫下它們。一旦一個客戶意識到這是一個使用者故事並不是一個契約而且可以進行協商的時候，他們將非常樂意寫下故事。

就我所呆過3個專案組經歷而言，讓客戶寫價值比較難但也不是無法實現。在使用者和IT團隊的合作模式已磨合得較成熟的團隊裡，使用者對軟體和業務的熟悉程度較高，給出價值的可能性高。反之，則需要BA去溝通、總結這個故事的價值。

可以估算性（Estimable）—開發團隊需要去估計一個使用者故事以便確定優先順序，工作量，安排計劃。但是讓開發者難以估計故事的問題來自：對於領域知識的缺乏（這種情況下需要更多的溝通），或者故事太大了（這時需要把故事切分成小些的）。

短小（Small）—
一個好的故事在工作量上要儘量短小，最好不要超過10個理想人/天的工作量,至少要確保的是在一個迭代或Sprint中能夠完成。使用者故事越大，在安排計劃，工作量估算等方面的風險就會越大。

可測試性（Testable）—一個使用者故事要是可以測試的，以便於確認它是可以完成的。如果一個使用者故事不能夠測試，那麼你就無法知道它什麼時候可以完成。一個不可測試的使用者故事例子：軟體應該是易於使用的

二、使用者故事和用例的區別：

1. 目的不同：使用者故事適合探索需求。用例適合交付給開發和測試人員，且作為備案。

2. 範圍不同：使用者故事更輕量級、概括化、更隨意，用例更詳細、更正式。

3. 創造方式不同：使用者故事是由客戶團隊、開發坐一起寫在卡片上頭腦風暴出來的。用例主要是BA書寫的。

4. 壽命不同：使用者故事在功能上線後就被丟掉，而用例會作為書面文件儲存。

5. 使用者故事優勢和劣勢：

優勢：早期捕獲需求時，更靈活、更節約需求分析時間（最主要）

劣勢：沒有上下文關係，是一個個的需求點，無法連成面（使用者故事地圖一定程度上可以緩解）

6. 適合使用者故事的：從0到1搭建起來的有現場客戶支援的新系統、快速迭代的網際網路公司。對敏捷和使用者故事認同、使用者較配合的理想的團隊。

適合用例/ 需求文件的：傳統瀑布式開發的團隊、執行多年（沒有現場支援客戶）的大系統。

三、個人體會

個人一點小心得：在需求探索階段，以使用者故事捕獲整理需求。需求確認較明確後，以需求文件內嵌用例的方式發給stakeholder做評審，等所有stakeholder都確認後讓其sign off（簽名確認，雖然較難實現），理論上此時這份文件就該停止更新了。如果以後再發現需要改動的地方，就應該出一個change request，然後改動後再讓所有的stakeholder去sign off，全部sign off之後再一次baseline。

早期的我，無法區分使用者故事、用例、場景、需求文件的區別，統一以需求文件概括它們。而在不斷的學習和實踐當中，我認識到他們是不同的。孰優孰劣並無定論，使用哪種技術也得看你所在的團隊的具體情景而定。

只有反覆的學習、實踐、總結，方能化紙上方法論為心經吧。