需求分析 - 用戶故事（User Story）

用戶故事(一)

用戶故事在軟件開發過程中被作為描述需求的一種表達形式；為了規范用戶故事的表達，便于溝通；包含角色、活動、價值三個要素。

用戶故事的概念

概念這種東西我喜歡說文解字的方式去理解和闡述；用戶故事=用戶+故事=人+故+事，那就是一個人因為什么原因要做什么事，提煉出來三要素就是who、why、what。從需求角度描述就是一個用來確認用戶和用戶需求的簡短描述。

用戶故事的三要素

用戶故事在軟件開發過程中被作為描述需求的一種表達形式。為了規范用戶故事的表達，便于溝通，用戶故事通常的表達格式為：作為一個<用戶角色>, 我想要<完成活動>, 以便于<實現價值>。

一個完整的用戶故事包含三個要素：

• 角色（who）：誰要使用這個
• 活動（what）：要完成什么活動
• 價值（value）：為什么要這么做，這么做能帶來什么價值

3C原則

用戶故事的描述信息以傳統的手寫方式寫在紙質卡片上，所以Ron Jeffries(2001)對這三個方面稱為3C：卡片(Card)、對話(Conversation)和確認(Confirmation)。

• 卡片（Card）：用戶故事一般在小卡片上寫著故事的簡短描述，規則和完成標準。
  
  卡片的正面書寫故事的描述，格式為：作為一個<角色>, 我想要<完成活動>, 以便于<實現價值>描述需求；卡片背面書寫完成用戶故事的規則和完成標準，格式為：Given…When…Then。

• 交談（Conversation）：用戶故事背后的細節來源于和客戶或者產品負責人的交流溝通；確保各方對故事的理解正確。
  

• 確認（Confirmation）：通過驗收測試確認用戶故事被正確完成。

INVEST原則

好的用戶故事除了格式規范，要素完整外，還應該遵循INVEST原則：Idependent（獨立的）；Negotiable（可協商的）；Valuable（有價值的）；Estimatable（可評估）；Small（小的）；Testable（可測試的）。

Idependent（獨立的）
要盡可能的讓一個用戶故事獨立于其他的用戶故事。用戶故事間保持獨立性不僅便于排列和調整優先級，使得發布和迭代計劃更容易制定，便于獨立地理解、跟蹤、實現、測試以及頻繁交付，也使得用戶故事的大小估算所涉及的范圍更清晰，從而估算偏差更小。

Negotiable（可協商的）
一個用戶故事的內容要是可以協商的，用戶故事不是合同。一個用戶故事只是對用戶故事的一個簡短的描述，不包括太多的細節；具體的細節在溝通階段產出。一個用戶故事帶有了太多的細節，實際上限制了用戶、團隊的想法和溝通。

Valuable（有價值的）
每個故事必須對客戶具有價值（無論是用戶、購買方還是公司內部角色）。用戶故事對于最終的用戶是有價值的，因此應該站在用戶的角度去編寫，描述的是一個一個的feature，而非一個一個的task。這個特點促進團隊的開發和測試成員由傳統的指令式工作方式向自驅動的價值導向工作方式轉變，使團隊中的每個人知道自己每天做的工作價值。

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

Small（小的）
一個好的故事在工作量上要盡量短小，最好不要超過10個理想人/天的工作量,至少要確保的是在一個迭代中能夠完成。用戶故事越大，在安排計劃，工作量估算等方面的風險就會越大。

Testable（可測試的）
一個用戶故事要是可以測試的，以便于確認它是可以完成的。如果一個用戶故事不能夠測試，那么你就無法知道它什么時候可以完成。一個不可測試的用戶故事例子：軟件應該是易于使用的。

三個準則

用戶故事在遵循了INVEST原則后，基本就是一個好的用戶故事了。再重點分析三個準則，幫助在產出用戶故事時更好地符合原則。

三個準則是：一個用戶、完整價值、不依賴。

一個用戶
只包含一個用戶，因為多個用戶常常有細微的差別。一般是典型的用戶，常常有共同的某類需求。

完整價值
完整地交付一個客戶價值。一個完整的用戶故事意味著這個故事完成后，用戶可以達成一個明確的、有意義的目標。

不依賴
依賴性的三種常見類型是：重疊、順序和包含。

總體上來說，故事之間功能點相互重疊是需要避免的；順序關系是現實存在，在多數情況下可以通過一些手段解決；包含關系對復雜系統是有幫助的，對排定發布和迭代計劃的影響需要注意。

（1）重疊依賴

重疊依賴是帶來最多困擾的依賴形式，特別是多個用戶故事包含多個不同的重疊部分時，很難找到一組用戶故事可以代表該最小可行產品的功能集合，該集合應該包含且僅包含一次需要的功能。

解決方式：

• 將重疊部分單獨剝離出來做為獨立的用戶故事；
• 合理拆分用戶故事，并且將重疊部分只保留在一個最有內聚性的用戶故事中；
• 使用Scrum開發模式。

（2）順序依賴

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

從敏捷開發的角度，整個系統是從初始的最小可行產品逐步演化為強大的產品，后面的每一步是建立在前面的基礎之上的。

但從另外的角度，不必要的順序依賴使得排列和調整優先級變的比較困難，進而影響制定發布和迭代計劃，也使得用戶故事的大小估算更難以把握。

解決方式：

• 一個迭代內的用戶故事盡量做到沒有內在依賴；
• 保持迭代之間只有單向依賴，在時間上只有后面迭代的故事對前面迭代故事的單向依賴（前向依賴）；
• 剝離出核心依賴作為獨立的故事，不要把有依賴和無依賴的需求混在一個故事里。

（3）包含依賴

包含依賴是指在組織用戶故事時使用有層級的管理，比如常見的特性－故事兩級管理，一個特性包含多個用戶故事，這樣就構成了特性對其屬下故事的包含依賴。

解決方式：

• 用戶故事一級用來做迭代計劃，避免用特性一級做粗粒度迭代計劃，特性一級可以用來做發布計劃；
• 特性一級同樣可以進行拆分，直至拆分到最小市場化特性的程度，并將其包含的用戶故事分別歸到新拆分出的特性中去；
• 遵從最小可行產品的理念，一個特性分多個用戶故事多個迭代實現，每一個迭代可形成潛在可交付或者提供內部或外部反饋。

用戶故事（二）

1. 敏捷開發的需求敏捷化的手段

就職在互聯網企業，在一個不大的項目組里，還是個要發揮產品經理主觀能動性的產品，你要去探索商業模式，做產品規劃，求生存。就先給你一只打火機讓你在黑暗中找金礦，你打著打火機只能照亮周圍1米，步子不能跨太大，不知道1米外是不是個坑，先跨一步看看，再能跨下一步。

更悲劇的是你的打火機不能一直按著，一直按著燙手啊，還要擔心燃氣夠不夠用。只能走走停停，摸摸索索，還要各方求資源補充燃氣。

這種環境下，整個團隊都在講小迭代，講敏捷，同樣你必須寫用戶故事啊。

用戶故事的出現使敏捷開發方法覆蓋了軟件研發中的“需求”環節，是敏捷開發模式中的需求敏捷化的重要手段。敏捷方法誕生十余年到現在我們知道，一個研發團隊要想實現完全的敏捷轉型光是實現迭代開發過程的敏捷化是不夠的，SCRUM和Kanban都無法解決產品需求敏捷化的問題。

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

Ps：如果你說你們在敏捷開發，但是你從不寫用戶故事，那怕是你們對敏捷開發有誤解，你們做的應該就是單純的迭代開發，不是敏捷開發。敏捷中重要的一點就是團隊達成一致意見，成員都認同要做的事的價值，這是建立在對需求的3W（who、what、why）重復理解和討論的基礎上達成的。傳統的需求表述方式只體現了what，無法支撐這種理解和討論。

2.貫穿整個產品實現過程

需求評審會之后，進入開發、測試環節，常常能聽到的聲音是“這個需求當初為什么要這么定？”“我也不知道，產品就這么定的?！?/p>

隨著時間的推移，可能產品經理自己也會忘記為什么要做這個需求，以及為什么要這么做。這就會造成團隊的后勁不足，無法明確自己正在做的事的價值。當一個人對于正在做的事，不知道有何意義時，是痛苦的。

而用戶故事能有效的將軟件研發過程中的需求環節、開發環節和測試環節有效的連接起來。通過經典的“三段論“描述和漸進的細節探索，用戶故事實現了需求描述的敏捷化；通過優先級排序和故事點的有效應用，用戶故事實現了需求到開發的連接；通過驗收標準的漸進明確，用戶故事實現了需求與測試的連接。

可以說，正是有了用戶故事這根線，才把軟件研發團隊的主要的工作環節：需求、開發、測試都有機的串聯起來。整個團隊成員都明確自己做的事能給團隊和客戶帶來什么價值，形成內驅動。

3. 提高溝通效果

舉個需求評審的場景：敏捷開發中，開發、設計、測試等在需求評審時，就會秉著敏捷參與的文化理念，來挑戰你的權威，一起懟產品啊，怎能錯過如此良機：這個需求誰提的，為什么這么做，做了有什么價值？

一頓舌戰群儒后，身心俱疲，開發還是用懷疑的眼光看著你說：“這都是你YY的吧？”

最后，不得已來一句，老板就讓這么做的，下周3上線。

但是，你用用戶故事的”三段論”作為一個<用戶角色>，我想要<完成活動>，以便于<實現價值>，在會前把故事發出去，注意力就是在故事的主人翁上，會中就是大家一起在探索用戶場景、路徑、給你提供思路，而不是在懟產品。

講故事不用太在意聽故事的人是誰？

用戶故事的一個核心在于對話（Conversation），客戶和開發人員可以就某個故事深入的交流，對每個重要的細節達成共識。這避免了通過文字記錄而可能導致的不精確性或語義多重性的問題。并且向用戶或客戶顯示價值，不涉及專業的技術術語，從而使得用戶和開發者理解起來都很容易。

4. 用戶故事適合于迭代開發

在開始編碼之前，我們并不需要寫出所有的用戶故事，我們可以寫出一部分故事，就開始編碼與測試，然后按需求的節奏重復這個過程。在寫故事時，也可以按照我們認為合適的粒度去寫，正是因為我們很容易對故事本身也進行迭代，所以用戶故事很適合迭代開發。

5. 用戶故事鼓勵延遲細節

我們可以先寫出一個起始的目標層面及占位意義的故事，在這個故事再后來對于開發進程變得重要時，才用更多對的細節來代替這個簡單的描述。

這很適用于有時間限制的項目。團隊可以非常迅速的寫出數十個用戶故事，讓大家對要開發的系統有一個整體的概念，然后先討論當前時間優先級較高的故事的細節并開始編碼，相對于事先完成系統的整體需求文檔，大大加快了研發進度。

6. 用戶故事傳播隱性知識

緣于對面對面溝通的重視，故事能夠促進團隊內隱性知識的積累。開發人員與客戶之間以及他們內部的溝通越密切，越多的隱性只是能得到傳播與加強。

撰寫有效的用戶故事

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

用戶故事應該根據業務需求編寫成較小的（small）、獨立的（independently）、可測試的（testable），增量的（increments），并有產品負責人確定其優先級。當產品負責人編寫用戶故事時，Scrum團隊可以提供非功能性/技術性用戶故事。但是，添加到待辦事項列表中，所有的功能性/非功能性需求要求被產品所有者審核并確定其優先級。總而言之，用戶故事應成為團隊（產品負責人、Scrum團隊、其他業務人員）之間溝通的橋梁。

編寫用戶故事

在Sprint Grooming期間，產品負責人將特性（Feature）、需求（Requirement）或史詩（Epic）分解為用戶故事。然后，Sprint計劃會（Spring planing）用來評估當前Sprint需完成的用戶故事。

用戶故事是從最終用戶的角度對功能的簡短描述：

作為[用戶類型]，我想要[一些目標，功能]，以便[一些原因]。

一個例子：

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

在編寫用戶故事時，它需要以下關鍵內容：

• 描述（Description）：對滿足業務需求的功能描述
• 驗收條件（Acceptance criteria）：所有可以標記用戶故事為完成的條件
• 最重要的是，它應該是：
  
  用戶故事應充分分解并保證其獨立性， 這樣就可以方便對工作進行適當的任務分配，估算，規模確定和測試。 產品負責人與Scrum團隊根據用戶需求協商功能的優先級，而用戶故事的價值決定了其優先級。

此外，在** 驗收條件（Acceptance criteria) **中記錄了用戶故事的測試用例。 它應該表示為：“誰”（用戶），“什么”（功能）和“為什么”（結果）

用戶故事該怎么寫

一個完整的用戶故事需要寫的內容包含：

展現形式如下：

一、故事標題

用戶故事的描述在列表中進行管理時，不利于快速理解，也不能一行展示。為每個故事取個標題（名字）就很有必要，而且像禪道、TAPD軟件的需求表述格式中標題也是必填項。

就行郵件的主題，用戶故事的標題是為了讓讀者能快速了解這個用戶故事的要點和大致范圍；怎么寫好標題也是有章可循的。
常見的做法有：

1. 用戶角度的動賓短語

如：創建商品、輸入名稱、修改頭像等等這是動作+對象形式，擅長描述從用戶看到的活動或功能。

2. 系統角度的動賓短語

此處的系統是指待開發的對象。

如，toast提示網絡異常，記錄用戶訪問次數，顯示搜索結果，顯示倒計時。擅長描述系統要執行的反饋和操作。

3. 主謂賓短語

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

隨著時間推移，新增的用戶故事有不少是基于原有的功能來再提升修改，這時往往要在標題里加上狀語來區分，比如根據客戶所在城市來查詢客戶列表，在客戶沒有登記電話號碼時強制客戶登記號碼。 狀語要清晰得說明用戶故事所處的情況，能夠區分類似的用戶故事。

4. 差勁標題舉例

（1）外訪業務處理

點評：處理是萬金油詞語，沒有突出重點。

（2）設計資產逾期流入流出報表

點評：主語既不是用戶，也不是待開發的系統，而是開發人員，這更像是一個任務的標題。

（3）角色分配資源

點評：要做什么呢？不能快速理解故事核心。

二、故事描述

固定格式“作為……（用戶角色），我想要……（完成活動），以便于……（實現價值）”的格式。故事描述一這種三段式表述，相比較于傳統需求表述，體現了需求方和需求價值的重要性，也為保證了需求描述的可協商性。

三、規則描述

為了完成故事，有時需要制定故事的實現規則，涉及的名詞定義等。規則描述由產品經理初步制定，在故事討論后，進行修訂確認。寫作方式就是一條條窮舉列出。注意這里不涉及原型頁面和交互規則。

四、驗收標準

可作為驗收測試用例的具體例子。這也是我們常說的實例化需求，也是為了避免誤讀，讓抽象的需求變得具體和可測試。
這一步很難，但非常重要。沒有明確的驗收條件，我們便不知道如何測試，業務也不知道如何驗收。

通常，一個用戶故事包含若干個驗收條件，包括快樂路徑（Happy Path）與意外場景（Exceptional Scenario）。

建議將驗收條件全部寫成“Given…When…Then”的 Gherkin 語言格式，這種寫法和測試用例類型，是一條條具體的路徑/場景，信息傳遞誤差小。延伸開來，這一原則適用于任何事情。做一件事情，以終為始，在一開始明確要做成什么樣子，行成閉環，才能指導行動并確保結果正確。

五、具體設計方案

故事完成需要具體的執行方案，方案一般都有故事實現的原型界面，交互規則；如果是數據類故事需求，還有數據指標的定義等。具體設計方案的產出可以在故事確認前也可以在故事確認后，具體看產品的時間和團隊的要求。

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

六、上線檢查清單

有些用戶故事的上線可能需要一些額外的步驟，在做用戶故事開發時就應該時刻想著上線時要留意的問題，及時記錄作為備忘，以確保上線成功。
這里，確認理解、問為什么以及驗收條件是重點，作為“就緒定義”（Definition of Ready, DoR），幫助我們厘清用戶故事的具體需求。

用戶故事例子

在編寫有效的用戶故事時，重要的是要有描述和詳細的驗收標準，以幫助團隊決定何時將用戶故事標記為“完成”。請參照以下例子：

史詩（Epic）用戶故事（User Story）驗收準則（ACCEPTANCE CRITERIA）

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。