工作中遇到很多同事問到用戶故事的相關(guān)概念粒竖，而且基本是每新來一個(gè)同事就要解釋一遍，這里做個(gè)總結(jié)籍琳，希望以后不要再做這個(gè)重復(fù)性的工作了先舷。??
1. INVEST
INVEST是用戶故事的書寫標(biāo)準(zhǔn)，具體每個(gè)字母的含義如下：
1.1. Independent(獨(dú)立的)
一個(gè)用戶故事對于另一個(gè)用戶故事應(yīng)該是盡可能獨(dú)立的前方。為什么呢狈醉？因?yàn)閭鹘y(tǒng)的需求描述方式（功能模塊廉油、用例等等）由于個(gè)體較大，彼此之間依賴較多苗傅，導(dǎo)致輸入到開發(fā)階段時(shí)開發(fā)工程師不太容易計(jì)劃他們的工作抒线，從而導(dǎo)致的開發(fā)延期的現(xiàn)象就變成大家習(xí)以為常了。而獨(dú)立性較好的故事能夠獨(dú)立交付渣慕，從這一點(diǎn)嘶炭，用戶故事就充分的考慮到了需求與開發(fā)的敏捷化連接問題。
那要如何才能做到用戶故事之間的獨(dú)立性呢逊桦？通常旱物，可以通過組合用戶故事或者分割用戶故事來減少依賴性。
1.2. Negotiable(可協(xié)商的)
大家對所有之前達(dá)成的一致在新的變化發(fā)生情況下卫袒，協(xié)商后達(dá)成新的一致宵呛，從而推動(dòng)系統(tǒng)的研發(fā)進(jìn)展。
上面是比較書面的解釋夕凝，我的理解是這樣的：
用戶故事可協(xié)商的地方宝穗，在于驗(yàn)收標(biāo)準(zhǔn)（AC），同樣一個(gè)手機(jī)號+驗(yàn)證碼的注冊功能码秉，我們既可以寫成如下的驗(yàn)收標(biāo)準(zhǔn)（以下只是舉例逮矛，真實(shí)的驗(yàn)收標(biāo)準(zhǔn)建議參照Given-When-Then的格式編寫）：
手機(jī)號是11位數(shù)字
手機(jī)號只能是13、15转砖、17须鼎、18開頭
驗(yàn)證碼一分鐘只能發(fā)送一條
發(fā)送驗(yàn)證碼之前需要做個(gè)圖片驗(yàn)證
驗(yàn)證碼的有效期是5分鐘
驗(yàn)證碼4位數(shù)字
密碼6-12位
密碼只能是字母、數(shù)字府蔗、下劃線的2種或3種的組合
……
如果按照這個(gè)驗(yàn)收標(biāo)準(zhǔn)來做晋控，一個(gè)注冊功能可能就要開發(fā)一周左右，但是早期我們?yōu)榱丝焖龠M(jìn)行后續(xù)的開發(fā)姓赤，可以暫時(shí)降低我們驗(yàn)收標(biāo)準(zhǔn)：
手機(jī)號是11位數(shù)字
驗(yàn)證碼一分鐘只能發(fā)送一條
驗(yàn)證碼4位數(shù)字
密碼6-12位
這樣就能迅速完成注冊的功能赡译，繼續(xù)后續(xù)的開發(fā)了。
這就是我理解的用戶故事的“可協(xié)商的”概念不铆。
協(xié)商去掉的這些驗(yàn)收標(biāo)準(zhǔn)蝌焚，不是說以后都不做了，而是暫時(shí)為了完成整個(gè)MVP誓斥，就先犧牲掉了只洒，這些細(xì)節(jié)還可以在后續(xù)的迭代里再加上。
1.3. Valuable(有價(jià)值的)
每個(gè)故事必須對客戶具有價(jià)值（無論是用戶還是購買方）劳坑。一個(gè)讓用戶故事有價(jià)值的好方法是讓客戶來寫下它們毕谴。
書寫用戶故事的三段論：
作為（XX角色），我想（XX功能），從而（實(shí)現(xiàn)XX價(jià)值）
最后一句話析珊，就是在強(qiáng)調(diào)價(jià)值的重要性羡鸥。
1.4. Estimable(可估計(jì)的)
開發(fā)者需要去估計(jì)一個(gè)用戶故事以便對故事進(jìn)行規(guī)劃。但是讓開發(fā)者難以估計(jì)故事的問題來自：對于領(lǐng)域知識的缺乏（這種情況下需要更多的溝通）忠寻，或者故事太大了（這時(shí)需要把故事切分成小些的）惧浴。
1.5. Small(短小的)
一個(gè)好的故事應(yīng)該在工作量上短小，描述具有代表性奕剃，而且不超過3人天（或者3故事點(diǎn)）的工作量衷旅。超過這個(gè)范圍的用戶故事，將會(huì)在劃分范圍和估計(jì)時(shí)出現(xiàn)很多錯(cuò)誤纵朋。
1.6. Testable(可測試的)
一個(gè)用戶故事是可測試的并用來確認(rèn)完成柿顶，記住，我們不開發(fā)不能測試的故事操软。如果你不能測試那么你永遠(yuǎn)不知道你什么時(shí)候是完成了嘁锯。
小結(jié)
一個(gè)編寫良好的用戶故事是敏捷開發(fā)的基礎(chǔ)。它們應(yīng)該相互獨(dú)立聂薪，詳情應(yīng)該便于開發(fā)者和用戶進(jìn)行溝通家乘，應(yīng)該對用戶有價(jià)值，應(yīng)該對于開發(fā)者來說盡可能的清晰以便進(jìn)行估計(jì)藏澳，應(yīng)該短小仁锯，通過預(yù)定義測試用例的使用確保它是可以測試的。
2. 3C
3C是收集用戶故事的有效手段翔悠，具體每個(gè)C的含義如下：
2.1. Card（卡片）
用卡片（Card）來簡要描述故事业崖。
2.2. Conversation（會(huì)話）
與Product Owner（或客戶）交談（Conversation）來明確細(xì)節(jié)。
2.3. Confirmation（確認(rèn)）
驗(yàn)收評審蓄愁，確認(rèn)（Confirmation）被正確完成双炕。
3. DEEP
DEEP原則是用來梳理Product Backlog的，改概念最早在Mike Cohn的《Succeeding with Agile》一書中提到涝登。
3.1. Detailed Appropriately（詳略得當(dāng)）
接下來的1~2個(gè)Sprint中要完成的用戶故事雄家，需要足夠的詳細(xì)。而不著急開發(fā)的胀滚，則不必太詳細(xì)。
3.2. Estimated（做過估算的）
Product Backlog中的需求都要是經(jīng)過估算的乱投，只不過靠后（優(yōu)先級低）的PBI沒有充分理解（也不必）咽笼，因此其估算也不如靠前（優(yōu)先級高）的PBI估算精確。
3.3. Emergent（涌現(xiàn)的）
Product Backlog不是靜止的戚炫。隨著了解的深入剑刑，Product Backlog中的用戶故事會(huì)增加、減少、刪除施掏、拆分或重新排優(yōu)先級钮惠。
3.4. Prioritized（排列優(yōu)先級的）
Product Backlog應(yīng)該根據(jù)由上至下按照條目的價(jià)值從高到低排序。團(tuán)隊(duì)?wèi)?yīng)根據(jù)優(yōu)先級進(jìn)行開發(fā)七芭，從而使正在開發(fā)的產(chǎn)品或系統(tǒng)價(jià)值實(shí)現(xiàn)最大化素挽。
4. WSJF
規(guī)模化敏捷框架SAFe(Scaled Agile Framework)提出了一種定量計(jì)算法來評估需求的優(yōu)先級狸驳，稱為WSJF(Weighted Shortest Job First: 加權(quán)最短作業(yè)優(yōu)先)预明。
計(jì)算公式如下：
其中分母的工作規(guī)模部分大家比較熟悉，即估算的需求規(guī)模(故事點(diǎn)方法耙箍、理想時(shí)間方法等)撰糠。
分母部分的延期成本包括三個(gè)因子：
4.1. User and Business Value(用戶和商業(yè)價(jià)值)
指的是對客戶或商業(yè)的相對價(jià)值，比如：
用戶更喜歡哪個(gè)?
對盈收有什么影響?
不做會(huì)產(chǎn)生什么潛在的負(fù)面影響?
4.2. Time Criticality(時(shí)間關(guān)鍵性)
指的是給用戶的商業(yè)價(jià)值隨著時(shí)間的推進(jìn)如何變化辩昆。比如：
是否是固定交付日期類型的需求?
用戶是否會(huì)愿意等待阅酪，還是會(huì)選擇其他產(chǎn)品?
在某個(gè)時(shí)間窗口不上線的話，是否會(huì)影響用戶的滿意度?
4.3. Risk Reduction& Opportunity Enablement(減少風(fēng)險(xiǎn)或幫助獲取新機(jī)會(huì))
指的是除了上面的第1個(gè)和第2因子需要考慮因素之外汁针，這個(gè)需求還能為業(yè)務(wù)帶來哪些價(jià)值, 比如：
是否降低產(chǎn)品以后交付某些必要特性的風(fēng)險(xiǎn)?
是否會(huì)學(xué)到我們不知道的知識或信息?
是否會(huì)帶來新的商業(yè)機(jī)會(huì)?
這樣拆解后术辐，WSJF的公式細(xì)化為：
如何操作呢?將所有特性列成表，如下：
對這個(gè)表中WSJF公式中的每個(gè)因子扇丛，采用與用戶故事的故事點(diǎn)相對估算類似的方法做估算术吗。比如，對于工作規(guī)模這一項(xiàng)帆精，選擇一個(gè)工作規(guī)模最小的特性作為基準(zhǔn)较屿，它的工作規(guī)模設(shè)為1（注意：WSJF公式中的每一項(xiàng)，都要選中一個(gè)特性作為相對估點(diǎn)的1）卓练，其他特性的工作規(guī)模與之相對比, 采用近似斐波那契數(shù)列1, 2,3, 5, 8,13, 20…為單位隘蝎。如果特性A是基準(zhǔn)特性的3倍，那么特性A的工作規(guī)模就是3襟企。
為WSJF公式分子的其他因子做同樣的相對估算法嘱么，即找到一個(gè)因子最小的基準(zhǔn)特性，然后其他特性與之相比較顽悼，從而得到相應(yīng)因子的估算數(shù)值曼振。
就每一個(gè)特性，將WSJF的每個(gè)因子做相對估算后蔚龙，就可以計(jì)算出每個(gè)特性的WSJF冰评，這樣你就得到了量化的需求排序。
常見疑惑：WSJF適用于所有需求的排序嗎?
不是的木羹。在SAFe里甲雅，WSJF可以適用于大粒度的Epic和Feature級需求解孙，不適用于小顆粒的用戶故事級需求，原因是用戶故事通常很小抛人，分母的幾個(gè)因子不容易對比出差異弛姜。此外這種定量計(jì)算法在團(tuán)隊(duì)里應(yīng)用過于沉重，因?yàn)樾枰獙γ總€(gè)需求估算四個(gè)因子妖枚，不止是需求規(guī)模這一個(gè)因子廷臼，所有估算的耗時(shí)翻了四倍。
5. MoSCoW
MoSCoW法則是用來排定用戶故事優(yōu)先級順序的一種定性方法盅惜。
具體這個(gè)縮寫的含義是什么中剩，具體怎么用，可以參考這篇文章：如何利用MoSCoW法則排定Sprint Backlog的優(yōu)先級
6. SMART
SMART是用來將用戶故事拆分為任務(wù)時(shí)的指導(dǎo)原則抒寂。
6.1. Specific（具體的）
任務(wù)必須是具體的结啼。
6.2. Measurable（可以衡量的）
任務(wù)必須是可以衡量的。
6.3. Attainable（可達(dá)成的）
任務(wù)必須是可以達(dá)成的屈芜。
6.4. Relevant（相關(guān)的）
任務(wù)與最終目標(biāo)是要相關(guān)的郊愧。
6.5. Time-bound（有時(shí)限的）
任務(wù)必須具有明確的截止期限。
