用戶故事INVEST原則，本質(zhì)上是用來形容“好的用戶故事”，而不是“用戶故事”，這點(diǎn)請一定要謹(jǐn)記，因此不用懷疑，如果不滿足INVEST也可以是用戶故事。下面簡單介紹各個(gè)部分。有一些很好懂我就快速掠過，有一些比較有爭議我也會努力講出我自己的理解。
這點(diǎn)算是INVEST中最難懂，且最有可能出錯(cuò)的部分。同時(shí)也是PO或者研發(fā)覺得最困難的一個(gè)部分。
所謂獨(dú)立性，說的是各個(gè)用戶故事之間不存在依賴性。原先我們對獨(dú)立性的理解是，在實(shí)現(xiàn)功能先后上不能有依賴性，即A的實(shí)現(xiàn)不依賴于B，這樣子我們就可以更好地根據(jù)價(jià)值來進(jìn)行優(yōu)先級排序。
但是實(shí)際工作中，我們遇到過這種需求。看起來是獨(dú)立的，但實(shí)際上依賴性很重。
假設(shè)我們有一個(gè)Epic，要求我們支持信用卡支付。信用卡包括Visa、MasterCard和銀聯(lián)。
我們根據(jù)習(xí)慣將這個(gè)Epic拆分為支持Visa、MasterCard和銀聯(lián)。
此時(shí)三個(gè)用戶故事是否有依賴？
從功能角度來看沒有，但估算用戶故事大小的時(shí)候，就有非常明顯的影響。支付底層邏輯是三個(gè)用戶故事共同依賴的，無論你優(yōu)先完成哪個(gè)需求，你都需要完成底層邏輯。因此就會出現(xiàn)，第一個(gè)完成的用戶故事（假設(shè)為A），一定會比另外兩個(gè)故事增加了一些底層邏輯實(shí)現(xiàn)的功能。但如果你說先實(shí)現(xiàn)用戶故事B，那么這部分底層邏輯功能就需要加到B上面去。
這種情況下，拆分出來的用戶故事是有依賴性的。
因此，我們對依賴性的定義就要包含兩方面：
- 功能實(shí)現(xiàn)之間沒有依賴性，即任意順序?qū)崿F(xiàn)用戶故事都可以，不用刻意考慮技術(shù)底層；
- 功能之間不要出現(xiàn)共同依賴的底層邏輯，這會讓底層邏輯必然在某個(gè)拆分的用戶故事中實(shí)現(xiàn)，這對用戶故事的尺寸估算帶來一定的麻煩，這也是一定意義上的依賴性。
那針對上面的示例，我們怎么做比較合適呢？這里給出一個(gè)我個(gè)人常用的方法，我一般稱其為“模糊細(xì)節(jié)”。針對于信用卡支付的用戶故事，我們拆分成下面的兩個(gè)，或者三個(gè)用戶故事，這里以兩個(gè)為例。為了簡化，不再嚴(yán)格按照用戶故事模板。通過這種方式，我們將用戶故事主體中關(guān)于信用卡類型的部分隱藏掉，不會過早的將細(xì)節(jié)暴露，方便優(yōu)先級排序與工作量估算，然后借助驗(yàn)收標(biāo)準(zhǔn)來完善用戶故事（在正式開發(fā)之前完善結(jié)束），再進(jìn)入正式的開發(fā)階段即可。可協(xié)商體現(xiàn)在需求實(shí)現(xiàn)程度可協(xié)商。
以登錄功能為例，假設(shè)有這么一個(gè)用戶故事。這里的登陸到底是什么意思？用戶名密碼？手機(jī)驗(yàn)證碼？OpenID？掃碼登陸？還是其他？都有可能，這一切并沒有在我們寫下上面的用戶故事的時(shí)候就確定，而是需要PO 與研發(fā)團(tuán)隊(duì)共同協(xié)商后得出結(jié)論?？赡芪覀儺?dāng)前只需要實(shí)現(xiàn)用戶名密碼，但是下一個(gè)迭代中，我們需要支持微信掃碼登陸。當(dāng)時(shí)這里請注意：Negotiable僅僅是可協(xié)商，并不代表PO 一定要接受研發(fā)的意見。畢竟PO 才是最終決定用戶故事的人。這個(gè)不用談了，只需要嚴(yán)格按照用戶故事模板來寫，必然是有價(jià)值的，否則在編寫階段就已經(jīng)被拍死了。
這里有一點(diǎn)要注意：在編寫用戶故事的時(shí)候，一般我們都會緊緊抓住價(jià)值，但是在對用戶故事進(jìn)行解聚（Split）時(shí)，可能會發(fā)生根據(jù)模塊（Module）而不是功能（Feature）來進(jìn)行拆分。所謂可估算的，背后的邏輯是：編寫用戶故事的人，對具備該用戶故事的行業(yè)背景。
研發(fā)團(tuán)隊(duì)是自組織團(tuán)隊(duì)，他們負(fù)責(zé)對用戶故事進(jìn)行估算、拆分、完成等工作。其工作輸入主要是來自于PO 與客戶/用戶，因此作為輸入方的PO 是否靠譜就成了最后自組織團(tuán)隊(duì)輸出是否靠譜的重要判斷標(biāo)準(zhǔn)之一。因此，如果PO 自身都不掌握該用戶故事的行業(yè)背景與知識，我們又怎能相信PO 可以為研發(fā)做澄清工作，并讓研發(fā)通過自組織團(tuán)隊(duì)的方式完成交付呢？具體來說就是，你讓一個(gè)做電商的PO ，從淘寶去有贊，這個(gè)問題不太大。畢竟都是相同行業(yè)，模式有差別而已，稍微學(xué)習(xí)學(xué)習(xí)還能搞定。但是你是否敢讓一個(gè)電商PO 去商飛做C919的PO？或者說，如果C919的PO 是淘寶網(wǎng)的PO，這種飛機(jī)你還敢不敢坐？當(dāng)然，上面的例子比較極端，但放到不同領(lǐng)域或者垂直領(lǐng)域都是適用的。具備行業(yè)知識是寫出好的用戶故事基礎(chǔ)條件之一。S——Small/Size Appropriate，小的/大小適當(dāng)?shù)?/strong>
傳統(tǒng)的INVEST中，對S的解釋就是Small，即認(rèn)為只有小的用戶故事才是好的用戶故事，來源見此。之所以認(rèn)為小的用戶故事是好的用戶故事，有以下幾個(gè)原因：- 小的用戶故事更容易被研發(fā)所理解，幫助更好的開發(fā)；
如果我們將用戶故事放在“即將開發(fā)”的用戶故事的話，Small 是毫無疑問非常正確的。但是，如果我們將用戶故事當(dāng)作Product Backlog的組成元素的話，那么Small可能就不那么合適。我們考慮一下PBL 排序之后，會是怎樣的場景？這里看一下用戶故事的冰山模型。如果我們針對的用戶故事是在冰山底層的用戶故事，鑒于其優(yōu)先級較低，我們也不需要在一開始就將這些用戶故事細(xì)化與拆分，因此這類用戶故事不可能是Small的，只能是Size Appropriate。所以綜合來看，我個(gè)人是比較接受Size Appropriate這種說法。這種說法可以包含Small的場景，也考慮那些不需要很早就拆分的、較大的用戶故事。可測試的重要性毋庸多言，這是用戶故事驗(yàn)收標(biāo)準(zhǔn)的重要組成部分之一。
在我的經(jīng)驗(yàn)中，可測試至少要包含兩個(gè)要素：- 客觀性。所謂客觀性，從某個(gè)測試結(jié)果可以得到唯一的結(jié)論，即測試通過或者不通過，不存在不同人、不同時(shí)間用測試結(jié)果可以得到不同的結(jié)論；
- 可重復(fù)性。即這種測試不是一次性的，是可以重復(fù)驗(yàn)證與測試的。
好的用戶故事是幫助我們實(shí)現(xiàn)敏捷的重要的一步。如何寫好用戶故事是個(gè)技術(shù)活，沒有太多的捷徑。只能通過不斷訓(xùn)練才可以將用戶故事寫好，而INVEST 就是我們在練習(xí)寫好的用戶故事過程中重要的尺子。不斷利用這項(xiàng)工具，對自己的用戶故事進(jìn)行反復(fù)地改寫與練習(xí)，才能最終走向用戶故事得心應(yīng)手。
IDCF DevOps黑客馬拉松，獨(dú)創(chuàng)端到端DevOps體驗(yàn)，精益創(chuàng)業(yè)+敏捷開發(fā)+DevOps流水線的完美結(jié)合，2021年僅有的3場公開課，數(shù)千人參與并一致五星推薦的金牌訓(xùn)練營，追求卓越的你一定不能錯(cuò)過！9月11-12日，上海站，企業(yè)組隊(duì)參賽&個(gè)人參賽均可，一年等一回，錯(cuò)過等一年，趕緊上車~??
