用戶故事之INVEST原則

敏捷團(tuán)隊(duì)在落地產(chǎn)品精益需求管理時(shí)，常常會(huì)引入用戶故事這個(gè)實(shí)踐，大家對(duì)于用戶故事的概念應(yīng)該都容易理解，實(shí)際上作為需求的一種表達(dá)方式，通過(guò)一張卡片來(lái)承載用戶需求。那么這么樣才能拆分出一個(gè)好的用戶故事，卻不是輕易就能夠做到的，為此，極限編程的倡導(dǎo)者Bill Wake提出了用戶故事的INVEST原則，指導(dǎo)我們?nèi)ゲ鸱趾蛯?xiě)出一個(gè)好的用戶故事。

哪我們就來(lái)了解下，到底什么是INVEST原則?INVEST實(shí)際上六個(gè)英文的首字母縮寫(xiě)：

Independent

Independent，獨(dú)立的，是指拆分后的用戶故事相對(duì)獨(dú)立，能夠一個(gè)一個(gè)的進(jìn)行單獨(dú)開(kāi)發(fā)，不具有強(qiáng)偶合性。比如，我們?cè)诓鸱忠韵乱粋€(gè)關(guān)于電子記事本的功能時(shí)，團(tuán)隊(duì)考慮拆分的故事中包括編輯和刪除兩個(gè)功能，實(shí)際上著2個(gè)功能就可以拆分成2個(gè)獨(dú)立的故事，分別進(jìn)行開(kāi)發(fā)。但是切記不可能將同一個(gè)業(yè)務(wù)功能，基于開(kāi)發(fā)技術(shù)棧的不同拆分成前后端來(lái)實(shí)現(xiàn)，這就不是一個(gè)獨(dú)立的故事，也違反了故事可測(cè)試的原則，也是我們盡量要避免的。

Negotiable

Negotiable，可協(xié)商的，故事并不不在一開(kāi)始鎖定太多細(xì)節(jié)，從故事卡所隱藏的背后含義我們也容易了解，一張卡片中是無(wú)法包含太多的細(xì)節(jié)內(nèi)容的。所以這就要求在用戶故事溝通的過(guò)程中，第一，用戶故事符合遠(yuǎn)粗近細(xì)的原則，避免在一開(kāi)始就引入太多的細(xì)節(jié)設(shè)計(jì)，使得相關(guān)人員誤以為這個(gè)需求已經(jīng)是非常明確的，不需要再展開(kāi)討論;第二，故事卡本身就是一個(gè)溝通的工具，希望借此工具我們能夠及時(shí)、面對(duì)面的溝通，從而避免細(xì)節(jié)遺漏;還有一點(diǎn)，很多故事是隨著對(duì)業(yè)務(wù)需求對(duì)場(chǎng)景的理解而不斷深化的，所以在迭代開(kāi)始前，我們后希望能夠獲取到更多的細(xì)節(jié)，將用戶故事不斷完善，最終開(kāi)發(fā)的功能是客戶真正想要的。

Valuable

Valuable，有價(jià)值的，必須是有價(jià)值的。這條原則在整個(gè)INVEST原則中是最重要的一條，故事必須有價(jià)值，否則我們?yōu)槭裁匆鏊?？這一點(diǎn)其實(shí)通過(guò)20/80原則就能得到驗(yàn)證。不知道到大家有沒(méi)有嘗試統(tǒng)計(jì)過(guò)我們自己手機(jī)的APP，試著將每天都用到的APP數(shù)量比上所有APP數(shù)量，看看能夠得到一個(gè)什么結(jié)論，你會(huì)發(fā)現(xiàn)：我們每天常用的功能，竟然不到20%！也就是說(shuō)超過(guò)80%的功能你從來(lái)沒(méi)用過(guò)。所以這也是我們?yōu)槭裁丛诔薪佑脩粜枨?、拆分用戶故事的時(shí)候，一定要明確這個(gè)故事是由價(jià)值，我們做的無(wú)意義的功能太多了，對(duì)于各種資源來(lái)說(shuō)都是一種浪費(fèi)。

Estimable

Estimable，可估算的，故事是可以估算大小的。為什么要是可估算的呢?有兩方面原因，一是可估算的故事有助于我們進(jìn)行迭代計(jì)劃排期，團(tuán)隊(duì)有多少資源，我們能做多少故事，有估算的故事便于我們內(nèi)外部協(xié)調(diào)資源、計(jì)劃排期;二是可估算的故事其實(shí)可以幫助我們進(jìn)一步澄清需求、降低風(fēng)險(xiǎn)，通過(guò)對(duì)故事工作量的評(píng)估，清楚這個(gè)故事的范圍、識(shí)別要做的事情。如果估算不了，很可能有兩方面的問(wèn)題：一故事顆粒度太大，無(wú)法估算，比如說(shuō)，產(chǎn)品經(jīng)理告訴你，我們需要做一個(gè)線上購(gòu)物平臺(tái)，這個(gè)什么概念，一個(gè)購(gòu)物平臺(tái)，很可能就是另一個(gè)京東、拼多多、淘寶，你無(wú)法評(píng)估需要投入資源去完成;第二點(diǎn)，無(wú)法估算可能是含有未知信息，不足以支撐進(jìn)行估算，如果我們?nèi)鄙儆行У男畔?，不知道需求的業(yè)務(wù)背景、不知道采用什么技術(shù)棧，是不是也很難做出估算。所以通過(guò)估算也是以另外一種方式幫助我們完成風(fēng)險(xiǎn)識(shí)別。

Small

Small，顆粒度小的(也有翻譯成 Size appropriate，大小適中的)，實(shí)際上都同樣的要求，大小顆粒度是合適，以便于在一個(gè)Sprint里能夠完成。對(duì)于為期2周一個(gè)迭代來(lái)講，小于3~5天的顆粒度是合適的，盡量不要超過(guò)5天。這一點(diǎn)也很容易理解，合適的顆粒度大小有助于我們做好迭代計(jì)劃，進(jìn)行開(kāi)發(fā)過(guò)程的風(fēng)險(xiǎn)管控。試想，如果故事的顆粒度比較大，一個(gè)故事的大小工作量需要5、6天，甚至超過(guò)一周，那就意味著測(cè)試的工作很可能都被推遲到迭代第二周才能開(kāi)始啟動(dòng)，一方面造成測(cè)試資源不匹配，第一周無(wú)事可做，第二周忙到起飛;另一方面也不能盡早的展開(kāi)測(cè)試驗(yàn)證，風(fēng)險(xiǎn)未能及時(shí)暴露出來(lái)。甚至有的故事大小需要跨迭代才能完成，很顯然這樣的顆粒度大小就是不合適的，需要進(jìn)一步評(píng)估。

Testable

Testable，可測(cè)試的，故事是可以進(jìn)行測(cè)試的，否則無(wú)法確認(rèn)故事是否已經(jīng)達(dá)成預(yù)期。對(duì)于一個(gè)獨(dú)立的故事，如果沒(méi)有辦法進(jìn)行測(cè)試，則意味著開(kāi)發(fā)人員也不知道到底要就該故事開(kāi)發(fā)到什么程度，而測(cè)試人員更是無(wú)法入手。比如說(shuō)在一個(gè)需求要求對(duì)系統(tǒng)性能進(jìn)行優(yōu)化，如何沒(méi)有清晰的測(cè)試范圍，這個(gè)故事是無(wú)法進(jìn)行驗(yàn)收的，這時(shí)候我們就需要考慮定義需求的范圍、細(xì)化驗(yàn)收標(biāo)準(zhǔn)，如頁(yè)面加載提升到2s以內(nèi)，這就是我們對(duì)性能優(yōu)化的最終結(jié)果，是具有可測(cè)試性的。當(dāng)然可測(cè)試是有多種手段的，并不是純粹的手工測(cè)試、界面測(cè)試等。有些技術(shù)性的故事卡，對(duì)于測(cè)試人員來(lái)說(shuō)，確實(shí)沒(méi)有辦法進(jìn)行手工測(cè)試，但是這并不意味著這個(gè)故事不具備可測(cè)試性，或許我們需要借助于其他的測(cè)試手段。