系統分析師撰寫的需求規格書，通常就像厚厚的小說一樣，讓人看了直呼「這裡面到底有什麼？」不過，這彷彿是為了展現自己需求分析的功力，或為了讓需求規格滴水不漏。隨著敏捷開發的興起，我們學會了利用 「User Story」 的方式來撰寫一份連使用者都能讀懂的需求書，這可是讓各種角色之間了解系統需求時 縮小認知落差 的好幫手！

何謂「User Stroy」?

簡單來說，它是一種用來描述功能需求的方法，通常以 「身為一位...，我想要...，這樣我能...」 的形式來表達，這樣的結構不僅幫助團隊聚焦於使用者的需求，也能確保大家都在同一個頻道上。

那麼，面對過去那厚厚的「需求規格書」，我們該如何將它轉換成一個個「User Story」呢？

首先我們要先了解何謂 「最小可行性」（Minimum Viable Product, MVP） 的概念，最小可行性是指在產品開發過程中，能夠 滿足基本需求 並提供最小功能集的版本，旨在快速驗證市場需求並獲得使用者反饋。簡而言之，就是在 不過度開發 的情況下，提供一個足夠的產品，以便進行測試和迭代。

如何切故事？

以「最小可行性」為中心思想，我們就可以開始切故事，這裡有一些步驟來幫助我們將最小可行性融入故事切割的過程：
1. 識別核心功能： 首先，確定對於某個功能而言，最基本的需求是什麼，以「職務主檔維護」為例，最小可行的功能可能是新增職務主檔，因為這是讓HR人員開始管理職位的必要步驟。
2. 拆分故事： 在明確核心功能後，可以將其餘功能拆分成多個User Story，例如，在「職務主檔維護」中，除了新增功能外，其他功能如修改、刪除、檢視、查詢等都可以被視為後續的增強功能；每一個故事都應該能在一個衝刺中完成，以便在每個迭代中交付可用的成果。
3. 量化使用者價值： 每個User Story都應該帶來明確的使用者價值，這有助於確定其在最小可行性中的優先級。例如，新增職務主檔能立即讓HR部門開始使用系統，而修改或刪除功能則可作為後續增強。
4. 驗證與反饋： 在每個衝刺結束後，讓團隊和使用者進行回顧，檢視已交付的功能是否滿足需求，這不僅能獲得實際的使用者反饋，還能針對未來的功能迭代進行調整。

舉例來說，假設我們正在開發一個HR系統的「職務主檔維護」功能，這個功能可以讓使用者進行新增、修改、刪除、檢視和查詢職務主檔；在這樣的情況下，我們可以將這個大的需求切分成幾個User Story：
1. 身為HR人員，我想要 新增 職務主檔，這樣我能夠管理新的職位需求。
2. 身為HR人員，我想要 修改 職務主檔，這樣我能夠更新現有職位的資訊。
3. 身為HR人員，我想要 刪除 職務主檔，這樣我能夠移除不再需要的職位。
4. 身為HR人員，我想要 檢視 職務主檔，這樣我能夠快速了解公司內所有的職位。
5. 身為HR人員，我想要 查詢 職務主檔，這樣我能找到特定職位的詳細資訊。

切故事的時候，故事大小 也是一個需要考量的因素，每個User Story都會點數，這代表著它的複雜度和工作量。那麼，如何拿捏故事的大小呢？一般來說，可以參考以下幾個指標：
1. 獨立性： 每個User Story應該儘量獨立，這樣團隊能夠並行開發，提升效率。
2. 可測試性： 每個故事都應該能夠被清楚地測試，確保達到預期效果。
3. 業務價值： 每個故事都應該提供明確的業務價值，幫助團隊理解其重要性。

一般而言，若某個User Story的 點數過高 ，那可能意味著它需要 被拆分成 更小 的故事，這樣不僅能提高可管理性，還能幫助團隊在 短時間內交付 有價值的功能。

一個好故事 = 最小可行性 + 預估故事點數

最小可行性與預估故事點數的結合，讓我們能夠在每個衝刺中交付有價值的成果，避免過度開發及資源浪費，透過持續的驗證與迭代，我們可以更快地調整產品方向，滿足使用者需求，最終提升產品的市場競爭力。

在未來的文章中，將會繼續探討更細節如何描述User Story的內容，並分享撰寫AC的技巧，讓大家都能寫出人人看得懂的需求故事！