在敏捷開發(fā)過程中阴颖，我們經(jīng)常會聽到，用戶故事（user story）丐膝，我們也會用用戶故事的方式來拆解細化需求量愧，我們是否有想過钾菊，為什么用用戶故事，什么樣的用戶故事才算是用戶的故事偎肃？

為什么要有用戶故事

你是不是遇到或聽說過這樣的場景煞烫，用戶想要A，產(chǎn)品經(jīng)理理解為B累颂，開發(fā)同學理解為C红竭，各自討論達成一致之后，最終我們得到了一個完美無缺的D喘落，什么缺點都沒有茵宪，就是不是用戶想要的東西。因此瘦棋，我們需要一個叫用戶故事的東西稀火，作為基礎，我們可以一起討論赌朋，講需求從每個人的頭腦中可視化出來凰狞，從而更好的達成一致。

什么是好的用戶故事

好的用戶故事有他的標準在沛慢，3C原則赡若，INVEST原則。

01 3C原則

• 卡（Card）：用戶故事卡团甲，在一張卡片上能夠描述出主要需求逾冬，誰要做什么，產(chǎn)生什么價值

• 確認（Confirmation）：有驗收躺苦，有測試身腻，有完整的驗收表征能確認這個故事被正確的交付，價值得以實現(xiàn)

• 交談（Conversation）：用戶故事作為交談的基礎匹厘，必須所有細節(jié)面面俱到嘀趟，大家一起聊并達成一致，才是目的

圖片

02 INVEST原則

• 獨立（Independent）：每個用戶故事都是可以獨立交付的一個功能點愈诚，理想狀態(tài)下不依賴于任何別的功能她按，不過也有例外，在一些非常長的流程性功能下炕柔，一定是先做第一步操作酌泰，才有第二步，因此獨立也是相對的汗唱。這里的獨立宫莱，是獨立開發(fā)，獨立驗收哩罪，一些情況下授霸，獨立交付。

• 可討論（Negotiable）：用戶故事不是BRD际插，寫啥是啥碘耳，面面俱到，結(jié)合3C原則框弛，用戶故事是為了達成一致辛辨，不是為了定義標準，可以根據(jù)具體的技術(shù)實現(xiàn)一起討論瑟枫，最終達成一致的交付結(jié)果斗搞。

• 有價值（Valuable）：不用多說，任何一個功能點如果找不到對應價值慷妙，我們就應該思考他存在的意義了僻焚，因此價值，是做一切的先決條件膝擂。

• 可估算（Estimable）：作為開發(fā)的依據(jù)虑啤，以及排期管理依據(jù)，他一定是可以被估算的架馋，能估算的前提是我們有范圍（上面提到）狞山，可溝通，達成一致叉寂，估算才有意義

• 足夠衅计簟（Small）：小到可以在迭代內(nèi)流轉(zhuǎn)，不會一直停留在迭代的某一個泳道屏鳍，小是相對的伊约，需要平衡價值和獨立。

• 可測試（Testable）：場景需要相對完整孕蝉，流程也需要有完整節(jié)點屡律，這樣才能夠滿足測試。只有能夠測試降淮，才能確認功能的交付超埋。

他們的順序并不是INVEST，從價值的角度依次為VTSINE佳鳖。

怎樣寫一個合格的用戶故事

所謂好的用戶故事總是相似的霍殴，不那么好的用戶故事各有各的特色。在我們?nèi)粘Ｗ疃嗟挠脩艄适轮邢捣裕吹阶疃嗟钠鋵嵤荌NVEST中的T（testable）来庭，在As a, I want to, so that后面，跟著的是驗收標準（Acceptance Cretirial）, 有了驗收標準穿挨，才是可執(zhí)行的用戶故事月弛。因此肴盏，在說什么是好的之前，我們先說說什么是不好的帽衙，一起樂呵樂呵菜皂，切忌對號入座。

需求：物品加入購物車
案例1：開發(fā)文檔拆寫類
AC1: 物品展示頁下發(fā)展示 加入購物車按鈕厉萝，點擊后物品被加入購物車恍飘，數(shù)量加1
AC2: 點擊購物車按鈕，展示購物車頁面谴垫，展示加入物品
AC3:加入失敗章母，展示通知：加入失敗請重試
AC4: 場景：瀏覽物品，搜索結(jié)果翩剪，首頁
案例2：論文類
AC1: 用戶可以看到加入購物車的按鈕
Given：用戶在瀏覽物品詳情頁面
When：用戶看到最下方
Then：用戶可以看到一個黃色的按鈕上面寫著加入購物車且在頁面的右下角
AC2:如果用戶點擊了加入購物車按鈕乳怎，則商品可以被加入購物車
Given:用戶在物品詳情展示的頁面停留
When：用戶想要加入購物車并點擊了加入購物車按鈕
Then：用戶看到物品被加入到購物車病情購物車數(shù)量加1
AC3:加入失敗，展示通知：加入失敗請重試
Given:網(wǎng)絡不穩(wěn)定或者其他不穩(wěn)定因素出
When：用戶想要加入購物車并點擊了加入購物車按鈕
Then：用戶會看到一個通知肢专，通知告訴他加入失敗請重試舞肆，他可以點擊知道了關閉頁面，也可以點擊關閉關閉通知
案例3：混合類
案例1 和 案例2 任意組合出來

上面三種用戶故事博杖，是我見到最多的用戶故事椿胯，他們也能準確的表達出要實現(xiàn)的內(nèi)容（當然，實現(xiàn)內(nèi)容都說不清楚的剃根，就不在這里列了哩盲，大概率例子列不下），但是他們是用戶的故事么狈醉？從案例的名字其實就能看出來廉油，案例1 其實就是拆分寫了下需求文檔，它并不是一個用戶故事苗傅，案例2是用戶故事抒线，是一個啰嗦的用戶，抓不住重點的用戶渣慕。

那嘶炭，到底如何判斷？那到底什么才是一個好的用戶故事逊桦？先舉個例子眨猎，當然，當然也只是個例子强经，并不是毫無破綻的例子睡陪。

需求：物品加入購物車
As 消費者
I want to將物品加入購物車
So that 可以讓我在購物車看到我想購買的東西，支持后續(xù)的合并付款
AC1:消費者可以看到加入購物車按鈕
Given: 我在商品列表/商品詳情頁/商品搜索結(jié)果頁
When：我查看商品
Then：我會看到加入購物車按鈕 （見設計圖）
AC2: 消費者可以將物品加入購物車
Given：我查看商品并看到加入購物車按鈕
When：我點擊按鈕
Then: 我可以看到
1. 商品被加入購物車
2. 購物車商品數(shù)量加1
3. 購物車頁面有這個商品
AC3: 失敗處理
Given:網(wǎng)絡原因或其他原因?qū)е录尤胧?/em>
When：消費者點擊加入購物車按鈕
Then：消費者可以
1. 看到消息：“加入失敗，請重試”
2. 點擊關閉/知道了按鈕 關閉消息