案例研究：行動支出追蹤應用程式
作為一個軟體開發團隊，你們被委派開發一款行動支出追蹤應用程式。該應用程式應協助使用者追蹤每日支出、分類消費項目，並設定預算目標。目標是提供使用者一個直覺易用、高效且功能豐富的應用程式，可在 Android 與 iOS 平台上使用。
為了模擬此專案的產品待辦事項清單，我們來建立一個包含多個使用者故事、其優先順序、估計值（以故事點計）及驗收標準的表格。
| 使用者故事 | 優先順序 | 估計值 | 驗收標準 |
|---|---|---|---|
| 使用者驗證 | 高 | 8 | – 使用者可使用電子郵件與密碼註冊。 – 使用者可使用其憑證登入。 – 密碼會安全儲存並雜湊處理。 – 使用者若遺忘密碼，可重設密碼。 |
| 支出輸入 | 高 | 13 | – 使用者可輸入新的支出，包含標題、金額、日期與類別。 – 使用者可編輯現有的支出。 – 使用者可刪除支出。 – 支出會儲存在資料庫中並可取出。 |
| 支出類別 | 中 | 5 | – 使用者可建立自訂的支出類別。 – 支出可指派至特定類別。 – 使用者可編輯與刪除類別。 |
| 支出分析 | 中 | 8 | – 用戶可以查看每月和每年的支出報表和圖表。 – 支出會根據用戶定義的規則自動分類。 – 用戶可以為不同類別設定預算目標。 |
| 雲端同步 | 高 | 13 | – 用戶資料可在各裝置間同步。 – 數據安全儲存在雲端。 – 支援離線存取，並透過本地資料儲存。 – 在一台裝置上所做的變更會反映在其他裝置上。 |
| 貨幣轉換 | 低 | 3 | – 用戶可選擇其偏好的貨幣。 – 支出金額會根據所選貨幣自動轉換。 |
| 指紋/面容辨識驗證 | 低 | 5 | – 用戶可啟用生物辨識驗證以增加安全性。 – 應用程式支援 Touch ID（iOS）、Face ID（iOS）或指紋（Android）驗證。 |
| 匯出資料 | 中 | 8 | – 用戶可將支出資料匯出為 CSV 格式。 – 匯出的資料包含所有支出細節，包括日期和類別。 – 資料可透過電子郵件傳送或儲存至本地。 |
| 通知提醒 | 中 | 8 | – 使用者可以設定每日、每周或每月的支出提醒。 – 提醒會觸發帶有預設訊息的通知。 |
| 支出排序 | 低 | 3 | – 使用者可以按日期、金額或類別對支出進行排序。 – 排序順序可以是升序或降序。 |
此表格模擬了開發行動支出追蹤應用程式時的簡化產品待辦事項清單。每個使用者故事根據其對專案的重要性進行優先排序，以故事點數估算其複雜度，並具備明確的接受標準，以定義何時視為完成。此待辦事項清單作為衝刺規劃的起點，確保開發團隊與利害關係人對專案範圍與優先順序有共同的理解。
從產品待辦事項到衝刺規劃
衝刺規劃是敏捷專案管理中至關重要的環節，它涉及從產品待辦事項中選擇一組使用者故事，以在接下來的衝刺期間進行開發。衝刺規劃通常包含兩個部分：衝刺規劃會議與衝刺待辦事項建立。讓我們根據您提供的產品待辦事項，逐步說明如何規劃一次衝刺：
步驟 1：定義衝刺目標
- 從討論即將到來的衝刺的整體目標或目的開始衝刺規劃會議。例如，在您的情況下，目標可能是：「本次衝刺的目標是實作基本的驗證功能與基本的支出輸入功能。」
步驟 2：決定衝刺時長
- 決定衝刺的時長。常見的衝刺時長為兩週、三週或一個月。選擇最適合您團隊與專案的時長。
步驟 3：選擇使用者故事
- 檢視產品待辦事項，並與開發團隊及產品負責人合作，選擇一組在衝刺期間可實際完成的使用者故事。考慮使用者故事的優先順序、估計值與依賴關係。同時記住團隊的速度，即根據過去表現，團隊在一次衝刺中可完成的工作量。
例如，假設您的團隊在兩週的衝刺中可完成總計 30 個故事點的使用者故事。根據此容量，您可能選擇以下使用者故事：
- 使用者驗證（8 個故事點）
- 支出輸入（13 個故事點）
- 貨幣轉換（3 個故事點）
- Touch ID/Face ID 驗證（5 個故事點）
此選擇總計 29 個故事點，接近您團隊的容量。
步驟 4：拆分使用者故事（如需）
- 如果所選的使用者故事過於龐大或複雜，可考慮將其拆分成更小、更易管理的任務或子故事。確保這些子故事定義明確，並具備清晰的接受標準。
步驟 5：估算任務
- 以小時或故事點估算每個選定的使用者故事或子故事所需的投入。這有助於團隊理解工作負荷，並確保衝刺保持可管理。
步驟 6：建立衝刺待辦事項
- 為每個選定的使用者故事或子故事建立任務清單。包含預估的工作量，並根據成員的技能與可用性分配任務。這將成為您的衝刺待辦事項。
以下是一個衝刺待辦事項可能的樣貌：
即將進行的兩週衝刺之衝刺待辦事項
| 使用者故事 | 任務描述 | 預估努力程度 | 指派給 |
|---|---|---|---|
| 使用者驗證 | 實作註冊邏輯 | 4小時 | 開發人員A |
| 使用者驗證 | 實作登入邏輯 | 6小時 | 開發人員B |
| 費用輸入 | 設計費用輸入表單 | 5小時 | 設計師 |
| 費用輸入 | 實作費用表單使用者介面 | 8小時 | 開發人員C |
| 費用輸入 | 為費用建立資料庫結構 | 4小時 | 資料庫專員 |
| 貨幣轉換 | 新增貨幣選擇功能 | 2小時 | 開發人員D |
| 觸控ID/面容辨識驗證 | 實作生物辨識驗證（iOS） | 8小時 | 開發人員E |
步驟7：承諾完成 Sprint
- 在 Sprint 計劃會議期間，團隊承諾在 Sprint 期間完成所選的使用者故事和任務。此承諾確保團隊專注於交付計畫中的工作。
步驟8：制定 Sprint 目標
- 根據所選的使用者故事和任務，明確且簡潔地闡述一個 Sprint 目標，總結團隊在 Sprint 結束時希望達成的成果。此目標提供對 Sprint 目的的共同理解。
步驟9：審查並結束 Sprint 計劃會議
- 在結束會議之前，確保每位成員都理解 Sprint 目標、所選的使用者故事及其相應任務。解決任何疑問或擔憂，並正式啟動 Sprint。
在整個 Sprint 期間，舉行每日站會以追蹤進度，必要時進行調整，並確保團隊按計畫達成 Sprint 目標。在 Sprint 結束時，進行 Sprint 回顧，向利益相關者展示已完成的工作並收集反饋。最後，舉行 Sprint 回顧會議，反思 Sprint 的流程，並找出未來 Sprint 改進的領域。
結論
Sprint 計劃是連接產品待辦事項與實際開發行動的關鍵橋樑，也是敏捷專案管理中的核心環節。這是一個協作且動態的過程，讓團隊能夠選擇並承諾完成特定 Sprint 中明確定義的使用者故事或任務。透過仔細考量優先順序、依賴關係與估算，Sprint 計劃確保團隊與整體專案目標保持一致，並能逐步為客戶創造價值。
有效的 Sprint 計劃不僅僅是任務分配；它促進清晰的溝通，賦予團隊成員對自身工作的主導權，最終形成一個引導團隊努力的 Sprint 目標。定期進行 Sprint 計劃，搭配每日站會、Sprint 回顧與回顧會議，構成了敏捷開發的核心動力，使團隊能夠適應變化的需求，保持專注，並持續改進其流程。
透過掌握 Sprint 計劃的藝術，敏捷團隊能夠精準應對軟體開發的複雜環境，確保每個 Sprint 都讓團隊更接近交付符合客戶需求、推動業務成功的卓越產品。這是一種體現敏捷原則——協作、回應力與以客戶為中心——的實踐，使其成為敏捷專案管理的基石。