『壹』 我們常說的用戶故事是什麼
1，用戶故事的概念
概念這種東西我喜歡說文解字的方式去理解和闡述。用戶故事=用戶+故事=人+故+事，那就是一個人因為什麼原因要做什麼事，提煉出來三要素就是who、why、what。從需求角度描述就是一個用來確認用戶和用戶需求的簡短描述。
2，用戶故事的三要素
用戶故事在軟體開發過程中被作為描述需求的一種表達形式。為了規范用戶故事的表達，便於溝通，用戶故事通常的表達格式為：作為一個<用戶角色>, 我想要<完成活動>, 以便於<實現價值>。
一個完整的用戶故事包含三個要素：
（1）角色（who）：誰要使用這個
（2）活動（what）：要完成什麼活動
（3）價值（value）：為什麼要這么做，這么做能帶來什麼價值
3，3C原則
用戶故事的描述信息以傳統的手寫方式寫在紙質卡片上，所以Ron Jeffries(2001)對這三個方面稱為3C：卡片(Card)、對話(Conversation)和確認(Confirmation)。
（1）卡片（Card）：用戶故事一般在小卡片上寫著故事的簡短描述，規則和完成標准。
卡片的正面書寫故事的描述，格式為：作為一個<角色>, 我想要<完成活動>, 以便於<實現價值>描述需求；卡片背面書寫完成用戶故事的規則和完成標准，格式為：Given…When…Then。
（2）交談（Conversation）：用戶故事背後的細節來源於和客戶或者產品負責人的交流溝通。確保各方對故事的理解正確。
（3）確認（Confirmation）：通過驗收測試確認用戶故事被正確完成。
4，INVEST原則
好的用戶故事除了格式規范，要素完整外，還應該遵循INVEST原則：Idependent（獨立的）；Negotiable（可協商的）；Valuable（有價值的）；Estimatable（可評估）；Small（小的）；Testable（可測試的）。
（1）Idependent（獨立的）
要盡可能的讓一個用戶故事獨立於其他的用戶故事。用戶故事間保持獨立性不僅便於排列和調整優先順序，使得發布和迭代計劃更容易制定，便於獨立地理解、跟蹤、實現、測試以及頻繁交付，也使得用戶故事的大小估算所涉及的范圍更清晰，從而估算偏差更小。
（2）Negotiable（可協商的）
一個用戶故事的內容要是可以協商的，用戶故事不是合同。一個用戶故事只是對用戶故事的一個簡短的描述，不包括太多的細節。具體的細節在溝通階段產出。一個用戶故事帶有了太多的細節，實際上限制了用戶、團隊的想法和溝通。
（3）Valuable（有價值的）
每個故事必須對客戶具有價值（無論是用戶、購買方還是公司內部角色）。用戶故事對於最終的用戶是有價值的，因此應該站在用戶的角度去編寫，描述的是一個一個的feature，而非一個一個的task。這個特點促進團隊的開發和測試成員由傳統的指令式工作方式向自驅動的價值導向工作方式轉變，使團隊中的每個人知道自己每天做的工作價值。
（4）Estimatable（可評估）
計劃會議裡面一個很重要的環節，那就是故事點的估計。實際上就是對要開發的User Story進行一個粗量級的估算，以便於團隊能夠知道這個user story的復雜度（工作量），重點放在當前迭代里能否按照該用戶故事的接收條件和團隊定義的DoD(完成標准)來完成這個用戶故事，如果不能完成，給出理由，由PO來決定是否拆分或者重新設計用戶故事。讓開發者難以估計故事的問題來自：對於領域知識的缺乏（這種情況下需要更多的溝通），或者故事太大了（這時需要把故事切分成小些的）
（5）Small（小的）
一個好的故事在工作量上要盡量短小，最好不要超過10個理想人/天的工作量,至少要確保的是在一個迭代中能夠完成。用戶故事越大，在安排計劃，工作量估算等方面的風險就會越大。
（6）Testable（可測試的）
一個用戶故事要是可以測試的，以便於確認它是可以完成的。如果一個用戶故事不能夠測試，那麼你就無法知道它什麼時候可以完成。一個不可測試的用戶故事例子：軟體應該是易於使用的。
5，三個准則
用戶故事在遵循了INVEST原則後，基本就是一個好的用戶故事了。再重點分析三個准則，幫助在產出用戶故事時更好地符合原則。三個准則是：一個用戶、完整價值、不依賴
（1）一個用戶
只包含一個用戶，因為多個用戶常常有細微的差別。一般是典型的用戶，常常有共同的某類需求。
（2）完整價值
完整地交付一個客戶價值。一個完整的用戶故事意味著這個故事完成後，用戶可以達成一個明確的、有意義的目標。
（3）不依賴
依賴性的三種常見類型是：重疊、順序和包含。總體上來說，故事之間功能點相互重疊是需要避免的；順序關系是現實存在，在多數情況下可以通過一些手段解決；包含關系對復雜系統是有幫助的，對排定發布和迭代計劃的影響需要注意。
1.重疊依賴
重疊依賴是帶來最多困擾的依賴形式，特別是多個用戶故事包含多個不同的重疊部分時，很難找到一組用戶故事可以代表該最小可行產品的功能集合，該集合應該包含且僅包含一次需要的功能。
解決方式：
將重疊部分單獨剝離出來做為獨立的用戶故事
合理拆分用戶故事，並且將重疊部分只保留在一個最有內聚性的用戶故事中
使用Scrum開發模式
2.順序依賴
順序依賴是指要使某用戶故事完成，另外的一個或多個用戶故事必須在它之前完成。順序依賴通常是無害的，而且有一些方式可以減輕這種依賴。從敏捷開發的角度，整個系統是從初始的最小可行產品逐步演化為強大的產品，後面的每一步是建立在前面的基礎之上的。但從另外的角度，不必要的順序依賴使得排列和調整優先順序變的比較困難，進而影響制定發布和迭代計劃，也使得用戶故事的大小估算更難以把握。
解決方式：
一個迭代內的用戶故事盡量做到沒有內在依賴。
保持迭代之間只有單向依賴，在時間上只有後面迭代的故事對前面迭代故事的單向依賴（前向依賴）。
剝離出核心依賴作為獨立的故事，不要把有依賴和無依賴的需求混在一個故事裡。
3.包含依賴
包含依賴是指在組織用戶故事時使用有層級的管理，比如常見的特性－故事兩級管理，一個特性包含多個用戶故事，這樣就構成了特性對其屬下故事的包含依賴。
解決方式：
用戶故事一級用來做迭代計劃，避免用特性一級做粗粒度迭代計劃，特性一級可以用來做發布計劃
特性一級同樣可以進行拆分，直至拆分到最小市場化特性的程度，並將其包含的用戶故事分別歸到新拆分出的特性中去
遵從最小可行產品的理念，一個特性分多個用戶故事多個迭代實現，每一個迭代可形成潛在可交付或者提供內部或外部反饋。
『貳』 什麼是用戶故事
用戶故事（user story）是從用戶的角度來描述用戶渴望得到的功能。一個好的用戶故事包括三個要素：
1. 角色：誰要使用這個功能。
2. 活動：需要完成什麼樣的功能。
3. 商業價值：為什麼需要這個功能，這個功能帶來什麼樣的價值。
用戶故事通常按照如下的格式來表達：
英文：
As a <Role>, I want to <Activity>, so that <Business Value>.
中文：
作為一個<角色>, 我想要<活動>, 以便於<商業價值>
舉例：
作為一個「網站管理員」，我想要「統計每天有多少人訪問了我的網站」，以便於「我的贊助商了解我的網站會給他們帶來什麼收益。」
需要注意的是用戶故事不能夠使用技術語言來描述，要使用用戶可以理解的業務語言來描述。
Ron Jeffries的3個C
關於用戶故事，Ron Jeffries用3個C來描述它：
卡片（Card） - 用戶故事一般寫在小的記事卡片上。卡片上可能會寫上故事的簡短描述，工作量估算等。
交談（Conversation）- 用戶故事背後的細節來源於和客戶或者產品負責人的交流溝通。
確認（Confirmation）- 通過驗收測試確認用戶故事被正確完成。
『叄』 用例，用戶故事和特性的區別
需求階段是軟體工程中的一個重要階段，裡面涉及到需求收集分析，需求管理，需求開發，系統工程，易用性和交互設計，界面，業務領域知識，非功能性需求等多方面的內容。在面向對象的需求分析中我們通常採用用例分析的方法進行，在RUP核心三要素中第一位的就是用例驅動。 在《Use Case Modeling》一書中的定義是，用例代表了系統為其用角（Actors）所做的有價值的事情。用例不是功能（functions），也不是特性（features），它們不能被分解。每個用例都有一個名字和一段簡述。用例的詳細描述本質上是一些敘述（stories），說明了用戶如何使用系統來完成他們認為重要的事情，以及系統做了些什麼來滿足這些需要。 張洵對用例的定義是一種粒度剛剛好，反映了用戶的真實目的（目標），並記錄了為達到此目的（目標），用戶與系統或多個干係者之間如何開展協作，從事了哪些動態交互行為的軟體需求（表現形式）。 首先用例是描述功能性需求，而在描述過程中所涉及到的三要素就是人(Actor)和系統邊界，交互和動態行為。在需求分析中我們另外強調了輸入輸出，而在用例中對輸入輸出的描述是融入在基本流和擴展流的描述中。在敏捷方法中我們一般採用用戶故事卡(User Story Card)，用戶故事卡對交互過程的描述可能並不會很詳細，但是更加強調了用戶驅動，強調了用戶場景，而這也是用例偏弱的地方。我們做任何需求都必須要清楚的知道是什麼樣的用戶和業務場景下驅動出了該需求。