在本教程中，您將學習敏捷軟體開發方法中的一個重要部分：用戶故事。

我將帶您了解什麼是用戶故事、在創建用戶故事時我所見的常見陷阱，以及現有的框架來驗證您的用戶故事是否“優秀”。

以下是我們將涵蓋的內容：

敏捷的起源

你可能聽說過敏捷開發和用戶故事。如果你還沒聽說過，那麼讓我們來簡單回顧一下歷史：

用戶故事是敏捷方法論這個更大概念的一部分。

敏捷方法論自2001年以來就存在，當時17位受人尊敬的軟體工程師在猶他州的一個滑雪勝地聚會，創建了現在著名的敏捷宣言。

如果像羅伯特·馬丁、馬丁·福勒和肯特·貝克這些名字對你來說沒有意義，完成這篇文章後，去查查他們。他們擁有豐富的知識，並且為軟體世界提供了一種更靈活的項目交付方式，稱為敏捷。

什麼是敏捷？

敏捷更像是一種思維方式，而不是一種規定的方法。存在一些規定的方法，例如Scrum和Kanban，但敏捷是一個概念。

敏捷提倡協作、快速反饋，以及經常為用戶交付價值。

敏捷的思維方式鼓勵在項目規劃中保持靈活性，這與當時的競爭對手——瀑布式項目規劃形成了鮮明的對比，後者在交付內容和時間上非常僵化。

敏捷方法論提倡在項目開始時進行“足夠”的研究，然後在整個項目過程中學習、迭代並根據需要更改設計和交付物，直到最終代碼交付為止。這種“隨著進展進行變更和學習”的方法稱為“適應性規劃”。

敏捷提倡快速且頻繁地交付有價值的成果，通常以每兩週的“短衝”結束時將代碼交付至生產環境的形式呈現。這與傳統的瀑布式規劃截然不同，後者通常需要幾個月的開發才能將任何用戶可見的變更交付至生產環境。

敏捷的另一個關鍵部分是它強調利益相關者之間的緊密合作和頻繁互動。產品、質量保證、工程和銷售在項目生命週期中都對項目有大量的貢獻和不斷的反饋。

現在您對敏捷的運作有了更多的了解，我們來深入探討如何驗證對用戶的價值。

進入用戶故事。

什麼是用戶故事？

用戶故事是一種用簡單英語將工程師與軟件的最終目標相連接的方式。

它的設計旨在讓非技術人員也能閱讀並理解所交付的內容，同時使工程師能夠查看並認識到其價值，以及如何驗證您已交付該價值。

用戶故事的結構

作為[用戶類型]，當我[執行動作]時，[預期結果]

這就是最基本的內容。

您強調的是最終用戶和您將提供的「價值」。

讓我們深入探討輸入：

  • 用戶類型：沒有一種適合所有人的「用戶」。您有「管理員用戶」，您有「已登入用戶」，您有「擁有權限X的用戶」或「角色Y的用戶」。這是針對執行動作的人進行具體化

  • 執行動作：用戶在做什麼？點擊「登入」按鈕？刪除記錄？提交表單？

  • 預期結果：一旦用戶執行了該動作，應該發生什麼？如果他們使用正確的電子郵件地址和密碼點擊「登入」，應該被導向哪裡？如果他們使用錯誤的電子郵件地址和密碼點擊「登入」，應該發生什麼？

用戶故事示例：

讓我們看一下登錄頁面用戶故事的示例。

沒有比示例更好的了。

讓我們來設定一下場景。您有一個帶有郵件地址輸入框和密碼輸入框的登錄頁面。您有一個提交按鈕。就是這樣。

從用戶的角度來看，這個頁面可能出現哪些不同的排列組合？

作為已登錄用戶，當頁面加載時，我被重定向到已登錄的首頁

如果我已經登錄，我不想重新輸入我的詳細信息，只需重定向我到已登錄的首頁。

作為未登錄用戶，當我輸入正確的郵件地址但不正確的密碼並點擊登錄時，會出現錯誤消息

我是一個未登錄的用戶，輸入了不正確的詳細信息。我不應該被登錄。

作為未登錄用戶，當我輸入不正確的郵件地址和密碼並點擊登錄時，會出現錯誤消息。

同樣。我不是已登錄的用戶。我輸入了不正確的詳細信息，我不應該被登錄。

作為未登錄用戶，當我輸入正確的郵件地址和密碼並點擊登錄時，我被重定向到已登錄的首頁。

這一次，我還沒有登錄，我輸入了正確的詳細信息並點擊登錄。我已經登錄到系統中。

您能看出這些都是以用戶為中心的嗎？

您可能會注意到上述“預期行為”中有些並未完全定義。我們將在後面的驗收標準中解決這個問題。

如何撰寫好的使用者故事

有一個稱為INVEST模型的良好模型，非常簡單地顯示了如何知道您的使用者故事是否好。

INVEST模型:

  • Independent: 可以分開開發。

  • Negotiable: 可以討論和更改。

  • Valuable: 為使用者提供價值。

  • Estimable: 可以估計工作量。

  • Small: 可在一個迭代中完成。

  • Testable: 具有明確的驗收標準。

讓我們將這個INVEST模型應用於上面的一個使用者故事範例：

作為一個未登錄的使用者，當我輸入正確的電子郵件地址和密碼並點擊登錄時，我將被重定向到登錄後的首頁。

(我將在這裡做一些假設，因為這是一個理論上的代碼基礎和理論項目)

這個故事是 獨立的 嗎？我會說是的。這是一個小故事，只涉及幾個可能已經存在的組件。不過，如果這個項目的資料庫還沒有建立，那麼就會產生依賴性。這樣就不再是獨立的了。

這是 可協商的 嗎？嗯，答案是肯定的。這個故事可以輕易地改為重定向到用戶的個人資料頁面，而不是他們的主頁。

這個故事絕對是 有價值的。一旦實施，用戶就可以登錄。如果這個故事是：

作為一個未登錄的用戶，當我輸入正確的電子郵件地址和密碼並點擊登錄時，什麼也不會發生。

這將沒有價值。用戶將無法從中獲得任何東西。

這個故事是 可評估的 嗎？再一次，我們必須在這個假設的情境中做出一些假設，但我當然希望這可以輕易地被評估。這是一個簡潔的故事，涉及少數組件，處於每個人都熟悉的領域，並且有明確的接受標準。

這個故事肯定是 小的。需要做的事情幾乎沒有模糊之處，只有一條用戶路徑和明確的結果。我們來看看一個會太大的故事：

作為一個未登錄的用戶，登錄頁面應該如預期般運作。

正如在這篇文章的前面討論過的，登錄頁面可以也應該有很多種運作方式。“應該如預期般運作”似乎涵蓋了所有這些變化。這將太大，無法有效地作為一個故事進行評估，並且可能太大，無法在一個衝刺中完成。

這個故事絕對是可測試的。有明確的用戶操作，並且有明確的結果。這個用戶故事可以通過單元測試、集成測試和手動測試來覆蓋。

看起來我們創建了一個很好的用戶故事！

如果您使用我上面定義的結構，並且故事符合INVEST模型的標準，那麼這可能是一個好的故事。

用戶故事創建中的常見陷阱

過去我見過一些用戶故事出錯的情況，人們錯過了一些關鍵方面：

過分關注技術方面

正如我上面的例子所示，用戶故事是非技術性的。

不應該提到服務名稱、數據庫名稱，或者基於用戶看不到的任何驗證。

一旦您的故事不再能被最終用戶理解，您就出錯了。

著眼於用戶將要做什麼，以及用戶將要看到什麼。

讓我們看一個技術性故事的例子：

作為一個未登錄的用戶，當我點擊正確的電子郵件地址的忘記密碼鏈接時，在數據庫表中記錄一條記錄，說明已發送密碼重置鏈接。

這個故事無法由用戶驗證，非技術性用戶可能無法理解它的含義。

讓我們修正一下：

作為一個未登錄的用戶，當我點擊正確的電子郵件地址的忘記密碼鏈接時，將會發送一封郵件到提供的電子郵件地址，其中包含一個忘記密碼重置鏈接。

非技術使用者能夠理解這一點，並且將焦點放在用戶身上，而非產品。

利益相關者協作

敏捷開發是協作的。

用戶故事需要產品、業務分析師、質量保證人員、工程師，以及最重要的，用戶的參與。

這樣做可以確保您正在交付用戶想要的內容。人多好辦事。

例如，如果只有一個工程團隊提出用戶故事，可能看起來像這樣：

作為一個登錄用戶，當頁面加載時，我被重定向到登錄後的首頁

作為一個未登錄用戶，當我輸入正確的電子郵件地址但是不正確的密碼並點擊登錄時，會顯示錯誤消息

作為一個未登錄用戶，當我輸入不正確的電子郵件地址和密碼並點擊登錄時，會顯示錯誤消息。

這樣做很好。但現在讓質量保證人員參與，他們從不同的角度參與，因為他們對軟件有不同的經驗：

作為一個未登錄用戶，當我輸入希伯來語中的正確電子郵件地址和正確密碼時，我被重定向到首頁

作為一個未登錄用戶，當我輸入正確的電子郵件地址和密碼並重複點擊登錄時，我被重定向到首頁

很好。現在我們得到了一組更全面的用戶故事，覆蓋了更多情況。但如果讓產品也參與呢？

作為一個未登錄用戶，當頁面加載時，我的密碼管理器應預先加載我的用戶名和密碼，當我點擊登錄時，我被重定向到首頁

產品團隊了解用戶。他們知道人們確實使用密碼管理器。我們應該確保當用戶實際上沒有輸入任何內容（因為文本是由密碼管理器加載的）時，登錄仍然能正確運作。

模糊的用戶故事

好的用戶故事背後的理念是每個人，不論專業程度，都能理解它。

如果你寫的用戶故事可以被10個不同的人以10種不同的方式解讀，那麼你就有點偏離了方向。

我在上面提到過我會談到接受標準，現在是時候來做這件事了。

讓我們重新檢視以下用戶故事：

作為一個未登錄的用戶，當我輸入一個不正確的電子郵件地址和密碼並點擊登錄時，會出現一條錯誤訊息。

這裡面有模糊之處。

應該顯示什麼訊息？在無效登錄嘗試後頁面重載時，使用者名稱文本框應該重設為空，還是預填上之前輸入的值？什麼是「不正確的電子郵件地址」？是一個從未見過的電子郵件地址，還是目前無效的電子郵件地址（例如未支付訂閱、取消訂閱等）？

所以你可以看到，細節很重要。

這個用戶故事是一個相當牽強的簡單例子，我已經找到了很多與之相關的問題。

讓我們來解決這個問題：

作為一個未登錄的用戶，當我輸入一個未在系統中註冊的電子郵件地址時，當我點擊登錄時，會出現一條錯誤訊息。

這消除了有關用戶行為的問題，但尚未解決有關預期錯誤消息的問題。

輸入接受標準。

在用戶故事中，您需要有一組接受標準，定義用戶故事的實施是否符合預期。

例如：

  • 錯誤消息：“無效的電子郵件地址或密碼”

  • 電子郵件地址和密碼文本框在重新加載時重置為空

  • 用戶無法訪問需要登錄的頁面

  • 用戶會看到“忘記密碼”的建議。

接受標準說明了實施中預期的內容。

如何開始使用用戶故事

從小開始。

您在開始時不會完美地精煉和創建用戶故事。

創建用戶故事既是一門藝術，也是一門科學。熟能生巧。

用戶故事的創建應該以小組的方式進行。通常，這是通過“3位朋友”方法實現的，您將有一位工程師、一位產品人員和一位質量保證一起坐下來，集思廣益，討論您需要支持的不同變化。

一旦您交付了項目，回顧一下。回顧並查看您的用戶故事中存在哪些空白。用戶可能會發現錯誤，測試和使用者驗收也可能發現這些問題，這些問題可能是由於您的用戶故事存在空白或測試中存在空白。無論如何，您應該從中吸取教訓，以便下次做得更好。

結論

敏捷是協作的。Scrum 是協作的。創建用戶故事是協作的。請記住這一點。

從不同專業領域的人一起協作創建用戶故事，您更有可能涵蓋完整的工作流程。

用戶是焦點。如果您包含了用戶不理解的術語，請重新思考用戶故事。

一開始您不會做得完美，但隨著經驗的增加，您會變得更快更有效。請聽一聽一個做了十多年這項工作的人的話。與十年前相比，我今天創建用戶故事的速度和質量相差甚遠。

查看我的網站上的博客文章，Just Another Tech Lead，或註冊我的每週電子郵件新聞快報此處。