蒐集 Story 不等於蒐集需求#

傳統的需求蒐集（Requirements Gathering）試圖在專案早期就抓取所有需求。但 User Story 強調的是持續性的對話，而非一次性的蒐集活動。

不要試圖在專案初期就蒐集到所有 Story。Story 應該隨著專案的進行逐步浮現和精煉。

蒐集 Story 的技巧#

Story 撰寫工作坊#

這是最有效的蒐集方式。將客戶、開發人員和測試人員聚在一起，進行集中式的 Story 撰寫：

1. 從使用者角色出發：逐一檢視每個角色的需求
2. 限時且密集：通常 2-4 小時即可產出大量 Story
3. 不追求完美：先寫下所有想到的 Story，稍後再整理

使用者訪談#

直接與真實使用者對話，了解他們的工作流程和痛點：

• 聚焦於使用者的目標，而非他們想要的功能
• 詢問「你目前是怎麼做的？」比「你想要什麼功能？」更有效
• 觀察使用者實際操作，往往比訪談更能發現需求

問卷調查#

當無法直接接觸大量使用者時，問卷可以作為補充：

• 適合蒐集廣泛但淺層的資訊
• 不適合深入探索複雜的需求

最佳的蒐集方式是混合使用多種技巧。工作坊產出初始 Story，訪談深入探索關鍵角色的需求，問卷驗證優先順序。

分解 Epic Story#

在蒐集階段，經常會產出過大的 Story（Epic）。需要適時拆分：

• 封閉式 Story（Closed Story）：完成後使用者能達成一個有意義的目標
• 開放式 Story（Open Story）：範圍不明確，需要進一步拆分

拆分 Story 時，應確保每個子 Story 都是「封閉的」——也就是說，使用者完成它後能獲得某種有意義的價值。

不要忘記的事項#

在蒐集 Story 的過程中，容易忽略以下幾類需求：

• 非功能性需求：效能、安全性、可用性等（以約束條件表達）
• 錯誤處理：當事情出錯時，系統應該如何反應
• 管理功能：系統管理、資料維護等後台功能
• 報表與分析：資料查詢、統計報表等