我如何規劃軟體團隊的 Sprint

前言

這篇文章分享我目前團隊的 Sprint 規劃方式。做法和標準敏捷開發略有不同，差異和原因會在後段說明。這套流程目前運作良好，但並非放諸四海皆準。我將流程腳本化，確保會議專注並涵蓋所有重點。

Sprint 週期通常為 1 到 3 週（視團隊規模而定，盡量縮短）。每次規劃都從複製好的 Notion 範本開始，裡面會記錄想法和主題。

腳本內容

以下依序進行。

閒聊（最多 5 分鐘）

每位成員同時花幾分鐘寫下近況，例如週末活動、最近玩的遊戲、興趣等等。範例：

* Jack
  * 看了最新的漫威電影，很讚
  * 打保齡球
* John
  * 在家耍廢
* James
  * 玩幻獸帕魯！

如果有共同話題，可以稍微聊一下，例如「我也在玩幻獸帕魯！」。主要目的是讓大家放鬆心情、暖場，尤其在週一早上的會議特別有用。時間不宜過長。

管理層同步重點

我會分享主管提供的、可能影響團隊的資訊，例如其他團隊正在研究的新技術，或是他們遇到的問題，我們或許可以協助解決。

上個 Sprint 的心得

每位成員同時寫下對上個 Sprint 的想法。建議參考 Linear 裡的紀錄。可能的回饋：

• 覺得蠻順的，完成很多工作
• 花很多時間回覆 Slack 訊息，但沒記錄到
• WAF 專案比預期花更多時間
• Bob 先生一直私訊問我 X 的問題
• 學 Z 框架有點卡
• Y 這張工單一直延宕，不太開心

重點不是讓我（主管）挑毛病，而是讓大家暢所欲言，討論 Sprint 流程的優缺點。例如，成員應專注自身而非他人的進度。團隊一起腦力激盪，找出改善方法或影響團隊效率的共同問題。與其在 1 對 1 會議中私下抱怨，不如公開讓其他成員知道，或許能獲得協助或建議。

待辦事項

這是 Notion 範本裡的共享區塊，會列出我們想改善 Sprint 流程的小地方。例如：

• 將私訊移到公開頻道討論
• 為開發者常問的問題寫文件
• 優先處理高優先級工單
• 如果 X 再發生錯誤，記得設定警報

這份清單會動態調整，通常只有 2 到 3 項，提供快速參考。內容來自上週「上個 Sprint 的心得」。如果順利解決，就移除該項；若未解決且仍相關，就保留。也會加入這個 Sprint 遇到的阻礙。

確認特殊事項

為了掌握全局，我們會確認是否有任何事項會影響 Sprint 節奏，例如連假、公司活動等等。也會確認值班人員，方便安排工作。

檢視延續的工作

Linear 會在週日晚上自動關閉上個 Sprint，週一早上開啟新的，並將未完成的工作延續到新的 Sprint。我們會先討論這些工作是否仍需執行或是否仍為優先事項。如果一直延宕，可能會將其移回待辦清單（通常表示不重要）或取消。之後我會私下和成員討論延宕的工作，尤其是有績效疑慮時，但公開場合仍以任務討論為主。

檢視承諾事項

我們的團隊負責許多專案，常會收到其他開發者提出的需求。我們會溝通預計完成的時間，並將這些工單預先放到對應的 Sprint，標示為「未指派」。規劃會議時，會檢視這些工單並指派負責人。

檢視進行中的主要專案

我們的 OKR 是團隊的主要目標。在 Linear 裡，這些專案會被歸類到當季（Q1/Q2 等等），狀態為「進行中」。我們會逐一檢視每個專案，由專案負責人說明需要完成的工單，再分配工作。

專案完成後會關閉，團隊繼續處理其他「進行中」的專案。如果「進行中」的專案不多，就會從待辦清單中挑選新的專案開始進行。我們會盡量減少同時進行的專案數量。

檢視總指派點數

我們會追蹤每位成員平均每 Sprint 完成的點數，並與這次的總點數比較。如果工作太多，會調整點數（縮小範圍）或取消指派。沒有最低點數要求，但有設定上限，盡量避免「說得多做得少」。

發布公司公告

目的不是炫耀成果，而是提供以下資訊：

• 可能影響其他團隊的基礎設施異動
• 我們正在研究的新技術

公告會發布在公開的 Slack 頻道，範例如下：

:wave: 即將異動 :wave:
* 預計在 *這裡* 的時間，將測試環境資料庫從 PG14 升級到 PG15。
** 已通知相關團隊，請在升級後的一到兩週內測試資料庫 API。
* 將在 X:00 PM 重啟正式環境負載平衡器，以遷移到 ARM 執行個體。期間可能會有短暫連線問題。
** 詳細資訊請參考 *這裡*。
* 正在研究用 Kafka 解決先前的訊息問題。

重點是不要列出所有工作內容，而是聚焦會直接影響其他員工的事項。另外，我們覺得預告新技術蠻有用的，或許能獲得其他團隊的建議，例如「我在 X 公司用過 Kafka，建議你們改用 Y」。

附錄：規劃流程中未包含的內容

待辦清單

當工作多到做不完時，就會放到待辦清單。只有在有人想做的時候，才會從待辦清單中取出。其實門檻不高，只要有人表示這件事很重要，通常就夠了。否則，我們會在每季規劃 OKR 時檢視待辦清單。

活文件

我們的 Sprint 規劃腳本會持續更新。例如，有一次我們因為忘記公司全員大會而超量承諾工作，所以新增了「確認特殊事項」這個步驟。

無獨立的 Sprint 回顧會議

標準敏捷開發會另外舉行 Sprint 回顧會議。Atlassian 的資料顯示，這類會議可能需要 45 分鐘到 3 小時。我認為「上個 Sprint 的心得」已涵蓋回顧會議的重點，而且可以省下一次會議，這對時間有限的 Sprint 來說很值得。所有會議，即使看起來很簡單，都會佔用不少時間。

無 Sprint 檢視

Sprint 檢視的目的是展示團隊成果。但久而久之，很容易變成炫耀大會，失去原本迭代回饋的意義。我們會以非同步訊息的方式分享新功能，並通知相關人員進行測試和提供回饋。

無 Sprint 目標

標準敏捷開發會設定 Sprint 目標。由於我們的工作範圍很廣，所以沒有特別設定單一目標。我蠻認同這篇文章的觀點，尤其是「有些團隊就是有很多事情要做」。

工單格式

工單的格式如下：

問題：

行動：

驗收標準：

詳細程度視問題的複雜度而定。簡單的工單可以簡潔扼要。例如：

工單標題：提高 CLI 測試覆蓋率
---
問題：上週 CLI 的資料庫存取功能壞掉了
行動：擴展 ./cli/db 模組的測試覆蓋率
驗收標準：至少涵蓋 ./cli/db/Auth 結構

不需要為了追求教科書式的完美工單而浪費時間。如果符合以下條件，可以簡化工單內容：

• 開發者…
  • 經驗豐富
  • 都能理解你的需求
  • 熟悉程式碼或問題
  • 是你的團隊成員或密切合作的夥伴
  • 能穩定交付成果
• 工作…
  • 最糟情況影響不大（例如單元測試、測試工具等等）
  • 沒有明確的期限
  • 有很多解決方案，你不在意用哪一種

相反地，如果符合以下條件，則需要更詳細的工單內容：

• 開發者…
  • 經驗不足
  • 容易誤解需求
  • 不熟悉程式碼或問題
  • 屬於其他團隊
  • 經常延遲工作或正在績效改進計畫中
• 工作…
  • 最糟情況影響很大（例如資料庫升級、安全性問題等等）
  • 這週必須完成
  • 有很多解決方案，但團隊希望採用特定方案

你如何規劃 Sprint？

歡迎分享你的 Sprint 規劃方式！我很樂意學習和交流，讓我們的流程更完善。請在下方留言。