用戶故事(一):什么是用戶故事?
用戶故事在軟件開發(fā)過(guò)程中被作為描述需求的一種表達(dá)形式;為了規(guī)范用戶故事的表達(dá),便于溝通;包含角色、活動(dòng)、價(jià)值三個(gè)要素。
一、用戶故事的概念
概念這種東西我喜歡說(shuō)文解字的方式去理解和闡述;用戶故事=用戶+故事=人+故+事,那就是一個(gè)人因?yàn)槭裁丛蛞鍪裁词拢釤挸鰜?lái)三要素就是who、why、what。從需求角度描述就是一個(gè)用來(lái)確認(rèn)用戶和用戶需求的簡(jiǎn)短描述。
二、用戶故事的三要素
用戶故事在軟件開發(fā)過(guò)程中被作為描述需求的一種表達(dá)形式。為了規(guī)范用戶故事的表達(dá),便于溝通,用戶故事通常的表達(dá)格式為:作為一個(gè)<用戶角色>, 我想要<完成活動(dòng)>, 以便于<實(shí)現(xiàn)價(jià)值>。
一個(gè)完整的用戶故事包含三個(gè)要素:
- 角色(who):誰(shuí)要使用這個(gè)
- 活動(dòng)(what):要完成什么活動(dòng)
- 價(jià)值(value):為什么要這么做,這么做能帶來(lái)什么價(jià)值
三、3C原則
用戶故事的描述信息以傳統(tǒng)的手寫方式寫在紙質(zhì)卡片上,所以Ron Jeffries(2001)對(duì)這三個(gè)方面稱為3C:卡片(Card)、對(duì)話(Conversation)和確認(rèn)(Confirmation)。
(1)卡片(Card):用戶故事一般在小卡片上寫著故事的簡(jiǎn)短描述,規(guī)則和完成標(biāo)準(zhǔn)。
卡片的正面書寫故事的描述,格式為:作為一個(gè)<角色>, 我想要<完成活動(dòng)>, 以便于<實(shí)現(xiàn)價(jià)值>描述需求;卡片背面書寫完成用戶故事的規(guī)則和完成標(biāo)準(zhǔn),格式為:Given…When…Then。
(2)交談(Conversation):用戶故事背后的細(xì)節(jié)來(lái)源于和客戶或者產(chǎn)品負(fù)責(zé)人的交流溝通;確保各方對(duì)故事的理解正確。
(3)確認(rèn)(Confirmation):通過(guò)驗(yàn)收測(cè)試確認(rèn)用戶故事被正確完成。
四、INVEST原則
好的用戶故事除了格式規(guī)范,要素完整外,還應(yīng)該遵循INVEST原則:Idependent(獨(dú)立的);Negotiable(可協(xié)商的);Valuable(有價(jià)值的);Estimatable(可評(píng)估);Small(小的);Testable(可測(cè)試的)。
1. Idependent(獨(dú)立的)
要盡可能的讓一個(gè)用戶故事獨(dú)立于其他的用戶故事。用戶故事間保持獨(dú)立性不僅便于排列和調(diào)整優(yōu)先級(jí),使得發(fā)布和迭代計(jì)劃更容易制定,便于獨(dú)立地理解、跟蹤、實(shí)現(xiàn)、測(cè)試以及頻繁交付,也使得用戶故事的大小估算所涉及的范圍更清晰,從而估算偏差更小。
2. Negotiable(可協(xié)商的)
一個(gè)用戶故事的內(nèi)容要是可以協(xié)商的,用戶故事不是合同。一個(gè)用戶故事只是對(duì)用戶故事的一個(gè)簡(jiǎn)短的描述,不包括太多的細(xì)節(jié);具體的細(xì)節(jié)在溝通階段產(chǎn)出。一個(gè)用戶故事帶有了太多的細(xì)節(jié),實(shí)際上限制了用戶、團(tuán)隊(duì)的想法和溝通。
3. Valuable(有價(jià)值的)
每個(gè)故事必須對(duì)客戶具有價(jià)值(無(wú)論是用戶、購(gòu)買方還是公司內(nèi)部角色)。用戶故事對(duì)于最終的用戶是有價(jià)值的,因此應(yīng)該站在用戶的角度去編寫,描述的是一個(gè)一個(gè)的feature,而非一個(gè)一個(gè)的task。
這個(gè)特點(diǎn)促進(jìn)團(tuán)隊(duì)的開發(fā)和測(cè)試成員由傳統(tǒng)的指令式工作方式向自驅(qū)動(dòng)的價(jià)值導(dǎo)向工作方式轉(zhuǎn)變,使團(tuán)隊(duì)中的每個(gè)人知道自己每天做的工作價(jià)值。
4. Estimatable(可評(píng)估)
計(jì)劃會(huì)議里面一個(gè)很重要的環(huán)節(jié),那就是故事點(diǎn)的估計(jì)。實(shí)際上就是對(duì)要開發(fā)的User Story進(jìn)行一個(gè)粗量級(jí)的估算,以便于團(tuán)隊(duì)能夠知道這個(gè)user story的復(fù)雜度(工作量)。
重點(diǎn)放在當(dāng)前迭代里能否按照該用戶故事的接收條件和團(tuán)隊(duì)定義的DoD(完成標(biāo)準(zhǔn))來(lái)完成這個(gè)用戶故事,如果不能完成,給出理由,由PO來(lái)決定是否拆分或者重新設(shè)計(jì)用戶故事。
讓開發(fā)者難以估計(jì)故事的問(wèn)題來(lái)自:對(duì)于領(lǐng)域知識(shí)的缺乏(這種情況下需要更多的溝通),或者故事太大了(這時(shí)需要把故事切分成小些的)。
5. Small(小的)
一個(gè)好的故事在工作量上要盡量短小,最好不要超過(guò)10個(gè)理想人/天的工作量,至少要確保的是在一個(gè)迭代中能夠完成。用戶故事越大,在安排計(jì)劃,工作量估算等方面的風(fēng)險(xiǎn)就會(huì)越大。
6. Testable(可測(cè)試的)
一個(gè)用戶故事要是可以測(cè)試的,以便于確認(rèn)它是可以完成的。如果一個(gè)用戶故事不能夠測(cè)試,那么你就無(wú)法知道它什么時(shí)候可以完成。一個(gè)不可測(cè)試的用戶故事例子:軟件應(yīng)該是易于使用的。
五、三個(gè)準(zhǔn)則
用戶故事在遵循了INVEST原則后,基本就是一個(gè)好的用戶故事了。再重點(diǎn)分析三個(gè)準(zhǔn)則,幫助在產(chǎn)出用戶故事時(shí)更好地符合原則。
三個(gè)準(zhǔn)則是:一個(gè)用戶、完整價(jià)值、不依賴。
1. 一個(gè)用戶
只包含一個(gè)用戶,因?yàn)槎鄠€(gè)用戶常常有細(xì)微的差別。一般是典型的用戶,常常有共同的某類需求。
2. 完整價(jià)值
完整地交付一個(gè)客戶價(jià)值。一個(gè)完整的用戶故事意味著這個(gè)故事完成后,用戶可以達(dá)成一個(gè)明確的、有意義的目標(biāo)。
3. 不依賴
依賴性的三種常見類型是:重疊、順序和包含。
總體上來(lái)說(shuō),故事之間功能點(diǎn)相互重疊是需要避免的;順序關(guān)系是現(xiàn)實(shí)存在,在多數(shù)情況下可以通過(guò)一些手段解決;包含關(guān)系對(duì)復(fù)雜系統(tǒng)是有幫助的,對(duì)排定發(fā)布和迭代計(jì)劃的影響需要注意。
(1)重疊依賴
重疊依賴是帶來(lái)最多困擾的依賴形式,特別是多個(gè)用戶故事包含多個(gè)不同的重疊部分時(shí),很難找到一組用戶故事可以代表該最小可行產(chǎn)品的功能集合,該集合應(yīng)該包含且僅包含一次需要的功能。
解決方式:
- 將重疊部分單獨(dú)剝離出來(lái)做為獨(dú)立的用戶故事;
- 合理拆分用戶故事,并且將重疊部分只保留在一個(gè)最有內(nèi)聚性的用戶故事中;
- 使用Scrum開發(fā)模式。
(2)順序依賴
順序依賴是指要使某用戶故事完成,另外的一個(gè)或多個(gè)用戶故事必須在它之前完成。順序依賴通常是無(wú)害的,而且有一些方式可以減輕這種依賴。
從敏捷開發(fā)的角度,整個(gè)系統(tǒng)是從初始的最小可行產(chǎn)品逐步演化為強(qiáng)大的產(chǎn)品,后面的每一步是建立在前面的基礎(chǔ)之上的。
但從另外的角度,不必要的順序依賴使得排列和調(diào)整優(yōu)先級(jí)變的比較困難,進(jìn)而影響制定發(fā)布和迭代計(jì)劃,也使得用戶故事的大小估算更難以把握。
解決方式:
- 一個(gè)迭代內(nèi)的用戶故事盡量做到?jīng)]有內(nèi)在依賴;
- 保持迭代之間只有單向依賴,在時(shí)間上只有后面迭代的故事對(duì)前面迭代故事的單向依賴(前向依賴);
- 剝離出核心依賴作為獨(dú)立的故事,不要把有依賴和無(wú)依賴的需求混在一個(gè)故事里。
(3)包含依賴
包含依賴是指在組織用戶故事時(shí)使用有層級(jí)的管理,比如常見的特性-故事兩級(jí)管理,一個(gè)特性包含多個(gè)用戶故事,這樣就構(gòu)成了特性對(duì)其屬下故事的包含依賴。
解決方式:
- 用戶故事一級(jí)用來(lái)做迭代計(jì)劃,避免用特性一級(jí)做粗粒度迭代計(jì)劃,特性一級(jí)可以用來(lái)做發(fā)布計(jì)劃;
- 特性一級(jí)同樣可以進(jìn)行拆分,直至拆分到最小市場(chǎng)化特性的程度,并將其包含的用戶故事分別歸到新拆分出的特性中去;
- 遵從最小可行產(chǎn)品的理念,一個(gè)特性分多個(gè)用戶故事多個(gè)迭代實(shí)現(xiàn),每一個(gè)迭代可形成潛在可交付或者提供內(nèi)部或外部反饋。
系列文章目錄
參考文章
如何理解用戶故事INVEST規(guī)則中的獨(dú)立性?
本文由 @chun 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來(lái)自 Unsplash,基于CC0協(xié)議。
剛好最近再做環(huán)球項(xiàng)目,這種外企要求是寫用戶故事,真的是很繁瑣,一般一個(gè)prd一千多字就能解決的問(wèn)題,寫用戶故事需要拆成五六個(gè)甚至更多,研發(fā)看起來(lái)也很費(fèi)勁,看一堆文檔才能了解這一期產(chǎn)品設(shè)計(jì)的全貌。這種公司一般都是不著急的,用戶故事里面包含了產(chǎn)品文檔+測(cè)試用例等等,字?jǐn)?shù)一般在兩三千左右一個(gè)拆的要足夠細(xì),很繁瑣。接到這種項(xiàng)目的需求,盡量就跑吧,就是個(gè)寫文檔工具人
花里胡哨,全是理論,沒有干貨,沒有用!
請(qǐng)教作者,寫用戶故事的目的在于使整個(gè)團(tuán)隊(duì)理解需求的價(jià)值。但是對(duì)開展開發(fā)工作來(lái)說(shuō),產(chǎn)品經(jīng)理需要交付的是產(chǎn)品需求文檔PRD,開發(fā)團(tuán)隊(duì)依據(jù)PRD進(jìn)行開發(fā)。開發(fā)如果只依靠用戶故事,是不足以開始干活的。是不是可以這樣理解 ?謝謝~~
是的。具體開發(fā)實(shí)施,是需要詳細(xì)的需求文檔,一般包括功能結(jié)構(gòu)、產(chǎn)品規(guī)則、流程圖、交互設(shè)計(jì)稿等,就是在需求確定要做的情況下,該怎么完成。
用戶故事,講究的是敏捷化,統(tǒng)一團(tuán)隊(duì)意見和明確努力方向。
所以用戶故事是運(yùn)用于產(chǎn)品規(guī)劃?指導(dǎo)需求調(diào)研顯然不夠,信息量太少了
用戶故事是傳達(dá)需求的方式,是調(diào)研后得到需求后的結(jié)論性表述。以故事的方式講述,大家更容易場(chǎng)景化理解,認(rèn)可需求價(jià)值,
感謝分享!作為一個(gè)小白,概念性的東西有些晦澀,建議多補(bǔ)充些例子,如依賴的情況。
+1 具體點(diǎn)就好啦
同意,后面兩個(gè)依賴的解決辦法有點(diǎn)模糊