為什麼使用 User story
A story is a placeholder for a conversation.
User Story 的概念
過往我們對於提需求這件事存在著一個固定的ㄧ想法：先把需求規格定好，我們就照這個規格做好軟體給使用者。當然想也知道通常規格一定是一直改來改去的，所以有很多有趣的文章都在說明規格跟工程師之間的戰爭。
User Story 這一概念的出現就是希望解決前面的問題，User Story 不是一個刻板的、詳細的需求說明，而是一個高層次、靈活的描述，用以引導後續的開發工作。所以 User Story 的目的就是希望促進互動，並延遲到必要時才提供細節。
User Story 通過簡潔的敘述方式，鼓勵團隊成員之間的對話和討論。這種描述方式專注於用戶需求和期望的「什麼」和「為什麼」，而非具體的實現方式或技術細節。這種高層次的描述使得非技術人員也能參與到討論中，從而確保每個人對產品目標和功能有一致的理解。另外因為還不是很具體的敘述內容，可以引發更多人的討論跟對於 User story 內容的理解，確保在這個 User story 討論好以後是團隊的每個人皆有共識。
User Story 的另一個關鍵特點是其對細節的延遲提供。在初期階段，過於詳細的技術或設計規格可能限制思維，並可能在未來的開發過程中導致不必要的更改。隨著產品的進展和獲取到更多的資訊時，團隊可以逐步完善和細化需求。
有效的 User Story
User Story 通常遵循一個基本的格式：“As a [Role], I want [Feature], so that [Benefit].” 這裡的 [Role] 代表著一個特定的使用者群體而非個別使用者，這有助於從這個群體的特性出發，考慮其在系統中的利益。相對於 [Role]，我們還有 [Persona]，這是一個更加具體化的角色，代表個別的使用者，通常會有一個背景故事來描述這個角色的特點和需求。這些角色的描述幫助開發團隊理解和同理使用者，從而設計出更加符合使用者需求的功能。
有效的 User Story 應該是獨立的、可協商的、有價值的、可估計的、小而精的、並且可測試的（INVEST）。例如，一個過於龐大的 User Story 可能是：“As a user, I want a video app that lets me play, download, share, and create playlists of videos。” 這樣的故事過於廣泛，難以管理和實施。相反，它應該被分解成更小、更具體的故事，例如分開處理播放和下載功能。
在 User Story 的開發過程中，我們還需要考慮如何切割故事。橫向切割，即按照專業領域（如 UI, server side, DB）來分割故事，這種方法雖然在技術上可行，但有可能無法交付完整的功能，比如只有 UI 但是什麼功能都沒有，難以帶來真正的價值。相反的，所謂功能的縱向切割，即按照物件的功能來切割，我們交付較小的功能片段，使用者真正能使用這個功能，並使這個故事更容易被用來測試。
User story 的階層關係
User Story 還應該包括「Epic」和「Theme」。Epic 是一系列 User Story 的集合，用於描述達成特定目標的完整工作流程。而 Theme 則是追蹤一系列相關的故事，但這些故事可以獨立完成。例如，在我們的學習平台軟體中，一個 Epic 可能是關於建立和管理影片學習清單等一系列 User Story，而一個 Theme 則可能是關於提高使用者體驗的不同故事。
User story 的驗收
我們需要為制定的功能考慮「驗收標準（Acceptance Criteria, AC）」和「完成標準（Definition of Done, DoD）」。驗收標準為開發團隊提供具體的實作細節，幫助團隊明確理解何時 User Story 被視為完成。例如，在我們的前面的學習平台軟體產品中，驗收標準可能是：Given the user has selected a video, When they press the play button, Then the video should start playing without undue delay.。 DoD 確保產品符合品質標準，像是達成一開始團隊共同協商的測試覆蓋率、Code Reivew、部署和滿足 User story 驗收標準等等。
