撰寫使用者故事是任何進入敏捷環境的軟體工程師的基本技能。雖然許多團隊依賴數位平台來管理任務，但理解無需軟體依賴的使用者故事核心機制，能建立更堅實的基礎。本指南專注於手動流程，使用便利貼、白板和索引卡等實體工具來撰寫清晰且可執行的需求。目標是思維的清晰，而非螢幕操作的便利。
當你移除軟體後，便被迫深入參與內容。沒有自動完成功能或預設範本可供掩飾。你必須明確表達價值、行動者與需求。這種手動紀律確保團隊在撰寫任何程式碼之前，已充分理解問題範疇。以下，我們將探討故事的結構、接受標準，以及在無數位協助下優化想法的方法。
📖 理解核心概念
使用者故事是從渴望新功能的人的角度，對功能所做的輕量級描述，通常為系統的使用者或客戶。它不是規格文件，而是對話的佔位符。將故事寫在卡片或紙上這種具體行為，強化了這項意圖。故事應能被移動、編輯、丟棄或合併。數位系統往往過早將你鎖定在僵化的結構中。手動方法能讓故事保持流動性。
為什麼選擇手動？
有幾個令人信服的理由，讓新工程師特別應該練習手動撰寫故事：
- 專注於價值： 沒有欄位需要填寫，你便能專注於實際的價值主張。
- 認知負荷： 手寫會讓你放慢速度，有時間在投入文字前進行思考。
- 協作： 實體卡片讓團隊能實際移動工作，直觀地呈現流程與優先順序。
- 獨立性： 你將格式掌握得如此熟練，即使工具無法使用，也能撰寫出有效的需求。
📋 手動故事的結構
每個使用者故事都遵循特定結構。手動撰寫時，請在索引卡或便利貼上使用一致的格式。這種一致性讓團隊能在規劃會議中快速掃描資訊。標準格式包含三個明確部分，切勿跳過任何一項。
1. 角色身分（誰）
明確指出使用者的特定角色或類型。避免使用「使用者」等泛泛的詞語。務必精確。是「管理員」、「一般訪客」還是「付費訂閱者」？角色身分決定了功能的權限與使用情境。
2. 行動（做什麼）
描述使用者希望執行的功能或行動。這就是動詞。應為高階目標，而非技術實作細節。例如，「搜尋項目」比「將查詢輸入 SQL 資料庫」更佳。行動代表使用者的意圖。
3. 好處（為了）
這是最關鍵的部分，卻常被新手忽略。使用者為什麼想要這個？它能帶來什麼價值？如果你無法回答，這個故事可能並無價值。『為了』（So That）這段落將功能與商業或使用者成果連結起來。
範例結構
請寫在一或兩行內，保持簡潔。
- 作為 [角色身分]，
- 我想要 [行動]，
- 為了 [優勢]。
📝 定義接受標準
一個故事若沒有接受標準就不算完整。這些是故事被視為完成所必須滿足的條件。手動撰寫時，應直接列在故事卡下方，或附在卡片上的獨立紙張上。它們作為工程工作的測試案例。
接受標準能消除模糊性。它們定義了功能的範圍。若無此標準，兩位工程師可能會為同一個故事實作出不同的解決方案。手動撰寫能迫使你在開發開始前就思考邊界情況。
Given/When/Then 格式
為了精確的標準，請使用 Given/When/Then 結構。這是行為驅動開發（BDD）的手動翻譯。它能清楚地組織邏輯。
- Given： 初始的環境或狀態。
- When： 發生的事件或執行的操作。
- Then： 預期的結果。
範例標準
- 當使用者已登入時，
- 當他們點擊登出按鈕時，
- 則他們會被重定向到登入頁面。
- 當他們點擊登出按鈕時，
標準類型表
存在不同類型的標準。表格有助於在手動撰寫過程中對其進行分類。
| 類型 | 描述 | 範例 |
|---|---|---|
| 功能型 | 系統的特定行為 | 「系統在表單提交後發送郵件」 |
| 非功能型 | 效能或安全限制 | 「頁面載入時間少於 2 秒」 |
| 商業邏輯 | 資料管理的規則 | 「折扣僅適用於金額超過 50 美元的訂單」 |
| 可用性 | 易用性需求 | 「按鈕必須在不滾動的情況下可見」 |
🌐 使用 INVEST 模型進行驗證
手動撰寫完一個故事後，必須驗證其品質。INVEST 模型是此項工作的標準框架。你可以使用一張獨立的紙張上的清單，在將故事加入待辦事項之前進行評估。這能確保工作可管理且具有價值。
獨立性
這個故事應該是自包含的。它不應依賴於另一個故事完成後才具有價值。雖然存在技術上的依賴，但其價值應能獨立存在。如果你必須等待故事 A 完成才能開發故事 B，請考慮是否可以將故事 B 拆分。
可協商性
這個故事是一項討論的承諾，而非合約。它允許工程師與利益相關者之間進行對話。如果文字過於詳細，就會變成規格說明，而非故事。應為技術探索留出空間。
具有價值
每個故事都必須為使用者或企業帶來價值。如果一個故事無法有效滿足「所以」需求，就應該被捨棄或重新設計。價值是待辦事項的主要驅動力。
可估算
團隊必須能夠估算所需的 effort。如果一個故事過於模糊，就無法估算。如果過於複雜，應加以拆分。手動撰寫有助於識別模糊之處，因為你必須實際寫出細節。
小規模
一個故事應小到可以在單一迭代或衝刺內完成。大型故事具有風險，通常會導致工作無法完成。如果一個故事感覺像是一個專案，就應拆分成較小、順序性的故事。
可測試
你必須能夠驗證故事是否已完成。如果沒有接受標準，這個故事就無法測試。手動撰寫迫使你明確定義「完成」的樣貌。
INVEST 清單
在規劃期間使用此表格來審查你的故事。
| 字母 | 應提出的问题 | 狀態 |
|---|---|---|
| I | 這個故事能否在不依賴其他故事的情況下開發？ | [ ] |
| N | 範圍是否開放討論？ | [ ] |
| V | 它是否提供明確的價值？ | [ ] |
| E | 我們能猜測所需的努力嗎？ | [ ] |
| S | 它能在一個迭代中完成嗎？ | [ ] |
| T | 是否有明確的通過/失敗條件？ | [ ] |
🔍 製作流程
優化，也稱為潤飾，是為未來開發準備故事的活動。你不需要軟體來進行優化。事實上，將卡片在桌上移動的實際動作可以提升對流程的理解。優化會議包括審查故事、釐清細節，以及拆分大型項目。
步驟 1：審查
召集團隊圍坐在一張大桌旁。鋪開卡片。逐個朗讀每個故事。這個簡單的動作能發現靜默閱讀時看不見的錯誤。注意「所以」部分是否有模糊之處。
步驟 2：拆分
如果一張卡片感覺太沉重，就將它拆分。在新的卡片上寫下較小的新故事。將新卡片放在原卡片上方或旁邊。確保原卡片已更新以反映拆分情況。這種視覺上的分離有助於管理範圍。
步驟 3：提問
在審查過程中，團隊會提出問題。將這些問題寫在另一張紙上。不要立即回答。問題代表知識上的缺口。它們會成為下一次會議的行動項目。這能將規劃與回答分開。
步驟 4：排序
根據依賴關係或價值排列卡片。使用繩子或膠帶在桌上標示連結。如果卡片 A 必須在卡片 B 之前完成，就在兩者之間畫線。這種視覺流程能幫助在開發開始前識別瓶頸。
📈 權重排序技巧
一旦你有一份故事清單，就必須決定先建構什麼。手動排序方法通常比數位排序更有效，因為它涉及與工作的實際互動。
MoSCoW 法
用顏色標記你的卡片，或使用不同形狀來表示優先順序。這是一種經典的手動技巧。
- M – 必須擁有：對發佈至關重要。不容例外。
- S – 應該擁有：重要但非關鍵。如有需要可延後。
- C – 可能擁有：理想但非必要。
- W – 不會包含： 同意不包含在當前範圍內。
加權最短作業優先（WSJF）
若採用更數學化的做法，可為價值與時間分配數字。將數字寫在卡片上，手動計算比例。這能迫使團隊量化價值，而非依賴直覺。對新工程師而言，這是一項極具價值的練習，有助於理解商業上的權衡取捨。
⚠️ 應避免的常見陷阱
即使採用手動方式，錯誤仍會發生。新工程師在缺乏軟體驗證指導的情況下撰寫故事時，經常陷入特定陷阱。
1. 技術用語
不要從系統的角度撰寫故事。避免使用「資料庫」、「API」或「後端」等詞語。應從使用者的角度出發。系統對使用者而言是不可見的。若你寫下「系統更新快取」，使用者並不在意。他們關心的是頁面的載入速度。
2. 缺少接受標準
很容易只寫「作為…」的部分，卻遺忘「為了…」或標準。沒有標準的故事只是一項待辦事項，而非使用者故事。這會造成模糊不清。在卡片被視為完成前，務必要求提供標準。
3. 細節過多
撰寫故事並非撰寫規格書。若你在單張卡片上寫了五段文字，很可能已經過度細節化。保持卡片簡潔。細節應出現在釐清過程中的對話中，而非直接寫在卡片上。
4. 忽略邊界情況
手動撰寫常著重於順利流程。你必須明確寫下事情出錯時的處理方式。為錯誤狀態加入標準。「當網路中斷時，使用者提交後，應顯示重試訊息。」
5. 缺乏合作
單獨撰寫故事是浪費時間。故事是啟發對話的起點。若你未與同儕討論就撰寫故事，很可能會被誤解。務必與同事手動審核。
👩💻 後續轉向數位系統
雖然本指南專注於手動方法，但團隊最終會轉向數位系統進行追蹤與報告。你在此學到的技能可直接轉移。當你最終使用數位平台時，將能撰寫出更優質的故事，因為你已理解核心結構。你不會再依賴軟體來定義價值。
若基礎扎實，轉移過程將順利無阻。數位工具成為你已仔細思考過的手動工作的儲存庫。你只需將卡片內容複製到系統中。邏輯保持不變。
📝 新工程師的實務練習
為鞏固這些概念，請嘗試以下練習。此練習無需軟體，僅需紙張與筆。
- 步驟 1： 選擇一個你每天使用的功能（例如網站上的搜尋欄）。
- 步驟 2： 使用標準格式在索引卡上撰寫使用者故事。
- 步驟 3： 使用「給定／當／則」格式撰寫三個接受標準。
- 步驟 4： 將 INVEST 模型檢查清單套用至卡片上。
- 步驟 5： 記下兩個你對這個故事的疑問，這些疑問是開發人員會提出的。
- 步驟 6： 與同事一起審查這張卡片，請他們批評「所以」部分。
💬 對手動紀律的最終思考
掌握使用者故事的藝術在於精確與同理心。你需要設身處地站在使用者的角度思考。你需要表達清晰且簡潔。手動流程能去除軟體介面的雜訊，只留下核心訊息。這種紀律讓你成為更優秀的工程師，也讓你成為更出色的溝通者。
當你去除工具後，剩下的只有邏輯。正是這份邏輯驅動著軟體。透過手動練習，你能在請求電腦執行之前確保邏輯正確。這種方法能減少重做，提升品質。這是一種對自己定義價值能力的沉穩自信。
請記住，目標不是填滿數位待辦事項清單。目標是為一個人解決問題。保持人類在流程中。讓故事簡單明瞭。讓標準清晰明確。無論你最終使用什麼工具，這些原則都會讓你受益良多。
📊 重點收穫摘要
- 結構： 始終使用「作為一名…，我想要…，所以…」的格式。
- 標準： 定義「給定/當/則」以確保清晰。
- 驗證： 最終確認前，依照 INVEST 標準進行檢核。
- 協作： 與團隊實際審查卡片。
- 重點： 优先考慮使用者價值，而非技術實現。