大家好，我是來自IT修真院的一枚PM~~今天和大家來分享一下PM基本功之用戶故事。
大綱:
一、用戶故事在整個開發(fā)中的位置
二、用戶故事是什么？
三、如何編寫一個優(yōu)秀的用戶故事？
四、故事優(yōu)先級
---------------------------------------------------------------------
一、用戶故事在整個開發(fā)中的位置
用戶故事是敏捷開發(fā)中一個十分重要的環(huán)節(jié)，他幫助我們高效的收集客戶真正的需求。
用戶故事是敏捷計劃于估算的重要基礎(chǔ)
是需求的基本形態(tài)
軟件開發(fā)起始于需求收集與分析，如果一開始需求弄錯了，軟件的成功也無從談起。
用戶故事貫穿整個開發(fā)流程。首先產(chǎn)品負責(zé)人根據(jù)收集來的需求編寫用戶故事，放入產(chǎn)品代辦事情集中。baclog
在迭代（sprint計劃會議）中，團隊成員討論其中的一些用戶故事，細化細節(jié)，確定驗收標準，使用planning poker估算故事點。然后，將故事分成一些小的任務(wù)，并估算工作時間。最后，講故事放入（sprint backlog）迭代待辦事項中，并按優(yōu)先級排序。任務(wù)完成后，將任務(wù)挪到done欄。
?團隊盡可能的完成優(yōu)先級高的故事。
---------------------------------------------------------------------
二、用戶故事是啥？
用戶故事包含：
一份書面的故事描述
有關(guān)故事的對話，用于細化細節(jié)
測試，用于確定故事何時完成
下面我們一個一個來講：
1.書面的故事描述
ron jeffries提出3c - card/conversation/ confirmation
卡片記錄的是客戶/用戶 需求而不僅僅是記錄需求-也就是說：卡片包含故事的文字描述、然而需求細節(jié)需要在與客戶的“對話”中獲得，并在“確認”部分得以記錄。
用戶故事的表達形式：
三要素大法：as a ….(role)I want…. so that ...
2.用戶故事的細節(jié)：
也就是顆粒度
以智聯(lián)招聘為例：
1.用戶可以搜索工作
2.公司可以發(fā)布職位
雖然求職網(wǎng)站的智能說到底就是這兩大點，但顯然這并不是一個好的用戶故事，為毛呢？對于開發(fā)來說太龐大太模糊了，實際工作中沒有任何知道意義。
那腫么辦？
epic史詩故事
當(dāng)一個故事很大的時候就稱之為史詩故事，他可以拆成更多的小故事。舉個栗子，“用戶可以搜索工作”可以分如下：
1.用戶可以通過地區(qū)、薪水范圍、職位、公司名、發(fā)布日期等來搜索工作
2.用戶可以查看搜索結(jié)果中每個工作的信息
3.用戶可以查看發(fā)布工作的公司的信息
巴特！
拆分并不是沒完沒了的，不需要覆蓋每一個細節(jié)。再舉個栗子
“用戶可以查看搜索結(jié)果中每個工作的信息”就很OK，不需要再拆成-
用戶可以查看工作描述
用戶可以查看薪水范圍
用戶可以查看工作地點
為毛不需要這么的細節(jié)，有人會覺得這樣很好啊出來的效果就是我設(shè)計的那樣啊不會有差別啊，我個人理解是 1）互聯(lián)網(wǎng)產(chǎn)品迭代快，你永遠無法精準的預(yù)知產(chǎn)品上線時（幾個月后）的市場行情，與其有時間細化倒不如加快開發(fā)進程。畢竟很多時候，用戶也并不知道自己到底需要什么==！??2）一個產(chǎn)品包含很多個功能，所以也有很多個細節(jié)。高效的做法是，當(dāng)我知道這個細節(jié)變得重要時，再去和客戶討論。
3.“什么時候完成？”
其實指的是開發(fā)人員了解用戶的期望，從而以驗收測試的形式被記錄下來。
比如：
用空的工作描述來試試
用缺少薪資來試試
用6位數(shù)薪資來試試
些測試描述是為了便于開發(fā)人員預(yù)估故事于什么時候結(jié)束。通過測試驗收是否達到了客戶的期望，變能知道什么時候完成了客戶要求的功能。
就好像老師告訴我們什么時候交作業(yè)一樣。
---------------------------------------------------------------------
三、怎么寫好一個優(yōu)秀的用戶故事？
INVEST原則
一、獨立的
不獨立會造成什么后果？排列優(yōu)先級的時候或者預(yù)估時間的時候會導(dǎo)致一定的混亂。
繼續(xù)智聯(lián)招聘的栗子，假設(shè)現(xiàn)在編寫客戶公司如何對發(fā)布職位進行付費的故事：
1.公司可以通過visa信用卡對發(fā)布職位付費
2。公司可以通過masteracrd卡對發(fā)布職位付費
3.公司可以通過美國運通卡對發(fā)布職位付費
這時候開發(fā)估計完成第一種信用卡的開發(fā)需要3天（未指明哪種信用卡），對第二第三種信用卡各需要1天，問題來了，到底應(yīng)該給那種信用卡預(yù)估3他的時間？
出現(xiàn)這種問題，可以將這些相互依賴的故事進行合并。
此時，這三個故事就合并成：
1.公司可以用信用卡對發(fā)布職位進行付費
如何判斷合并的顆粒度是否正確？就看這個合并后的故事的預(yù)估時間是否超過5天。如果超過了，就找別的維度。
二、可討論的
用戶故事是可以討論的。用戶故事的細節(jié)是在用戶與開發(fā)團隊的討論中產(chǎn)生的。
這里需要注意的是，故事卡并不是需求本身，它是功能的簡短描述，他的作用是提醒客戶和開發(fā)在以后要進行關(guān)于需求的對話，這也就是為什么故事卡不包含細節(jié)，細節(jié)將在客戶團隊和開發(fā)的討論中產(chǎn)生。另外，還有兩點就是：細節(jié)過多時也會喧賓奪主讓人們過多的關(guān)注細節(jié)；且給予開發(fā)一種不需要和客戶討論的錯覺。
三、對用戶或客戶有價值的
！！“保證每個故事必須對用戶有價值”
比如避免寫一些只對開發(fā)人員有用的用戶故事
所以用戶故事最好是讓客戶來編寫故事，也就是說pm必需做好需求分析
四、可估計的
主要針對開發(fā)而言。
五、小的
故事的大小很關(guān)鍵，過大過小都會拖累進度。
當(dāng)故事過大時。。。分割故事？
比如之前智聯(lián)招聘的例子，針對epic story“用戶可以發(fā)布她的簡歷”，我們發(fā)現(xiàn)：
這個故事的主要行為“發(fā)布簡歷”包含以下幾個點：
-簡歷包含的內(nèi)容：教育背景、工作經(jīng)歷、薪資等
-用戶可以將簡歷表為非激活狀態(tài)
-用戶可以有多份簡歷
-用戶可以修改簡歷
-用戶可以刪除簡歷
那么針對這個epic我們可以這樣拆分：
-用戶可以創(chuàng)建簡歷，包含“教育背景、工作經(jīng)歷等”
-用戶可以修改簡歷
-用戶可以刪除簡歷
-用戶可以有多份簡歷
-用戶可以激活簡歷，也可以讓簡歷失效
如下的拆分方式就會過于細節(jié)化也就是過小：
-求職者可以在簡歷上輸入每段教育背景的日期
-求職者可以在簡歷上輸入每段工作經(jīng)歷的日期
-求職者可以在簡歷上添加照片
最終還是取決于對產(chǎn)品的了解以及技術(shù)實現(xiàn)方式
六、可測試的
通過測試開發(fā)人員才能證明確實實現(xiàn)了故事。
那是不是會有不可測試的故事？有，基本會是一些非功能性的故事比如。。。用戶覺得這個軟件很好用^^
---------------------------------------------------------------------
四、故事優(yōu)先級-仍待探討中...
法一：莫斯科法則，就是Must or Should， Could or Would not。在排用戶故事優(yōu)先級的時候，把用戶故事按以下4種類別排優(yōu)先級。
Must：這個迭代一定要做的。比如前面提到的“必需”的功能。
Should：應(yīng)該做，但若沒時間就算了。比如前面提到的“不太需要的”功能。
Could：不太需要的，但有了更好。比如前面提到的“幾乎早期版本中不要”的功能。
Would Not：明確說明這個功能不需要做，切勿把功能放到Must，Should or Could里。
法二：
基本型需求
期望型需求
興奮型需求
