1，用戶故事的概念
概念這種東西我喜歡說文解字的方式去理解和闡述展箱。用戶故事=用戶+故事=人+故+事旨枯，那就是一個人因為什么原因要做什么事，提煉出來三要素就是who混驰、why攀隔、what皂贩。從需求角度描述就是一個用來確認(rèn)用戶和用戶需求的簡短描述。
2竞慢，用戶故事的三要素
用戶故事在軟件開發(fā)過程中被作為描述需求的一種表達形式先紫。為了規(guī)范用戶故事的表達，便于溝通筹煮，用戶故事通常的表達格式為：作為一個<用戶角色>, 我想要<完成活動>, 以便于<實現(xiàn)價值>。
一個完整的用戶故事包含三個要素：
（1）角色（who）：誰要使用這個
（2）活動（what）：要完成什么活動
（3）價值（value）：為什么要這么做居夹，這么做能帶來什么價值
3败潦，3C原則
用戶故事的描述信息以傳統(tǒng)的手寫方式寫在紙質(zhì)卡片上，所以Ron Jeffries(2001)對這三個方面稱為3C：卡片(Card)准脂、對話(Conversation)和確認(rèn)(Confirmation)劫扒。
（1）卡片（Card）：用戶故事一般在小卡片上寫著故事的簡短描述，規(guī)則和完成標(biāo)準(zhǔn)狸膏。
卡片的正面書寫故事的描述沟饥，格式為：作為一個<角色>, 我想要<完成活動>, 以便于<實現(xiàn)價值>描述需求；卡片背面書寫完成用戶故事的規(guī)則和完成標(biāo)準(zhǔn)湾戳，格式為：Given…When…Then贤旷。
（2）交談（Conversation）：用戶故事背后的細節(jié)來源于和客戶或者產(chǎn)品負(fù)責(zé)人的交流溝通。確保各方對故事的理解正確砾脑。
（3）確認(rèn)（Confirmation）：通過驗收測試確認(rèn)用戶故事被正確完成幼驶。
4，INVEST原則
好的用戶故事除了格式規(guī)范韧衣，要素完整外盅藻，還應(yīng)該遵循INVEST原則：Idependent（獨立的）；Negotiable（可協(xié)商的）畅铭；Valuable（有價值的）氏淑；Estimatable（可評估）；Small（小的）硕噩；Testable（可測試的）假残。
（1）Idependent（獨立的）
要盡可能的讓一個用戶故事獨立于其他的用戶故事。用戶故事間保持獨立性不僅便于排列和調(diào)整優(yōu)先級榴徐，使得發(fā)布和迭代計劃更容易制定守问，便于獨立地理解、跟蹤坑资、實現(xiàn)耗帕、測試以及頻繁交付，也使得用戶故事的大小估算所涉及的范圍更清晰袱贮，從而估算偏差更小仿便。
（2）Negotiable（可協(xié)商的）
一個用戶故事的內(nèi)容要是可以協(xié)商的，用戶故事不是合同。一個用戶故事只是對用戶故事的一個簡短的描述嗽仪，不包括太多的細節(jié)荒勇。具體的細節(jié)在溝通階段產(chǎn)出。一個用戶故事帶有了太多的細節(jié)闻坚，實際上限制了用戶沽翔、團隊的想法和溝通。
（3）Valuable（有價值的）
每個故事必須對客戶具有價值（無論是用戶窿凤、購買方還是公司內(nèi)部角色）仅偎。用戶故事對于最終的用戶是有價值的，因此應(yīng)該站在用戶的角度去編寫雳殊，描述的是一個一個的feature橘沥，而非一個一個的task。這個特點促進團隊的開發(fā)和測試成員由傳統(tǒng)的指令式工作方式向自驅(qū)動的價值導(dǎo)向工作方式轉(zhuǎn)變夯秃，使團隊中的每個人知道自己每天做的工作價值座咆。
（4）Estimatable（可評估）
計劃會議里面一個很重要的環(huán)節(jié)，那就是故事點的估計仓洼。實際上就是對要開發(fā)的User Story進行一個粗量級的估算介陶，以便于團隊能夠知道這個user story的復(fù)雜度（工作量），重點放在當(dāng)前迭代里能否按照該用戶故事的接收條件和團隊定義的DoD(完成標(biāo)準(zhǔn))來完成這個用戶故事衬潦，如果不能完成斤蔓，給出理由，由PO來決定是否拆分或者重新設(shè)計用戶故事镀岛。讓開發(fā)者難以估計故事的問題來自：對于領(lǐng)域知識的缺乏（這種情況下需要更多的溝通）弦牡，或者故事太大了（這時需要把故事切分成小些的）
（5）Small（小的）
一個好的故事在工作量上要盡量短小，最好不要超過10個理想人/天的工作量,至少要確保的是在一個迭代中能夠完成漂羊。用戶故事越大驾锰，在安排計劃，工作量估算等方面的風(fēng)險就會越大走越。
（6）Testable（可測試的）
一個用戶故事要是可以測試的椭豫，以便于確認(rèn)它是可以完成的。如果一個用戶故事不能夠測試旨指，那么你就無法知道它什么時候可以完成赏酥。一個不可測試的用戶故事例子：軟件應(yīng)該是易于使用的。
5谆构，三個準(zhǔn)則
用戶故事在遵循了INVEST原則后裸扶，基本就是一個好的用戶故事了。再重點分析三個準(zhǔn)則搬素，幫助在產(chǎn)出用戶故事時更好地符合原則呵晨。三個準(zhǔn)則是：一個用戶魏保、完整價值、不依賴
（1）一個用戶
只包含一個用戶摸屠，因為多個用戶常常有細微的差別谓罗。一般是典型的用戶，常常有共同的某類需求季二。
（2）完整價值
完整地交付一個客戶價值檩咱。一個完整的用戶故事意味著這個故事完成后，用戶可以達成一個明確的胯舷、有意義的目標(biāo)税手。
（3）不依賴
依賴性的三種常見類型是：重疊、順序和包含需纳。總體上來說艺挪，故事之間功能點相互重疊是需要避免的不翩；順序關(guān)系是現(xiàn)實存在，在多數(shù)情況下可以通過一些手段解決麻裳；包含關(guān)系對復(fù)雜系統(tǒng)是有幫助的口蝠，對排定發(fā)布和迭代計劃的影響需要注意。
1.重疊依賴
重疊依賴是帶來最多困擾的依賴形式津坑，特別是多個用戶故事包含多個不同的重疊部分時妙蔗，很難找到一組用戶故事可以代表該最小可行產(chǎn)品的功能集合，該集合應(yīng)該包含且僅包含一次需要的功能疆瑰。
解決方式：
將重疊部分單獨剝離出來做為獨立的用戶故事
合理拆分用戶故事眉反，并且將重疊部分只保留在一個最有內(nèi)聚性的用戶故事中
使用Scrum開發(fā)模式
2.順序依賴
順序依賴是指要使某用戶故事完成，另外的一個或多個用戶故事必須在它之前完成穆役。順序依賴通常是無害的寸五，而且有一些方式可以減輕這種依賴。從敏捷開發(fā)的角度耿币，整個系統(tǒng)是從初始的最小可行產(chǎn)品逐步演化為強大的產(chǎn)品梳杏，后面的每一步是建立在前面的基礎(chǔ)之上的。但從另外的角度淹接，不必要的順序依賴使得排列和調(diào)整優(yōu)先級變的比較困難十性，進而影響制定發(fā)布和迭代計劃，也使得用戶故事的大小估算更難以把握塑悼。
?解決方式：
一個迭代內(nèi)的用戶故事盡量做到?jīng)]有內(nèi)在依賴劲适。
保持迭代之間只有單向依賴，在時間上只有后面迭代的故事對前面迭代故事的單向依賴（前向依賴）拢肆。
剝離出核心依賴作為獨立的故事减响，不要把有依賴和無依賴的需求混在一個故事里靖诗。
3.包含依賴
包含依賴是指在組織用戶故事時使用有層級的管理，比如常見的特性－故事兩級管理支示，一個特性包含多個用戶故事刊橘，這樣就構(gòu)成了特性對其屬下故事的包含依賴。
??解決方式：
用戶故事一級用來做迭代計劃颂鸿，避免用特性一級做粗粒度迭代計劃促绵，特性一級可以用來做發(fā)布計劃
特性一級同樣可以進行拆分，直至拆分到最小市場化特性的程度嘴纺，并將其包含的用戶故事分別歸到新拆分出的特性中去
遵從最小可行產(chǎn)品的理念败晴，一個特性分多個用戶故事多個迭代實現(xiàn)，每一個迭代可形成潛在可交付或者提供內(nèi)部或外部反饋栽渴。
---
參考：
