什麼是 Sprint 任務看板

---

什麼是 Sprint 任務看板？

Sprint 任務箱是一段時間區間。每個 Sprint 都有開始和結束日期，在此期間必須完成並確認一組選定的使用者故事。下圖展示了 Sprint 的關鍵元素，包括一組使用者故事、參與的 Scrum 成員、工作指派、持續時間和結束日期（右上角）。

在 Sprint 開始時，產品負責人、利害關係人與開發團隊會共同聚會，以優先排序並選擇在該 Sprint 中要完成的使用者故事。由於各方對專案與專案進度有不同的偏好、考量與關切，會議的目的在於讓不同參與者有機會聆聽並理解彼此的觀點，並共同達成一組所有參與方都同意的使用者故事。

Sprint 持續時間

快速交付高品質的工作是軟體團隊選擇採用敏捷軟體方法論的原因之一。因此，儘管並不存在適合所有情況的 Sprint 持續時間，但普遍共識是持續時間應盡可能短。但究竟要多短呢？

雖然較長的 Sprint 持續時間並非理想，但過短的 Sprint 持續時間可能會削弱開發團隊完成重要工作的動力，甚至導致交付成果品質不佳。

因此，Sprint 持續時間的選擇是整個團隊——包括產品負責人、Scrum 主管以及資料庫設計師、程式設計師、UX 設計師、測試人員、分析師等 Scrum 成員——共同討論的結果。但最終仍需有人做出決定，在那一刻，Scrum 主管通常會提供答案。

傳統上，Sprint 持續時間為三週至一個月，但如今越來越多團隊成功採用兩週 Sprint。畢竟，Sprint 持續時間並無固定選擇。一位優秀的 Scrum 主管應具備協作與促進的技巧，以決定合適的 Sprint 持續時間，確保工作能如期完成。以下是 Scrum 主管可能考慮的一些因素：

1. 協議的專案進度
2. 客戶/利害關係人/產品負責人的可取得性（能釐清潛在疑問的人）
3. 客戶的工作文化
4. Scrum 團隊的能力
5. Scrum 經驗

一旦團隊達成共識，未來所有 Sprint 都將遵循相同的持續時間，不會在每次 Sprint 之間頻繁變更。然而，持續檢視 Sprint 的成效，並找出最適合所有人的最佳 Sprint 持續時間，是一項良好的實務做法。

Sprint 中工作（使用者故事）的確認

Sprint 開始後，開發活動便圍繞著使用者故事展開，隨著 Sprint 的推進，越來越多的使用者故事被實現。然而，使用者故事的完整實現並非故事的結束，仍有一個重要的步驟需要完成——確認。

確認一個使用者故事，就是測試已實現的功能，並判斷該功能是否如預期般實現。判斷應僅基於在詳細說明使用者故事時所建立的標準，以確認項目形式呈現。在確認過程中，產品負責人會獲得一個測試環境或設備，用以測試已實現的工作。產品負責人將逐一檢視使用者故事上所列的確認項目。若所有項目均確認完成，則該使用者故事即被視為已確認。若發現任何項目未完成或未如預期運作，產品負責人將要求開發團隊進行修正。修正與確認流程將重複進行，直到使用者故事完全確認為止。

何時進行確認？

Sprint，事實上敏捷開發是一種持續交付的流程。不應等到 Sprint 結束時才確認使用者故事，而應在任何使用者故事完成後立即進行確認。然而，若產品負責人無法參與持續確認，可安排每週一次、每次 1 至 2 小時的會議。在會議中，產品負責人將與團隊一起確認已完成的使用者故事，會議也包含討論環節，用以釐清在實現 Sprint 中其他故事時所發現的疑問。

確認並非等同於測試

如前所述，確認的目的在於確保使用者故事被正確實現。判斷應僅基於在詳細說明使用者故事時所設定的確認項目，不多也不少。這種檢查的範圍遠不足以確保功能已準備好投入生產使用。那麼，何時進行「真正的測試」？

不同團隊在軟體測試方面有不同的做法。有些團隊偏好在每個 Sprint 結束時進行測試，包括整合測試與回歸測試。有些團隊則偏好設立一個穩定化 Sprint，正如其名稱所示，專注於測試與除錯。在該 Sprint 中不會進行任何新的開發活動。

無論你選擇哪種方法，請記住，這個選擇不是任何一個人的決定，而是所有人的共識。

Visual Paradigm 提供您在 敏捷軟體開發 中所需的所有工具，包括 UML 使用案例圖工具 , (敏捷) 使用者故事, 冲刺, 故事板 和 線框圖 用於 UX 設計，任務管理工具，等等