用戶故事之INVEST原則

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

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

Independent

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

Negotiable

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

Valuable

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

Estimable

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

Small

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

Testable

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