用戶故事之INVEST原則

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

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

Independent

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

Negotiable

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

Valuable

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

Estimable

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

Small

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

Testable

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