為什么要來討論用戶故事
在傳統(tǒng)研發(fā)模式下友题，特別是在一些小型的產(chǎn)品研發(fā)領(lǐng)域，產(chǎn)品經(jīng)理往往會編寫一份產(chǎn)品需求文檔（PRD），然后技術(shù)團隊再依照于這個PRD文檔來做開發(fā)改基。
這種基于PRD的開發(fā)方式在當前市場變化越來越快阳液，研發(fā)組織越來越追求小步快跑的產(chǎn)品發(fā)布節(jié)奏的環(huán)境下遇到了很多挑戰(zhàn)：
- 產(chǎn)品編寫一份PRD往往需要很長的時間（產(chǎn)品默認都會追求編寫一份完整的需求文檔怕敬，要考慮到方方面面），考慮到互聯(lián)網(wǎng)非常緊張的產(chǎn)品發(fā)布周期壓力帘皿，技術(shù)團隊會抱怨產(chǎn)品需求給得太晚东跪，留給技術(shù)的開發(fā)時間太短。
- 整體的開發(fā)周期長鹰溜，獲取用戶反饋也就晚虽填。完整的產(chǎn)品需求也就可能導(dǎo)致只能完整的交付，當然曹动，這個也和下面第三點有關(guān)斋日。
- PRD內(nèi)容的豐富同時造成了優(yōu)先級不清晰。雖然PRD里也會標注有優(yōu)先級墓陈，但是因為里面需求的數(shù)量龐大并且相互交織依賴恶守，最后的結(jié)果就是高優(yōu)先級的需求太多竭恬，優(yōu)先級不能細化導(dǎo)致失去價值。
- 缺少對話熬的。需求文檔不可能承載所有需求信息痊硕，而且由于描述的角度，容易造成誤解押框。所以需求不僅僅只是一份文檔岔绸，它更應(yīng)該是一個溝通的工具，可以用來幫忙大家對特性的理解達成一致橡伞。
- 后期調(diào)整需求成本高盒揉，但不幸的是在隨著產(chǎn)品形態(tài)不斷的顯露出來的時候，需求的調(diào)整是不可避免的兑徘。而且過早的決策刚盈，需求調(diào)整的可能性只會更高。
為了解決這些問題挂脑，使用用戶故事的方法來表述需求逐漸流行起來藕漱。
本文試圖從非常基礎(chǔ)的角度解釋什么是用戶故事崭闲。
什么是用戶故事
用戶故事一共包含三個部分肋联，簡稱3C模型：
- Card（卡片）
- Conversation（會話）
- Confirmation（確認）
1.Card
作為<用戶角色>，我想要<產(chǎn)品特性>刁俭，這樣可以<價值或收益>橄仍。
這個卡片形式已經(jīng)是家喻戶曉的了（雖然大家不一定都能按這個來做），甚至當大家提到“用戶故事”的時候也就只記得這個卡片了牍戚，在很多人心中卡片和用戶故事是等同的侮繁。但顯然這樣是片面的，這樣的理解就只是得其形而失其神如孝。
卡片僅僅是用戶故事最明顯的表現(xiàn)形式宪哩，但他不是最重要的。
2.Conversation
卡片代表客戶需求而不是記錄需求暑竟。
同樣一份文檔或卡片斋射，閱讀的人不同，各自得到的信息也不一樣但荤。
卡片包含故事的文字描述罗岖，然而需求細節(jié)要在對話中獲得。故事之所以叫故事腹躁，因為它是要講而不是要寫的桑包。
說得通俗一點就是一張卡片只是代表了一個需求，但它遠遠不是需求的全部纺非，相關(guān)干系人一起在對話中發(fā)現(xiàn)并探索需求的細節(jié)哑了，這個才是更重要的赘方。
對話肯定不是一次性的，而是持續(xù)的深度交談：寫故事的時候會有對話弱左，宣講的時候又有一次窄陡，估算的時候再有一次，迭代計劃會議的時候還會有拆火，迭代中在軟件設(shè)計跳夭，構(gòu)建和測試的時候都會有。
盡管我們說對話主要是依靠口頭語言交流發(fā)生的们镜，單我們?nèi)匀唤?jīng)常借助于文檔的方式做說明或記錄：比如一張PS的效果圖币叹，一張畫在白板上的交互邏輯照片，引用某篇文檔中規(guī)范內(nèi)容的鏈接模狭，等等颈抚。
3.Confirmation
用戶故事還要包含確認信息，作為接收標準（或確認條件）嚼鹉。這和“完成的定義”（DoD）非常像贩汉，只不過DoD更偏向哪些general的和流程化的事項。
如果我們使用的物理化的卡片的話反砌，正面寫的是story的描述雾鬼，那么背面就很適合寫上確認條件萌朱。
有了確認條件宴树，開發(fā)和測試團隊就能更好的理解要構(gòu)建和測試的是什么，產(chǎn)品團隊可以確認用戶故事的實現(xiàn)是否和服預(yù)期晶疼。
“確認條件”最遲是需要在迭代planning meeting上確定的酒贬，很明顯，這個是story估算的重要依據(jù)之一翠霍。但是我們不保證確認條件不會發(fā)生變化锭吨，但前提是調(diào)整和變化不會影響本次迭代的交付，如果真的有大的影響寒匙，我們就要馬上調(diào)整我們的迭代計劃（re-planning）零如。
確認條件在某種程度上也能看成驗收條件，是story的測試要點锄弱，很自然的我們就想到了敏捷的另一種實踐：接收測試驅(qū)動開發(fā)（ATDD）考蕾。
關(guān)于“接收測試驅(qū)動開發(fā)”和“實例化需求”，我們以后再談会宪。
好故事需要滿足的原則
一個好的故事需要滿足INVEST標準：
- 獨立的（Independent）
- 可協(xié)商的（Negotiable）
- 有價值的（Valuable）
- 可估算的（Estimatable）
- 小的（Small）
- 可測試的（Testable）
我不太想用長篇大論來一一介紹這六個好故事特征（不然篇幅太長）肖卧，這里我只用最簡單的一句話來描述各個特征的好處：
- 不獨立的故事會對優(yōu)先級的排列和測試帶來巨大的麻煩；
- 故事不是合同掸鹅，故事只是占位符塞帐，它提醒我們需要更多的去對話和協(xié)商拦赠；
- 卡片的三段式寫法本身就是要強調(diào)價值的，這里要強調(diào)的是價值是對用戶和客戶來說的葵姥，我們要盡量避免做只是對開發(fā)團隊有價值的故事荷鼠；
- 不能估算的故事要么是對業(yè)務(wù)還沒理解，要么是團隊缺少相應(yīng)的技術(shù)實力榔幸，要么就是太大颊咬，總之這些都是要在開發(fā)之前解決的問題；
- 小是必須的牡辽，但是太小也不是不能合并一下喳篇，總之大小要合適；
- 如果不能測試态辛，就不能證明它是完成的麸澜。
有興趣深入探討的話可以自己google或者參考Mike Cohn的《用戶故事與敏捷方法》。
非功能性需求
非功能性的需求往往包含安全性奏黑、可靠性炊邦、互操作性、健壯性熟史、易使用性馁害、可維護性、可移植性蹂匹、可重用性碘菜、可擴充性、實驗性等限寞，一般反應(yīng)了系統(tǒng)的約束忍啸，而非系統(tǒng)特定行為的需求。
- 對于非功能性需求我們?nèi)匀幌Ｍ馨凑展适碌慕Y(jié)構(gòu)來編寫它履植，這樣能幫助我們理清這些需求的價值计雌，這往往是容易忽略的；
- 非功能性需求往往是跨所有功能性需求的玫霎，一旦你完成了一個非功能性需求凿滤，那么在以后的迭代中你要始終關(guān)注這個非功能性需求以防止它被影響而失效。那該怎么辦呢庶近？
- 考慮把非功能性的要求放到每一個功能性需求DoD中去翁脆，在一開始就考慮到系統(tǒng)的各種限制
- 或者和PO約定，哪些迭代里需要對非系統(tǒng)性需求做驗證和維護
Story mapping
使用story的形式做需求管理最被人詬病的就是拦盹，相對于大而全的PRD鹃祖，story是“只見樹木，不見森林”。用戶故事地圖（user story mapping）的是給這個問題一個解決辦法恬口。
用戶故事地圖校读，就是在講大故事的同時進行拆分。
對于story mapping暫時就不在這篇文章中詳細描述了祖能，后續(xù)會單獨開一片story mapping的小文歉秫。
