在轉向敏捷之后，很多團隊開始使用“用戶故事”一詞。用戶故事是一種簡單而優雅的技術，可以收集客戶需求。然而，它需要一定的理解和實踐才能用User Stories構建出色的軟件。

讓我們仔細看看用戶故事是什么以及如何使用這種技術取得成功。

什么是用戶故事？

用戶素材是對功能的簡短描述，它為用戶或客戶帶來價值，團隊可以在迭代中提供這些功能。

用戶故事應該回答3個問題：

• 我們為誰建造它？ - 作為<用戶類型>
• 我們在建什么？ - 我想<feature>
• 我們為什么要建造它？ - 這樣<值或利益>

在此之后，用戶故事的典型格式是：

作為<用戶類型>，我想要<feature>，以便<value或benefit>。

用戶故事示例：作為注冊用戶，我希望能夠將我的圖片下載到我的個人資料中，以便其他用戶可以看到我的樣子。

有沒有創建用戶故事的程序？

沒有正式的過程來創建用戶素材。盡管如此，還是應該遵循一條準則來創建一個好的用戶故事。它被稱為3 C，由極限編程的創始人之一Ron Jeffries提出。

• 該卡是用戶故事的書面說明。它沒有捕獲有關應該構建的內容的所有詳細信息。相反，它是一個提醒，是對必須進行的后續通信的承諾。
• 對話用于討論用戶故事的細節。它可能會被一些文檔補充。
• 確認由用戶驗收測試表示，確保用戶故事滿足用戶/客戶的驗收標準。

如何撰寫高質量的用戶故事

確保用戶故事具有適當質量的良好做法是遵守Bill Wake的INVEST首字母縮略詞的標準。INVEST還有助于確定用戶故事是否已被充分理解并為開發團隊開始工作做好準備。

• 獨立 - 用戶故事不應該依賴于另一個用戶故事，因此用戶故事可以按任何順序開發。
• 可協商 - 用戶故事的詳細信息通過產品負責人和開發團隊之間的口頭對話進行協商。
• 有價值 - 用戶故事應該為用戶/客戶帶來所需的價值。
• 估計 - 開發團隊應該很好地理解用戶故事來估計它。
• 小 - 用戶故事應足夠小，以適應迭代。
• 可測試 - 應為用戶故事編寫正確的驗收標準，以便進行驗證。

什么不是用戶故事？

讓我們對自己說實話：用戶故事不能通過其定義成為“技術用戶故事”，因為在這種情況下它不會給用戶/客戶帶來直接價值。不過，許多團隊喜歡在需要執行代碼重構等技術任務時創建用戶故事。我建議將其他工作項用于此類任務，并與您的產品負責人就此類工作達成一致，以便了解為何需要這樣做。這同樣涉及非功能性需求任務，界面設計任務，復雜的用戶交互任務或錯誤。您可以自由地為這些任務創建其他工作項。例如，Constraint Story可用于表示非功能性需求。用戶故事是捕獲產品功能的絕佳技術，但我們沒有義務將其用于所有目的。

誰是用戶？

在編寫用戶故事之前，應該清楚地了解創建用戶素材的用戶是誰。有時它被新用戶故事技術的團隊所忽視，他們最終創建了具有不必要功能的軟件。因此，做一個適當的用戶研究，讓你的所有用戶類型或用戶角色或角色寫下來并描述。可以幫助您解決此問題的兩種技術是用戶角色建模和角色。

誰負責撰寫用戶故事？

通常，客戶代表（例如產品負責人）負責用戶故事。盡管如此，用戶故事并不是從頂級到團隊的規范，而是產品負責人和團隊之間的協作技術。這就是為什么如果用戶故事是協作編寫的話會更好。一個很好的方法是做一個故事寫作研討會。

細節在哪里？

由于用戶故事不是規范，因此詳細信息以不同方式傳達：

• 3 C指南中的第二個“C”是Conversation。對話是敏捷最重要的方面之一。因此，大多數細節都是通過客戶代表和開發團隊之間的口頭溝通來傳達的。
• 第三個“C”是確認。用戶驗收測試確認用戶故事滿足用戶/客戶的驗收標準，并且它們用作正式的文檔詳細信息。BDD（行為驅動開發）是一種編寫驗收測試的好方法。
• 如果需要，某些用戶故事可能包含其他書面詳細信息。

你怎么知道用戶故事何時完成？

使用“完成定義”技術。簡而言之，Done的定義是團隊成員之間對工作完成意義的共同理解。完成的定義通常以活動清單的形式創建，其表明商定的價值（用戶驗收測試以滿足用戶驗收標準）和質量（以滿足質量標準）。團隊有時會忽略最后一個，在迭代結束時，什么可以使用戶故事不可能發送給客戶。完成技術的定義有助于避免這種情況。

完成定義的示例：

完成時間：

• 單元測試通過
• 代碼經過同行評審
• 用戶驗收測試通過
• 集成測試通過
• 回歸測試通過
• 用戶指南已更新

如何開始定義產品范圍？

在項目開始時，我們需要定義產品的粗略范圍，以便對其有全局視野。這可以通過Epics完成。史詩是一大塊工作，有一個共同的目標。Epic可以被視為占位符，用于稍后創建的更詳細的用戶故事。Epic通常需要多次迭代才能完成。

什么是組織用戶故事的最佳方式？

使用由Jeff Patton發明的故事映射技術 (User story Mapping)。故事映射代表了一種自上而下的需求組織方法，也是確定優先級和規劃的好方法。

對BABOK?Guidev2的敏捷擴展指出：

“故事映射提供了解決方案支持的活動序列的視覺和物理視圖。它使用二維網格結構來顯示產品在水平維度上的關鍵方面的順序和分組，詳細信息和優先級關于垂直維度的故事。故事映射是一種分解技術，它允許從端到端視圖開始逐步理解解決方案，并深入到詳細的用戶故事。

故事映射示例 (Visual Paradigm User Story Mapping)：

https://www.youtube.com/watch...

總結

以上是生活随笔為你收集整理的User Stories - 最佳实践 (Best Practices)的全部內容，希望文章能夠幫你解決所遇到的問題。

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