需求分析 - 用戶(hù)故事（User Story）

用戶(hù)故事(一)

用戶(hù)故事在軟件開(kāi)發(fā)過(guò)程中被作為描述需求的一種表達(dá)形式；為了規(guī)范用戶(hù)故事的表達(dá)，便于溝通；包含角色、活動(dòng)、價(jià)值三個(gè)要素。

用戶(hù)故事的概念

概念這種東西我喜歡說(shuō)文解字的方式去理解和闡述；用戶(hù)故事=用戶(hù)+故事=人+故+事，那就是一個(gè)人因?yàn)槭裁丛蛞鍪裁词?#xff0c;提煉出來(lái)三要素就是who、why、what。從需求角度描述就是一個(gè)用來(lái)確認(rèn)用戶(hù)和用戶(hù)需求的簡(jiǎn)短描述。

用戶(hù)故事的三要素

用戶(hù)故事在軟件開(kāi)發(fā)過(guò)程中被作為描述需求的一種表達(dá)形式。為了規(guī)范用戶(hù)故事的表達(dá)，便于溝通，用戶(hù)故事通常的表達(dá)格式為：作為一個(gè)<用戶(hù)角色>, 我想要<完成活動(dòng)>, 以便于<實(shí)現(xiàn)價(jià)值>。

一個(gè)完整的用戶(hù)故事包含三個(gè)要素：

• 角色（who）：誰(shuí)要使用這個(gè)
• 活動(dòng)（what）：要完成什么活動(dòng)
• 價(jià)值（value）：為什么要這么做，這么做能帶來(lái)什么價(jià)值

3C原則

用戶(hù)故事的描述信息以傳統(tǒng)的手寫(xiě)方式寫(xiě)在紙質(zhì)卡片上，所以Ron Jeffries(2001)對(duì)這三個(gè)方面稱(chēng)為3C：卡片(Card)、對(duì)話(huà)(Conversation)和確認(rèn)(Confirmation)。

• 卡片（Card）：用戶(hù)故事一般在小卡片上寫(xiě)著故事的簡(jiǎn)短描述，規(guī)則和完成標(biāo)準(zhǔn)。
  
  卡片的正面書(shū)寫(xiě)故事的描述，格式為：作為一個(gè)<角色>, 我想要<完成活動(dòng)>, 以便于<實(shí)現(xiàn)價(jià)值>描述需求；卡片背面書(shū)寫(xiě)完成用戶(hù)故事的規(guī)則和完成標(biāo)準(zhǔn)，格式為：Given…When…Then。

• 交談（Conversation）：用戶(hù)故事背后的細(xì)節(jié)來(lái)源于和客戶(hù)或者產(chǎn)品負(fù)責(zé)人的交流溝通；確保各方對(duì)故事的理解正確。
  

• 確認(rèn)（Confirmation）：通過(guò)驗(yàn)收測(cè)試確認(rèn)用戶(hù)故事被正確完成。

INVEST原則

好的用戶(hù)故事除了格式規(guī)范，要素完整外，還應(yīng)該遵循INVEST原則：Idependent（獨(dú)立的）；Negotiable（可協(xié)商的）；Valuable（有價(jià)值的）；Estimatable（可評(píng)估）；Small（小的）；Testable（可測(cè)試的）。

Idependent（獨(dú)立的）
要盡可能的讓一個(gè)用戶(hù)故事獨(dú)立于其他的用戶(hù)故事。用戶(hù)故事間保持獨(dú)立性不僅便于排列和調(diào)整優(yōu)先級(jí)，使得發(fā)布和迭代計(jì)劃更容易制定，便于獨(dú)立地理解、跟蹤、實(shí)現(xiàn)、測(cè)試以及頻繁交付，也使得用戶(hù)故事的大小估算所涉及的范圍更清晰，從而估算偏差更小。

Negotiable（可協(xié)商的）
一個(gè)用戶(hù)故事的內(nèi)容要是可以協(xié)商的，用戶(hù)故事不是合同。一個(gè)用戶(hù)故事只是對(duì)用戶(hù)故事的一個(gè)簡(jiǎn)短的描述，不包括太多的細(xì)節(jié)；具體的細(xì)節(jié)在溝通階段產(chǎn)出。一個(gè)用戶(hù)故事帶有了太多的細(xì)節(jié)，實(shí)際上限制了用戶(hù)、團(tuán)隊(duì)的想法和溝通。

Valuable（有價(jià)值的）
每個(gè)故事必須對(duì)客戶(hù)具有價(jià)值（無(wú)論是用戶(hù)、購(gòu)買(mǎi)方還是公司內(nèi)部角色）。用戶(hù)故事對(duì)于最終的用戶(hù)是有價(jià)值的，因此應(yīng)該站在用戶(hù)的角度去編寫(xiě)，描述的是一個(gè)一個(gè)的feature，而非一個(gè)一個(gè)的task。這個(gè)特點(diǎn)促進(jìn)團(tuán)隊(duì)的開(kāi)發(fā)和測(cè)試成員由傳統(tǒng)的指令式工作方式向自驅(qū)動(dòng)的價(jià)值導(dǎo)向工作方式轉(zhuǎn)變，使團(tuán)隊(duì)中的每個(gè)人知道自己每天做的工作價(jià)值。

Estimatable（可評(píng)估）
計(jì)劃會(huì)議里面一個(gè)很重要的環(huán)節(jié)，那就是故事點(diǎn)的估計(jì)。實(shí)際上就是對(duì)要開(kāi)發(fā)的User Story進(jìn)行一個(gè)粗量級(jí)的估算，以便于團(tuán)隊(duì)能夠知道這個(gè)user story的復(fù)雜度（工作量）。重點(diǎn)放在當(dāng)前迭代里能否按照該用戶(hù)故事的接收條件和團(tuán)隊(duì)定義的DoD(完成標(biāo)準(zhǔn))來(lái)完成這個(gè)用戶(hù)故事，如果不能完成，給出理由，由PO來(lái)決定是否拆分或者重新設(shè)計(jì)用戶(hù)故事。讓開(kāi)發(fā)者難以估計(jì)故事的問(wèn)題來(lái)自：對(duì)于領(lǐng)域知識(shí)的缺乏（這種情況下需要更多的溝通），或者故事太大了（這時(shí)需要把故事切分成小些的）。

Small（小的）
一個(gè)好的故事在工作量上要盡量短小，最好不要超過(guò)10個(gè)理想人/天的工作量,至少要確保的是在一個(gè)迭代中能夠完成。用戶(hù)故事越大，在安排計(jì)劃，工作量估算等方面的風(fēng)險(xiǎn)就會(huì)越大。

Testable（可測(cè)試的）
一個(gè)用戶(hù)故事要是可以測(cè)試的，以便于確認(rèn)它是可以完成的。如果一個(gè)用戶(hù)故事不能夠測(cè)試，那么你就無(wú)法知道它什么時(shí)候可以完成。一個(gè)不可測(cè)試的用戶(hù)故事例子：軟件應(yīng)該是易于使用的。

三個(gè)準(zhǔn)則

用戶(hù)故事在遵循了INVEST原則后，基本就是一個(gè)好的用戶(hù)故事了。再重點(diǎn)分析三個(gè)準(zhǔn)則，幫助在產(chǎn)出用戶(hù)故事時(shí)更好地符合原則。

三個(gè)準(zhǔn)則是：一個(gè)用戶(hù)、完整價(jià)值、不依賴(lài)。

一個(gè)用戶(hù)
只包含一個(gè)用戶(hù)，因?yàn)槎鄠€(gè)用戶(hù)常常有細(xì)微的差別。一般是典型的用戶(hù)，常常有共同的某類(lèi)需求。

完整價(jià)值
完整地交付一個(gè)客戶(hù)價(jià)值。一個(gè)完整的用戶(hù)故事意味著這個(gè)故事完成后，用戶(hù)可以達(dá)成一個(gè)明確的、有意義的目標(biāo)。

不依賴(lài)
依賴(lài)性的三種常見(jiàn)類(lèi)型是：重疊、順序和包含。

總體上來(lái)說(shuō)，故事之間功能點(diǎn)相互重疊是需要避免的；順序關(guān)系是現(xiàn)實(shí)存在，在多數(shù)情況下可以通過(guò)一些手段解決；包含關(guān)系對(duì)復(fù)雜系統(tǒng)是有幫助的，對(duì)排定發(fā)布和迭代計(jì)劃的影響需要注意。

（1）重疊依賴(lài)

重疊依賴(lài)是帶來(lái)最多困擾的依賴(lài)形式，特別是多個(gè)用戶(hù)故事包含多個(gè)不同的重疊部分時(shí)，很難找到一組用戶(hù)故事可以代表該最小可行產(chǎn)品的功能集合，該集合應(yīng)該包含且僅包含一次需要的功能。

解決方式：

• 將重疊部分單獨(dú)剝離出來(lái)做為獨(dú)立的用戶(hù)故事；
• 合理拆分用戶(hù)故事，并且將重疊部分只保留在一個(gè)最有內(nèi)聚性的用戶(hù)故事中；
• 使用Scrum開(kāi)發(fā)模式。

（2）順序依賴(lài)

順序依賴(lài)是指要使某用戶(hù)故事完成，另外的一個(gè)或多個(gè)用戶(hù)故事必須在它之前完成。順序依賴(lài)通常是無(wú)害的，而且有一些方式可以減輕這種依賴(lài)。

從敏捷開(kāi)發(fā)的角度，整個(gè)系統(tǒng)是從初始的最小可行產(chǎn)品逐步演化為強(qiáng)大的產(chǎn)品，后面的每一步是建立在前面的基礎(chǔ)之上的。

但從另外的角度，不必要的順序依賴(lài)使得排列和調(diào)整優(yōu)先級(jí)變的比較困難，進(jìn)而影響制定發(fā)布和迭代計(jì)劃，也使得用戶(hù)故事的大小估算更難以把握。

解決方式：

• 一個(gè)迭代內(nèi)的用戶(hù)故事盡量做到?jīng)]有內(nèi)在依賴(lài)；
• 保持迭代之間只有單向依賴(lài)，在時(shí)間上只有后面迭代的故事對(duì)前面迭代故事的單向依賴(lài)（前向依賴(lài)）；
• 剝離出核心依賴(lài)作為獨(dú)立的故事，不要把有依賴(lài)和無(wú)依賴(lài)的需求混在一個(gè)故事里。

（3）包含依賴(lài)

包含依賴(lài)是指在組織用戶(hù)故事時(shí)使用有層級(jí)的管理，比如常見(jiàn)的特性－故事兩級(jí)管理，一個(gè)特性包含多個(gè)用戶(hù)故事，這樣就構(gòu)成了特性對(duì)其屬下故事的包含依賴(lài)。

解決方式：

• 用戶(hù)故事一級(jí)用來(lái)做迭代計(jì)劃，避免用特性一級(jí)做粗粒度迭代計(jì)劃，特性一級(jí)可以用來(lái)做發(fā)布計(jì)劃；
• 特性一級(jí)同樣可以進(jìn)行拆分，直至拆分到最小市場(chǎng)化特性的程度，并將其包含的用戶(hù)故事分別歸到新拆分出的特性中去；
• 遵從最小可行產(chǎn)品的理念，一個(gè)特性分多個(gè)用戶(hù)故事多個(gè)迭代實(shí)現(xiàn)，每一個(gè)迭代可形成潛在可交付或者提供內(nèi)部或外部反饋。

用戶(hù)故事（二）

1. 敏捷開(kāi)發(fā)的需求敏捷化的手段

就職在互聯(lián)網(wǎng)企業(yè)，在一個(gè)不大的項(xiàng)目組里，還是個(gè)要發(fā)揮產(chǎn)品經(jīng)理主觀能動(dòng)性的產(chǎn)品，你要去探索商業(yè)模式，做產(chǎn)品規(guī)劃，求生存。就先給你一只打火機(jī)讓你在黑暗中找金礦，你打著打火機(jī)只能照亮周?chē)?米，步子不能跨太大，不知道1米外是不是個(gè)坑，先跨一步看看，再能跨下一步。

更悲劇的是你的打火機(jī)不能一直按著，一直按著燙手啊，還要擔(dān)心燃?xì)鈮虿粔蛴谩Ｖ荒茏咦咄Ｍ?#xff0c;摸摸索索，還要各方求資源補(bǔ)充燃?xì)狻?/p>

這種環(huán)境下，整個(gè)團(tuán)隊(duì)都在講小迭代，講敏捷，同樣你必須寫(xiě)用戶(hù)故事啊。

用戶(hù)故事的出現(xiàn)使敏捷開(kāi)發(fā)方法覆蓋了軟件研發(fā)中的“需求”環(huán)節(jié)，是敏捷開(kāi)發(fā)模式中的需求敏捷化的重要手段。敏捷方法誕生十余年到現(xiàn)在我們知道，一個(gè)研發(fā)團(tuán)隊(duì)要想實(shí)現(xiàn)完全的敏捷轉(zhuǎn)型光是實(shí)現(xiàn)迭代開(kāi)發(fā)過(guò)程的敏捷化是不夠的，SCRUM和Kanban都無(wú)法解決產(chǎn)品需求敏捷化的問(wèn)題。

而用戶(hù)故事的誕生，就是為了實(shí)現(xiàn)需求的敏捷化。雖然用戶(hù)故事實(shí)踐本身還存在一些不足，但是至少到現(xiàn)在我們知道，用戶(hù)故事是需求敏捷化的基石之一。

Ps：如果你說(shuō)你們?cè)诿艚蓍_(kāi)發(fā)，但是你從不寫(xiě)用戶(hù)故事，那怕是你們對(duì)敏捷開(kāi)發(fā)有誤解，你們做的應(yīng)該就是單純的迭代開(kāi)發(fā)，不是敏捷開(kāi)發(fā)。敏捷中重要的一點(diǎn)就是團(tuán)隊(duì)達(dá)成一致意見(jiàn)，成員都認(rèn)同要做的事的價(jià)值，這是建立在對(duì)需求的3W（who、what、why）重復(fù)理解和討論的基礎(chǔ)上達(dá)成的。傳統(tǒng)的需求表述方式只體現(xiàn)了what，無(wú)法支撐這種理解和討論。

2.貫穿整個(gè)產(chǎn)品實(shí)現(xiàn)過(guò)程

需求評(píng)審會(huì)之后，進(jìn)入開(kāi)發(fā)、測(cè)試環(huán)節(jié)，常常能聽(tīng)到的聲音是“這個(gè)需求當(dāng)初為什么要這么定？”“我也不知道，產(chǎn)品就這么定的。”

隨著時(shí)間的推移，可能產(chǎn)品經(jīng)理自己也會(huì)忘記為什么要做這個(gè)需求，以及為什么要這么做。這就會(huì)造成團(tuán)隊(duì)的后勁不足，無(wú)法明確自己正在做的事的價(jià)值。當(dāng)一個(gè)人對(duì)于正在做的事，不知道有何意義時(shí)，是痛苦的。

而用戶(hù)故事能有效的將軟件研發(fā)過(guò)程中的需求環(huán)節(jié)、開(kāi)發(fā)環(huán)節(jié)和測(cè)試環(huán)節(jié)有效的連接起來(lái)。通過(guò)經(jīng)典的“三段論“描述和漸進(jìn)的細(xì)節(jié)探索，用戶(hù)故事實(shí)現(xiàn)了需求描述的敏捷化；通過(guò)優(yōu)先級(jí)排序和故事點(diǎn)的有效應(yīng)用，用戶(hù)故事實(shí)現(xiàn)了需求到開(kāi)發(fā)的連接；通過(guò)驗(yàn)收標(biāo)準(zhǔn)的漸進(jìn)明確，用戶(hù)故事實(shí)現(xiàn)了需求與測(cè)試的連接。

可以說(shuō)，正是有了用戶(hù)故事這根線(xiàn)，才把軟件研發(fā)團(tuán)隊(duì)的主要的工作環(huán)節(jié)：需求、開(kāi)發(fā)、測(cè)試都有機(jī)的串聯(lián)起來(lái)。整個(gè)團(tuán)隊(duì)成員都明確自己做的事能給團(tuán)隊(duì)和客戶(hù)帶來(lái)什么價(jià)值，形成內(nèi)驅(qū)動(dòng)。

3. 提高溝通效果

舉個(gè)需求評(píng)審的場(chǎng)景：敏捷開(kāi)發(fā)中，開(kāi)發(fā)、設(shè)計(jì)、測(cè)試等在需求評(píng)審時(shí)，就會(huì)秉著敏捷參與的文化理念，來(lái)挑戰(zhàn)你的權(quán)威，一起懟產(chǎn)品啊，怎能錯(cuò)過(guò)如此良機(jī)：這個(gè)需求誰(shuí)提的，為什么這么做，做了有什么價(jià)值？

一頓舌戰(zhàn)群儒后，身心俱疲，開(kāi)發(fā)還是用懷疑的眼光看著你說(shuō)：“這都是你YY的吧？”

最后，不得已來(lái)一句，老板就讓這么做的，下周3上線(xiàn)。

但是，你用用戶(hù)故事的”三段論”作為一個(gè)<用戶(hù)角色>，我想要<完成活動(dòng)>，以便于<實(shí)現(xiàn)價(jià)值>，在會(huì)前把故事發(fā)出去，注意力就是在故事的主人翁上，會(huì)中就是大家一起在探索用戶(hù)場(chǎng)景、路徑、給你提供思路，而不是在懟產(chǎn)品。

講故事不用太在意聽(tīng)故事的人是誰(shuí)？

用戶(hù)故事的一個(gè)核心在于對(duì)話(huà)（Conversation），客戶(hù)和開(kāi)發(fā)人員可以就某個(gè)故事深入的交流，對(duì)每個(gè)重要的細(xì)節(jié)達(dá)成共識(shí)。這避免了通過(guò)文字記錄而可能導(dǎo)致的不精確性或語(yǔ)義多重性的問(wèn)題。并且向用戶(hù)或客戶(hù)顯示價(jià)值，不涉及專(zhuān)業(yè)的技術(shù)術(shù)語(yǔ)，從而使得用戶(hù)和開(kāi)發(fā)者理解起來(lái)都很容易。

4. 用戶(hù)故事適合于迭代開(kāi)發(fā)

在開(kāi)始編碼之前，我們并不需要寫(xiě)出所有的用戶(hù)故事，我們可以寫(xiě)出一部分故事，就開(kāi)始編碼與測(cè)試，然后按需求的節(jié)奏重復(fù)這個(gè)過(guò)程。在寫(xiě)故事時(shí)，也可以按照我們認(rèn)為合適的粒度去寫(xiě)，正是因?yàn)槲覀兒苋菀讓?duì)故事本身也進(jìn)行迭代，所以用戶(hù)故事很適合迭代開(kāi)發(fā)。

5. 用戶(hù)故事鼓勵(lì)延遲細(xì)節(jié)

我們可以先寫(xiě)出一個(gè)起始的目標(biāo)層面及占位意義的故事，在這個(gè)故事再后來(lái)對(duì)于開(kāi)發(fā)進(jìn)程變得重要時(shí)，才用更多對(duì)的細(xì)節(jié)來(lái)代替這個(gè)簡(jiǎn)單的描述。

這很適用于有時(shí)間限制的項(xiàng)目。團(tuán)隊(duì)可以非常迅速的寫(xiě)出數(shù)十個(gè)用戶(hù)故事，讓大家對(duì)要開(kāi)發(fā)的系統(tǒng)有一個(gè)整體的概念，然后先討論當(dāng)前時(shí)間優(yōu)先級(jí)較高的故事的細(xì)節(jié)并開(kāi)始編碼，相對(duì)于事先完成系統(tǒng)的整體需求文檔，大大加快了研發(fā)進(jìn)度。

6. 用戶(hù)故事傳播隱性知識(shí)

緣于對(duì)面對(duì)面溝通的重視，故事能夠促進(jìn)團(tuán)隊(duì)內(nèi)隱性知識(shí)的積累。開(kāi)發(fā)人員與客戶(hù)之間以及他們內(nèi)部的溝通越密切，越多的隱性只是能得到傳播與加強(qiáng)。

撰寫(xiě)有效的用戶(hù)故事

用戶(hù)故事（User Story）描述了將要實(shí)現(xiàn)的特性（Feature）或需求（Requirement），用戶(hù)故事與特定的工具無(wú)關(guān)（Jira、Rally、Trello等等）。用戶(hù)故事在各種敏捷框架使用，包括Scrum，看板（Kanban）和極限編程（Extreme Programming）等等。

用戶(hù)故事應(yīng)該根據(jù)業(yè)務(wù)需求編寫(xiě)成較小的（small）、獨(dú)立的（independently）、可測(cè)試的（testable），增量的（increments），并有產(chǎn)品負(fù)責(zé)人確定其優(yōu)先級(jí)。當(dāng)產(chǎn)品負(fù)責(zé)人編寫(xiě)用戶(hù)故事時(shí)，Scrum團(tuán)隊(duì)可以提供非功能性/技術(shù)性用戶(hù)故事。但是，添加到待辦事項(xiàng)列表中，所有的功能性/非功能性需求要求被產(chǎn)品所有者審核并確定其優(yōu)先級(jí)。總而言之，用戶(hù)故事應(yīng)成為團(tuán)隊(duì)（產(chǎn)品負(fù)責(zé)人、Scrum團(tuán)隊(duì)、其他業(yè)務(wù)人員）之間溝通的橋梁。

編寫(xiě)用戶(hù)故事

在Sprint Grooming期間，產(chǎn)品負(fù)責(zé)人將特性（Feature）、需求（Requirement）或史詩(shī)（Epic）分解為用戶(hù)故事。然后，Sprint計(jì)劃會(huì)（Spring planing）用來(lái)評(píng)估當(dāng)前Sprint需完成的用戶(hù)故事。

用戶(hù)故事是從最終用戶(hù)的角度對(duì)功能的簡(jiǎn)短描述：

作為[用戶(hù)類(lèi)型]，我想要[一些目標(biāo)，功能]，以便[一些原因]。

一個(gè)例子：

作為一名房產(chǎn)中介，我希望能夠租戶(hù)身份證照片，以便可以將其附加到租賃合同中。

在編寫(xiě)用戶(hù)故事時(shí)，它需要以下關(guān)鍵內(nèi)容：

• 描述（Description）：對(duì)滿(mǎn)足業(yè)務(wù)需求的功能描述
• 驗(yàn)收條件（Acceptance criteria）：所有可以標(biāo)記用戶(hù)故事為完成的條件
• 最重要的是，它應(yīng)該是：
  
  用戶(hù)故事應(yīng)充分分解并保證其獨(dú)立性， 這樣就可以方便對(duì)工作進(jìn)行適當(dāng)?shù)娜蝿?wù)分配，估算，規(guī)模確定和測(cè)試。 產(chǎn)品負(fù)責(zé)人與Scrum團(tuán)隊(duì)根據(jù)用戶(hù)需求協(xié)商功能的優(yōu)先級(jí)，而用戶(hù)故事的價(jià)值決定了其優(yōu)先級(jí)。

此外，在** 驗(yàn)收條件（Acceptance criteria) **中記錄了用戶(hù)故事的測(cè)試用例。 它應(yīng)該表示為：“誰(shuí)”（用戶(hù)），“什么”（功能）和“為什么”（結(jié)果）

用戶(hù)故事該怎么寫(xiě)

一個(gè)完整的用戶(hù)故事需要寫(xiě)的內(nèi)容包含：

展現(xiàn)形式如下：

一、故事標(biāo)題

用戶(hù)故事的描述在列表中進(jìn)行管理時(shí)，不利于快速理解，也不能一行展示。為每個(gè)故事取個(gè)標(biāo)題（名字）就很有必要，而且像禪道、TAPD軟件的需求表述格式中標(biāo)題也是必填項(xiàng)。

就行郵件的主題，用戶(hù)故事的標(biāo)題是為了讓讀者能快速了解這個(gè)用戶(hù)故事的要點(diǎn)和大致范圍；怎么寫(xiě)好標(biāo)題也是有章可循的。
常見(jiàn)的做法有：

1. 用戶(hù)角度的動(dòng)賓短語(yǔ)

如：創(chuàng)建商品、輸入名稱(chēng)、修改頭像等等這是動(dòng)作+對(duì)象形式，擅長(zhǎng)描述從用戶(hù)看到的活動(dòng)或功能。

2. 系統(tǒng)角度的動(dòng)賓短語(yǔ)

此處的系統(tǒng)是指待開(kāi)發(fā)的對(duì)象。

如，toast提示網(wǎng)絡(luò)異常，記錄用戶(hù)訪(fǎng)問(wèn)次數(shù)，顯示搜索結(jié)果，顯示倒計(jì)時(shí)。擅長(zhǎng)描述系統(tǒng)要執(zhí)行的反饋和操作。

3. 主謂賓短語(yǔ)

有時(shí)動(dòng)賓短語(yǔ)不能推斷主語(yǔ)時(shí)使用主謂賓短句，或者可能有可能混淆時(shí)需要明確主語(yǔ)，此時(shí)就需要增加動(dòng)作主語(yǔ)，如，超級(jí)管理員重置普通管理員的口令；A系統(tǒng)推送批量客戶(hù)和合同信息。

隨著時(shí)間推移，新增的用戶(hù)故事有不少是基于原有的功能來(lái)再提升修改，這時(shí)往往要在標(biāo)題里加上狀語(yǔ)來(lái)區(qū)分，比如根據(jù)客戶(hù)所在城市來(lái)查詢(xún)客戶(hù)列表，在客戶(hù)沒(méi)有登記電話(huà)號(hào)碼時(shí)強(qiáng)制客戶(hù)登記號(hào)碼。 狀語(yǔ)要清晰得說(shuō)明用戶(hù)故事所處的情況，能夠區(qū)分類(lèi)似的用戶(hù)故事。

4. 差勁標(biāo)題舉例

（1）外訪(fǎng)業(yè)務(wù)處理

點(diǎn)評(píng)：處理是萬(wàn)金油詞語(yǔ)，沒(méi)有突出重點(diǎn)。

（2）設(shè)計(jì)資產(chǎn)逾期流入流出報(bào)表

點(diǎn)評(píng)：主語(yǔ)既不是用戶(hù)，也不是待開(kāi)發(fā)的系統(tǒng)，而是開(kāi)發(fā)人員，這更像是一個(gè)任務(wù)的標(biāo)題。

（3）角色分配資源

點(diǎn)評(píng)：要做什么呢？不能快速理解故事核心。

二、故事描述

固定格式“作為……（用戶(hù)角色），我想要……（完成活動(dòng)），以便于……（實(shí)現(xiàn)價(jià)值）”的格式。故事描述一這種三段式表述，相比較于傳統(tǒng)需求表述，體現(xiàn)了需求方和需求價(jià)值的重要性，也為保證了需求描述的可協(xié)商性。

三、規(guī)則描述

為了完成故事，有時(shí)需要制定故事的實(shí)現(xiàn)規(guī)則，涉及的名詞定義等。規(guī)則描述由產(chǎn)品經(jīng)理初步制定，在故事討論后，進(jìn)行修訂確認(rèn)。寫(xiě)作方式就是一條條窮舉列出。注意這里不涉及原型頁(yè)面和交互規(guī)則。

四、驗(yàn)收標(biāo)準(zhǔn)

可作為驗(yàn)收測(cè)試用例的具體例子。這也是我們常說(shuō)的實(shí)例化需求，也是為了避免誤讀，讓抽象的需求變得具體和可測(cè)試。
這一步很難，但非常重要。沒(méi)有明確的驗(yàn)收條件，我們便不知道如何測(cè)試，業(yè)務(wù)也不知道如何驗(yàn)收。

通常，一個(gè)用戶(hù)故事包含若干個(gè)驗(yàn)收條件，包括快樂(lè)路徑（Happy Path）與意外場(chǎng)景（Exceptional Scenario）。

建議將驗(yàn)收條件全部寫(xiě)成“Given…When…Then”的 Gherkin 語(yǔ)言格式，這種寫(xiě)法和測(cè)試用例類(lèi)型，是一條條具體的路徑/場(chǎng)景，信息傳遞誤差小。延伸開(kāi)來(lái)，這一原則適用于任何事情。做一件事情，以終為始，在一開(kāi)始明確要做成什么樣子，行成閉環(huán)，才能指導(dǎo)行動(dòng)并確保結(jié)果正確。

五、具體設(shè)計(jì)方案

故事完成需要具體的執(zhí)行方案，方案一般都有故事實(shí)現(xiàn)的原型界面，交互規(guī)則；如果是數(shù)據(jù)類(lèi)故事需求，還有數(shù)據(jù)指標(biāo)的定義等。具體設(shè)計(jì)方案的產(chǎn)出可以在故事確認(rèn)前也可以在故事確認(rèn)后，具體看產(chǎn)品的時(shí)間和團(tuán)隊(duì)的要求。

方案文件一般為附件或原型鏈接。

六、上線(xiàn)檢查清單

有些用戶(hù)故事的上線(xiàn)可能需要一些額外的步驟，在做用戶(hù)故事開(kāi)發(fā)時(shí)就應(yīng)該時(shí)刻想著上線(xiàn)時(shí)要留意的問(wèn)題，及時(shí)記錄作為備忘，以確保上線(xiàn)成功。
這里，確認(rèn)理解、問(wèn)為什么以及驗(yàn)收條件是重點(diǎn)，作為“就緒定義”（Definition of Ready, DoR），幫助我們厘清用戶(hù)故事的具體需求。

用戶(hù)故事例子

在編寫(xiě)有效的用戶(hù)故事時(shí)，重要的是要有描述和詳細(xì)的驗(yàn)收標(biāo)準(zhǔn)，以幫助團(tuán)隊(duì)決定何時(shí)將用戶(hù)故事標(biāo)記為“完成”。請(qǐng)參照以下例子：

史詩(shī)（Epic）用戶(hù)故事（User Story）驗(yàn)收準(zhǔn)則（ACCEPTANCE CRITERIA）

作為一個(gè)拍賣(mài)系統(tǒng)的用戶(hù)，我希望能夠安全登陸拍賣(mài)平臺(tái)，以至于我可以投標(biāo)購(gòu)買(mǎi)商品	作為拍賣(mài)系統(tǒng)的用戶(hù)，我希望能從拍賣(mài)平臺(tái)選擇商品，以至于我可以投標(biāo)購(gòu)買(mǎi)	保證拍賣(mài)系統(tǒng)的用戶(hù)可以：1.成功登陸拍賣(mài)平臺(tái)2.打開(kāi)拍賣(mài)頁(yè)面3.可以選擇商品并投標(biāo)
	作為拍賣(mài)系統(tǒng)的用戶(hù)，我希望查看拍賣(mài)歷史記錄，以至于我可以移除過(guò)期的拍賣(mài)	保證拍賣(mài)系統(tǒng)的用戶(hù)可以：1.成功登陸拍賣(mài)平臺(tái)2.成功打開(kāi)拍賣(mài)歷史記錄頁(yè)面3.選擇一個(gè)多個(gè)過(guò)期的歷史記錄4.移除選擇的記錄
作為市場(chǎng)部門(mén)主管，我希望有一個(gè)內(nèi)容管理系統(tǒng)（content management system），以至于我可以管理并提供高質(zhì)量的內(nèi)容給顧客	作為內(nèi)容提供者，我希望可以創(chuàng)建產(chǎn)品內(nèi)容，以至于我可以給用戶(hù)提供產(chǎn)品的內(nèi)容給顧客	保證內(nèi)容提供者可以：1.登錄內(nèi)容管理系統(tǒng)2.創(chuàng)建內(nèi)容3.更新內(nèi)容4.保存變更把內(nèi)容提交給編輯審核
	作為編輯，我希望可以在內(nèi)容發(fā)布前審核，以至于我可以保證內(nèi)容被優(yōu)化，沒(méi)有語(yǔ)法錯(cuò)誤	保證編輯可以：1.登錄內(nèi)容管理系統(tǒng)2.查看存在的內(nèi)容3.編輯、保存內(nèi)容4.對(duì)內(nèi)容做標(biāo)注5.將內(nèi)容打回要求重新修6.改定期發(fā)布內(nèi)容
作為人力資源主管，我希望有一個(gè)虛擬的職位看板，以至于我可以查看企業(yè)人力資源需求和職位狀態(tài)	作為人力資源主管，我希望查看應(yīng)聘者狀態(tài)，以至于我可以在招聘環(huán)節(jié)中管理應(yīng)聘者的狀態(tài)	保證人力資源主管可以：1.登錄虛擬職位看板2.編輯、添加及查看應(yīng)聘者的信息3.每個(gè)階段的更新（例如，電話(huà)篩選已完成，安排了面試，正在進(jìn)行的背景調(diào)查等）4.向員工發(fā)送有關(guān)候選人的電子郵件通訊

總結(jié)

以上是生活随笔為你收集整理的需求分析-用户故事的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。