如何編寫用戶故事：完整指南

用戶故事是正確的敏捷軟件開發的重要組成部分：讓我們看看它們的作用並學習如何編寫用戶故事。

敏捷框架是構建軟件開發和委派任務的一種流行且有效的方法。 編寫用戶故事（不要與如何編寫推薦書混淆）是敏捷開發中的一種工具，它允許開發人員了解需要做什麼以及如何滿足需求。 這使它們成為一個非常重要的起點——但這也意味著它們必須小心建造。 這是你應該知道的。

什麼是用戶故事？

這是一個在敏捷框架內的軟件開發中使用的術語。 用戶故事通常被認為是敏捷項目中的最小單元或滿足需求的第一步。 它們是在項目完全計劃好時創建的。

那麼，這到底是什麼意思呢？ 每個軟件功能在添加到項目中時都有（或應該有）特定用途。 該目的應影響其整個開發以及如何將其納入整體框架。 開發人員可以在需要做出決策時參考此目的，尤其是關於如何分解目標以及優先考慮什麼。 “用戶故事”只是描述功能目的的一種方式。

用戶故事是從用戶的角度編寫的，通常只用一兩句話。 它們捕捉用戶的觀點以及用戶想要做什麼。 完成後，好的用戶故事是討論戰略目標、可以安全地放棄或應該添加哪些功能等等的一種簡單方式。

如何編寫用戶故事

步驟 1. 獲取輸入

從所有者、潛在用戶和項目經理那裡獲取輸入。 一個強大的用戶故事需要大量的輸入才能準確。 從這些群體那裡得到關於他們想做什麼的明確解釋。 請記住，這不應直接轉化為用戶故事，但會提供必要的信息。 所有者可能會說，“我需要人們能夠在我的應用程序上使用 PayPal 付款”，這非常有用，但不是用戶故事本身。

第 2 步。決定如何創建用戶故事

這取決於您的工作流程。 在早期階段，在規劃整體框架時，將用戶故事記錄在索引卡或便利貼上。 後來，它們被合併到項目管理軟件中。 一些團隊成員跳過便利貼階段，而其他人則依賴它——以適合你的方式為準。

第 3 步：定義、定義、再定義

定義用戶：通過輸入，您現在可以定義用戶。 請記住，這並不總是產品功能的最終用戶； 它可能因用戶類型而異。 如有必要，創建用戶角色。 定義用戶正在執行的操作，並定義用戶執行此操作的目標。 在製作用戶故事以與目標受眾交流時包含此關鍵信息。

第 4 步。寫故事

開始編寫您的用戶故事，為了吸引讀者的注意力，它應該只有一兩句話。 在這裡很容易做到精確和技術性，但寬泛的語言，如使命宣言，可能會有所幫助。 把故事說清楚，確保它可以解決或完成，這樣你就可以回顧並確認，“是的，用戶現在可以做到這一點！”

步驟 5. 進一步分解

用戶故事可能需要多個步驟才能達到最終目標，這可能需要根據您使用的敏捷框架進行一些重組。 請記住，用戶故事始終是框架中的最小單元。 在這個粒度級別上，用戶故事應該需要幾天時間才能實施。

如果他們看起來需要更長的時間，那就是重新審視並查看是否需要進一步分解和重組用戶體驗的跡象。 如果添加了新需求，它們還需要分解為用戶故事。 雖然這幾句話是有效用戶故事的核心，但它們也可以隨著開發的進行而擴展。 讓我們仔細看看。

用戶故事中的 3C 是什麼？

Card ：Card階段是指用一兩句話為開發團隊編寫用戶故事。 之所以稱為卡片，是因為用戶故事最初是寫在索引卡片上的，許多團隊仍然喜歡這樣做。 該卡是其特定軟件要求的核心，也是所有討論的起點。 檢查您的用戶故事是否太長也很容易 - 如果它不能放在每個人都可以閱讀的索引卡上，則需要縮短它。

對話：創建卡片句子後，就該敲定細節了。 這通常以開發人員之間的一系列問題開始，例如“這需要多長時間才能實現？” 或“我們如何合併此操作？” 或者“這個用戶故事在這裡很重要嗎？” 等等。

這種對用戶故事的仔細檢查可能會產生額外的問題來詢問項目經理和產品所有者，他們應該在必要時參與對話。 隨著對話的繼續，用戶故事可能會被更改、改進、合併或刪除，直到每個人都在同一頁面上。 隨著用戶故事的最終確定，它們被轉移到實施階段，這是對話基本結束的標誌。

確認：確認是關於驗收測試，也就是驗收標準。 一旦實施了更改，並且開發人員報告它已準備就緒——用戶故事已經得到滿足——就該測試它了。

應根據產品所有者的輸入創建驗收測試，並直接與用戶故事聯繫起來。 在最好的情況下，用戶只是簡單地嘗試執行用戶故事指示的操作並查看他們是否可以。 但是驗收測試可能會有所不同，並不總是像他們應該的那樣考慮用戶故事。 如果這產生了問題，那麼是時候回到對話步驟，直到驗收測試和用戶故事正確對齊。 如果所有的驗收測試都完成了，用戶故事就會很高興。 現在是時候繼續產品開發的下一步或發布該功能了。

4C？ ：有趣的是，有些人認為有一個必不可少的 4th C：上下文。 在這種情況下，用戶故事與項目更大框架中的其他用戶故事一起被查看。 在這裡，開發人員詢問用戶故事是否順利地補充了其他用戶故事，或者是否存在差距——用戶需要做或理解的事情在用戶故事之間被遺漏了。

理想情況下，這是在對話階段發現的，但這並不總是發生。 一些開發團隊可能希望最終審查已完成的用戶故事如何融入更大的整體，以及是否需要做任何進一步的工作。

什麼是用戶故事的好格式？

讓我們回顧一下在創建用戶故事句子時非常有用的兩種格式化技術。 第一個非常簡單：“誰，什麼，為什麼？” 在句子模板中，可以這樣描述：

作為 [Who the user is]，我想 [What the user Wants]（這樣 [Why the user wants it]）。

此模板也可以構造為：“作為一個[角色]，我想[行動]，（以便[受益]）”，以簡化術語。 遵循這種基本格式足以創建大多數用戶故事。 這通常是您所需要的，並且在用於每個用戶故事時可以幫助節省大量時間。

然而，有時，用戶故事在更複雜的項目中更難定義。 在這種情況下，第二種用戶故事模板技術可能會有用。 它叫做 INVEST，一個首字母縮寫詞，代表：

• 獨立：故事應該完全相互獨立，因此故事應該能夠亂序處理。
• 可協商：故事應設計為在過程的對話部分進行更改。
• 有價值的：用戶故事應該為項目展示明確的價值。 如果不能，那可能是一種資源浪費。
• 可估計的：必鬚根據價值和優先級來衡量用戶故事，以幫助決定按重要性順序處理哪些內容。
• 小：用戶故事必須是最小的功能單元，否則應該進一步細分。
• 可測試：用戶故事必須在確認過程中以可測試的方式陳述。

關於如何編寫用戶故事的常見問題解答

您可能還對我們關於如何撰寫遊戲評論的指南感興趣。