為什么要來討論用戶故事

傳統(tǒng)瀑布模式下，往往先等產(chǎn)品經(jīng)理完成了產(chǎn)品PRD文檔，然后技術(shù)團(tuán)隊(duì)再根據(jù)這份PRD文檔實(shí)施開發(fā)。
在千變?nèi)f化的市場下，基于完整PRD的才進(jìn)行開發(fā)的模式遇到了挑戰(zhàn)，研發(fā)團(tuán)隊(duì)越重視小步快跑，快速迭代，靈活滿足不斷變化的環(huán)境。比如出現(xiàn)一下狀況：

• 階段規(guī)劃不合理，產(chǎn)品經(jīng)理編寫完整PRD文檔往往需要一定時間，在項(xiàng)目特定時間交付的情況下，勢必壓縮開發(fā)的時間，可能導(dǎo)致后續(xù)的工期緊張，加班加點(diǎn)完成工作。
• 需求響應(yīng)慢，特別是影響運(yùn)作業(yè)務(wù)的需求，如果沒有及時響應(yīng)，則會造成業(yè)務(wù)的損失，失去搶占市場的先機(jī)，如果是乙方團(tuán)隊(duì)，響應(yīng)慢也會降低客戶滿意度。
• 難以追溯需求源頭，產(chǎn)品研發(fā)是一個長時間的過程，可能做著做著就忘記了原來的需求了，技術(shù)和產(chǎn)品可能就開始了互懟。
• 缺乏對話，需求文檔不能承載所有的信息，而且文字的描述，理解起來各個人可能也有偏差，需求文檔不僅是一份文檔，它更是一種溝通工具，用它來讓大家達(dá)成共同的理解。
• 價值感低，軟件規(guī)格書或者產(chǎn)品PRD文檔，雖然是大而全的需求書，但更偏向于“如何實(shí)現(xiàn)”，而對“為什么這樣做”沒有足夠的描述和對話，也就沒有直接的價值感知。

用戶故事的概念

拆字理解，用戶故事=用戶+故事=人+故+事，通俗解釋，就是什么人因什么原因做某事。提煉出來就是三個要素，who、why、what。用這3個要素組成最簡單一句話的需求描述。

用戶故事的組成

用戶故事由三部分組成，簡稱3C原則：

• Card (卡片)
• Conversation (談話)
• Confirmation (確認(rèn))

1. Card (卡片)

作為(用戶角色)，我想要（產(chǎn)品特性或功能），以便于（實(shí)現(xiàn)利益）

卡片也稱為用戶故事卡，相信大家對于這個卡片很熟悉了，雖然大家未必按照這個格式寫用戶故事。但有些人心中把用戶故事等同于用戶故事卡 ，如果這樣理解，就會理解片面了，卡片只是用戶故事最明顯的表現(xiàn)方式，它并不是最重要的。加上后面的溝通和確認(rèn)才是完整的用戶故事。

image.png

2. Conversation (談話)

卡片代表客戶需求而不是記錄需求
卡片需要不斷談話澄清，以達(dá)成同樣的理解

用戶故事代表的是客戶最原始的需求，它并不是記錄大而全需求的地方?？ㄆ休d的是用戶需求故事，而需求細(xì)節(jié)則通過對話完成。
故事之所以是故事，它是用來講的，不是用來寫的。
比如一個卡片上代表一個用戶故事，它不是需求的全部，而組織相關(guān)干系人進(jìn)行細(xì)節(jié)討論，探討價值和場景，才是最重要的。
而對話往往不是一次性的，用戶故事是一個需求源頭，剛開始定義的時候可以對話，設(shè)計評審、技術(shù)評審，測試驗(yàn)收等環(huán)節(jié)都可以進(jìn)行對話。也就要求我們，對用戶故事進(jìn)行維護(hù)更新和持續(xù)迭代。
雖然我們常說的對話以口頭交流為主，但可以借助其它工具，比如業(yè)務(wù)流程圖、UI高保真圖等等，溝通的目的是我們對需求達(dá)成一致的理解和認(rèn)知。

3.Confirmation (確認(rèn))
用戶故事還包含“確認(rèn)”部分，也就是我們所說的“DoD”，“完成的定義”。這個DoD是大家共同討論出來的，是大家都愿意遵守的原則。
如果紙質(zhì)版的卡片，確認(rèn)部分就可以寫在故事的背面，即滿足了什么條件之下，這個用戶故事才算被滿足。

image.png

有了確認(rèn)條件，技術(shù)團(tuán)隊(duì)則更明確要測試什么，產(chǎn)品團(tuán)隊(duì)則可以確認(rèn)用戶故事是否達(dá)到預(yù)期和驗(yàn)收標(biāo)準(zhǔn)。
注意，這里的DoD不僅僅是功能性的，也包括非功能性，這往往我們?nèi)菀妆缓雎?，比如易用性、性能等方面的要求?br> 當(dāng)然確認(rèn)條件不是不變的，如果要調(diào)整驗(yàn)收條件，也勢必影響我們的范圍和工期，可能也要調(diào)整我們的迭代計劃。

用戶故事滿足的原則

一個好的故事要滿足INVEST原則：

• 獨(dú)立性（Independent）
• 可協(xié)商性(Negotiable)
• 有價值的(Valuable)
• 可估算的(Estimatable)
• 小的 (Small)
• 可測試的（Testable）

顧名思義，從字面上大家應(yīng)該都理解是什么意思了，這6個特性就不一一細(xì)講，用簡單的一句話講下這6個特性的好處。

1. 故事之間符合MECE原則，不交叉不重疊，要不然給測試和開發(fā)就帶來很大麻煩。
2. 用戶故事強(qiáng)調(diào)口頭溝通，人人都理解用戶故事。
3. 好的用戶故事傳遞價值，我們不是工具人，我們做的事情對于用戶來說是有價值的。
4. 不能估算可能是對業(yè)務(wù)還不理解，或者還沒有做詳細(xì)的設(shè)計，這些都是開發(fā)之前要去搞懂的東西。
5. 用戶故事不等于用例，太小的故事可以合并，太大的故事可以拆分。
6. 如果不能測試，也就沒辦法驗(yàn)收。

用戶故事的不足

講了這么多用戶故事的好處？那么它有不足嗎？
如果你分解了很多用戶故事，可能會發(fā)現(xiàn)它們是零散的，只見樹葉不見森林，這個時候就要用戶故事地圖來把故事串聯(lián)起來。
其次如果是大項(xiàng)目，則難以組織成千上萬的故事，此時就需要結(jié)合額外的文檔實(shí)現(xiàn)可追溯性。

本次分享到這里，有興趣的讀者可以閱讀原書，附上電子書鏈接《用戶故事與敏捷方法》