本文從「用戶故事」的概念、準(zhǔn)則、創(chuàng)建用戶故事地圖到建立用戶故事卡的方法無一不包，幫你完整掌握「用戶故事」這個(gè)知識(shí)點(diǎn)。
1. 什么是用戶故事？
- 迭代開發(fā)的一種工具；
- 代表了可開發(fā)的一個(gè)工作單元；
- 幫助我們跟蹤一個(gè)功能的生命周期。
2. 什么是用戶故事地圖？
- 一個(gè)有風(fēng)向的圖表；
- 橫軸為時(shí)間線，放置延時(shí)間線的用戶故事；
- 縱軸為優(yōu)先級(jí)，自上而下；
- 覆蓋所有用戶故事，表達(dá)需求全景。
3. 為什么使用用戶故事？
從設(shè)計(jì)賦能角度來講，用戶故事地圖可以幫助設(shè)計(jì)師從產(chǎn)品計(jì)劃層面，提升產(chǎn)品用戶體驗(yàn)，避免沉入細(xì)節(jié)之中；找到一種落地產(chǎn)品思維的方法，即平衡用戶價(jià)值、產(chǎn)品價(jià)值、開發(fā)成本三者的關(guān)系；關(guān)注項(xiàng)目和產(chǎn)品，設(shè)計(jì)出落地、有效的產(chǎn)品方案，避免理想化。
從項(xiàng)目管理角度，用戶故事地圖可以解決以下問題：
- 只見樹木不見森林，重要內(nèi)容埋沒在細(xì)節(jié)中，難以排列優(yōu)先級(jí)；
- 無法看到版本貢獻(xiàn)功能的完整價(jià)值流；
- 無法方便的使用迭代方法跟蹤、優(yōu)化內(nèi)容，確定版本計(jì)劃和目標(biāo)。
從團(tuán)隊(duì)協(xié)作角度，用戶故事可以降低溝通與達(dá)成共識(shí)的成本，將關(guān)注力更多集中在產(chǎn)品上。
4. 用戶故事簡述
- 作為一個(gè)（角色）：誰要使用這個(gè)功能。
- 為想要（功能）：需要完成什么樣的功能。
- 以便于（價(jià)值）：為什么需要這個(gè)功能，帶來什么樣的價(jià)值（用戶價(jià)值和組織價(jià)值）。
構(gòu)建用戶故事地圖需要：時(shí)間線、用戶活動(dòng)、用戶任務(wù)、用戶故事、故事地圖結(jié)構(gòu)。用于實(shí)現(xiàn)目標(biāo)的用戶功能 > 活動(dòng) > 任務(wù) > 史詩 > 故事。
- 將用戶要素從左向右拖動(dòng)到地圖的頂行。地圖頂行中的每個(gè)功能都是呼叫用戶活動(dòng)。
- 創(chuàng)建完成活動(dòng)所需的許多步驟，稱為用戶任務(wù)。
- 這些用戶任務(wù)中的每一個(gè)都可以分解為多個(gè)史詩。
- 在史詩下，可以定義用戶故事列表，其大小適合放入 sprint。
1. 用戶故事的3C原則
3C 原則是由 Ron Jeffries 提出的，它包括三個(gè)部分：
- Card 卡片，用來簡要描述軟件特性或改進(jìn)點(diǎn)；
- 描述的內(nèi)容簡潔、詞匯含義統(tǒng)一，項(xiàng)目成員不會(huì)對(duì)同一內(nèi)容有差異性理解；
- 這些卡片用于后續(xù)的溝通、對(duì)需求內(nèi)容的組織和排列優(yōu)先級(jí)。
Conversation 交談 ，與 Product Owner（或客戶）交談來明確細(xì)節(jié)。
- 卡片的內(nèi)容是由團(tuán)隊(duì)在溝通中獲得，而非由同一個(gè)人輸出或更新的，不然它與傳統(tǒng)的需求分析方法無異；
- 項(xiàng)目成員需要一起就卡片內(nèi)容進(jìn)行討論。在復(fù)雜邏輯中，梳理出清晰的需求脈絡(luò)，并在這一過程中，達(dá)到共識(shí)和理解的統(tǒng)一。
Confirmation 確認(rèn)，每個(gè)故事應(yīng)具有驗(yàn)收標(biāo)準(zhǔn)（驗(yàn)收條件），能夠確認(rèn)被正確完成。
- 以始為終，先行確認(rèn)以怎樣的結(jié)果，來判斷開發(fā)任務(wù)的完成；
- 它保證每個(gè)故事都是獨(dú)立的、完整的邏輯，可以單獨(dú)交付；
- 它為驅(qū)動(dòng)測試驅(qū)動(dòng)開發(fā)、行為驅(qū)動(dòng)開發(fā)和持續(xù)集成提供可能。
2. 用戶故事原則
- I 獨(dú)立的（Idependent）：獨(dú)立且完整，不依賴于其他任何用戶故事；
- N 可談判的（Negotiable）：引導(dǎo)團(tuán)隊(duì)跟干系人之間對(duì)話和談判的介質(zhì)。在任何時(shí)候，用戶故事都可以被改寫甚至丟棄。一個(gè)用戶故事不會(huì)像石頭一樣固定不變，直到它將要在接下來的 Sprint 里被實(shí)現(xiàn)；
- V 有價(jià)值的（Valuable）：需要將價(jià)值給干系人，不論是最終用戶還是采購者；
- E 可估算的（Estimable）：團(tuán)隊(duì)需要能夠粗略地估算出完成用戶故事所需工作量規(guī)模；
- S 小規(guī)模的（Small）：以一個(gè)大的「占位符」開始其生命周期。隨著時(shí)間的推移，當(dāng)人們對(duì)用戶故事所表達(dá)的愿望的復(fù)雜度更加了解時(shí)，這個(gè)較大的「占位符」就將被拆分成小的用戶故事。當(dāng)最重要的那些用戶故事將進(jìn)入 Sprint 被實(shí)現(xiàn)并交付時(shí)，它們需要變得足夠小，這樣才能在一個(gè) Sprint 里被完成。
- T 可測試的（Testable)）：一個(gè)用戶故事必須提供必要的信息，清楚地界定了故事的驗(yàn)收標(biāo)準(zhǔn)，這樣才能在它完成時(shí)判斷是否驗(yàn)收。
用戶故事地圖是一個(gè)用于需求收集的 4 級(jí)層次結(jié)構(gòu)。故事地圖從不同來源（即積壓）收集的用戶特征集合開始，這些用戶特征將通過執(zhí)行某些任務(wù)作為活動(dòng)來實(shí)現(xiàn)。這些任務(wù)可以轉(zhuǎn)換為史詩后，轉(zhuǎn)換為軟件開發(fā)的用戶故事。
1. 產(chǎn)品定義
一般是在故事編寫工作坊準(zhǔn)備階段，首先由 PD 主導(dǎo)產(chǎn)出，主要有幾點(diǎn)內(nèi)容：
- 產(chǎn)品的目標(biāo)用戶
- 解決了哪些問題
- 用戶目標(biāo)
- 產(chǎn)品目標(biāo)
2. 梳理骨干故事
寫出不同顆粒度的故事，需要設(shè)計(jì)師把控故事的大小，這段故事可以再往下梳理一層顆粒度更小一點(diǎn)的故事。這樣骨干故事就有兩層，一級(jí)故事和二級(jí)故事，故事的發(fā)生從左至右是一個(gè)敘事流。
3. 拆分故事
在剛剛梳理的每一個(gè)二級(jí)故事下面做停留，去拆分二級(jí)故事獲取更多細(xì)節(jié)內(nèi)容。項(xiàng)目組會(huì)圍繞這個(gè)故事寫出很多細(xì)節(jié)來。按照以下幾個(gè)維度對(duì)細(xì)節(jié)進(jìn)行歸類，分別是：故事細(xì)節(jié)、想法、痛點(diǎn)、機(jī)會(huì)、情緒。其中情緒可以通過固定的問題獲得，也可以通過用戶想法、用戶的痛點(diǎn)結(jié)合主觀判斷。
4. 溝通確認(rèn)
這里我們的故事已經(jīng)變得很豐滿，甚至變得臃腫，所以溝通確認(rèn)變得極為重要。我們?cè)谶@步需要花費(fèi)相對(duì)多的時(shí)間，大家對(duì)內(nèi)容進(jìn)行對(duì)標(biāo)、充足討論，把公認(rèn)的留下來，無用的剔除掉。同時(shí)可以區(qū)分要做的故事細(xì)節(jié)的優(yōu)先級(jí)。
卡與迭代的關(guān)系：
- 卡是迭代開發(fā)的一個(gè)工具；
- 卡代表了一個(gè)可以的工作單位；
- 幫助我們跟蹤一個(gè)功能的生命周期。
管理卡片：
- 估計(jì)工時(shí)
- 分配工作
- 追蹤進(jìn)度
如何使用？
- 書寫故事卡；
- 將卡放在墻內(nèi)（物理墻/數(shù)字墻）；
- 領(lǐng)卡需要與 QA/BA 澄清需求（一人不能有兩張正在做的卡）；
- 故事卡完成后需要做 Desck Check（block里的卡片要盡快消滅）。
IPM：Iteration Plan Meeting，迭代計(jì)劃會(huì)議主要是跟客戶保持溝通與信息更新的會(huì)議。
- 下一個(gè)迭代的 Story；
- 對(duì)下一個(gè)迭代的期望；
- 團(tuán)隊(duì)的人員可用性；
- 風(fēng)險(xiǎn)的評(píng)估總結(jié)。
敏捷宣言里面有一條：客戶協(xié)作優(yōu)于合同談判。在 Scrum 團(tuán)隊(duì)中有一個(gè)角色叫做產(chǎn)品負(fù)責(zé)人，他的核心職責(zé)是確保業(yè)務(wù)需求的清晰和透明，保證開發(fā)團(tuán)隊(duì)對(duì)業(yè)務(wù)有足夠的了解，并將這些待完成的業(yè)務(wù)需求（Story）按照優(yōu)先級(jí)排列出來，按照任務(wù)卡的方式來驅(qū)動(dòng)團(tuán)隊(duì)的開發(fā)。
IPM 的主要產(chǎn)出是下一個(gè)迭代中完成的 Story，這些 Story 即為下一個(gè) Story 要完成的目標(biāo)，通過敏捷看板工具來管理它們。
Sprint：業(yè)務(wù)流，Sprint1，Sprint2，Sprint3-N，已交付的故事。業(yè)務(wù)流就是史詩故事，每個(gè)史詩故事一個(gè)泳道。Sprint1，Sprint2，Sprint3-N 里面是不同史詩故事拆分出來的用戶故事，并且根據(jù)優(yōu)先級(jí)放到了不同的 Sprint 里面，橫向的泳道代表的是史詩故事和史詩故事拆分的子故事的對(duì)應(yīng)關(guān)系。
burn down chart：燃盡圖，一個(gè)sprint 內(nèi)，人/時(shí)是一個(gè)比較固定的值。在這個(gè)時(shí)間框架充分安排開發(fā)任務(wù)，每天進(jìn)行時(shí)間結(jié)算，繪制時(shí)間燃盡圖。項(xiàng)目成員通過燃盡圖獲知時(shí)間進(jìn)展，若項(xiàng)目燃盡所用時(shí)間與預(yù)期時(shí)間契合，則需求時(shí)間預(yù)估和安排合理，若不契合則需要在下一個(gè) sprint 進(jìn)行調(diào)整。
Retro（回顧）：即 retrospective 的簡寫，團(tuán)隊(duì)針對(duì)目前狀態(tài)總結(jié)，目的為保持好的方面及加強(qiáng)，做的欠佳的方面一起討論改進(jìn)措施，并盡力落實(shí)。在實(shí)踐中摸索出適合團(tuán)隊(duì)的最佳實(shí)踐，引導(dǎo)團(tuán)隊(duì)和個(gè)人不斷自我完善，追求卓越。
- 確認(rèn)構(gòu)建安全的環(huán)境；
- 建立幾項(xiàng)總結(jié)指標(biāo)（well，less well，suggestion，action）前三項(xiàng)列出看法，第四項(xiàng)針對(duì)前三總結(jié)；
- 一個(gè)點(diǎn)寫在一張便利貼，分欄貼上墻；
- 將同一類的問題歸納起來，總結(jié)出相應(yīng)的解決措施；
- Iteration 欄中的 sticker 指派并落實(shí)。
承擔(dān)因您的行為而導(dǎo)致的法律責(zé)任，
本站有權(quán)保留或刪除有爭議評(píng)論。
參與本評(píng)論即表明您已經(jīng)閱讀并接受
上述條款。