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

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

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

什麼是用戶故事？

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

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

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

如何編寫用戶故事

步驟 1. 獲取輸入

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

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

這取決於您的工作流程。 在早期階段，在規劃總體框架時，會在索引卡或便利貼上捕獲用戶故事。 後來，它們被納入項目管理軟件中。 有些團隊成員會跳過便利貼階段，而其他團隊成員則依賴它 - 無論哪種方式適合您。 您可能還想知道如何寫序言。

步驟 3. 定義、定義、定義

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

第四步：寫故事

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

步驟 5. 分為進一步的步驟

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

如果看起來需要更長的時間，則表明需要重新審視用戶體驗，看看是否需要進一步分解和重組用戶體驗。 如果添加新需求，還需要將它們分解為用戶故事。 雖然這幾句話是有效用戶故事的核心，但隨著開發的進行，它們也可以擴展。 讓我們仔細看看。 您可能還對了解什麼是用戶體驗寫作感興趣。

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

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

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

對用戶故事的仔細檢查可能會產生額外的問題，需要詢問項目經理和產品負責人，必要時應讓他們參與對話。 隨著對話的繼續，用戶故事可能會被更改、細化、合併或刪除，直到每個人都在同一頁面上。 當用戶故事最終確定後，它們將被轉移到實施階段，這表明對話基本上已經結束。

確認：確認就是關於驗收測試，也稱為驗收標準。 一旦實施了更改，並且開發人員報告它已準備就緒（用戶故事已得到滿足），就可以對其進行測試了。

驗收測試應該根據產品負責人的輸入來創建，並直接與用戶故事聯繫起來。 在最好的情況下，用戶只是嘗試執行用戶故事指示的操作，看看是否可以。 但驗收測試可能會有所不同，並且並不總是按照應有的方式考慮用戶故事。 如果這會產生問題，則需要返回到對話步驟，直到驗收測試和用戶故事正確對齊。 如果所有驗收測試都完成，用戶故事就會很令人滿意。 現在是時候繼續產品開發的下一步或發布該功能了。

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

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

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

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

作為一個[用戶是誰]，我想要[用戶想要什麼]（以便[用戶為什麼想要它]）。

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

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

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

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

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