解決每週 Sprint 面臨的挑戰：我們團隊的實踐分享

我們團隊已經運行每週一個 Sprint 的模式有一段時間了。雖然這樣的短周期確實帶來了不少靈活性，但也暴露出了一些問題：

[問題 1: 零碎的工作時間]

我們原本的操作方式是將 Planning 定在每週一下午 2 點，然後週五下午 2 點進行 Review 和 Retrospective。這樣雖然有頭有尾，但實際上使得工作時間變得非常零碎。一週中最重要的兩天變成了週一和週五，而這兩天又是最容易出現請假或插入其他會議的時候，進一步打破了本來就零碎的時間。

[問題 2: 空窗期]

在這種玩法下，我發現團隊成員往往會趕在週五的 Review 前完成工作，接著就會有一個從週五下午到週一下午的喘息期。然而，這段空窗期其實並不輕鬆，大家經常在這段時間內補做那些尚未完成的項目（聽起來很奇怪吧？已經進行了 Review，但項目還沒真正完成）。

[問題 3: 什麼時候進行 Product Backlog Refinement?]

由於時間分散，Product Backlog Refinement 很難進行。而沒做 Refinement 的結果就是大家的目光只聚焦在當前這個 Sprint 上，導致有時候無法有效應對未來的挑戰。過去，我們曾多次遇到這種情況，導致 Sprint 失敗。不過，接下來我會介紹我們如何將所有活動集中到同一天，這也為導入 Refinement 提供了機會。

解決方案 1: ScrumThon

為了解決零碎時間和空窗期的問題，我做了一個改變：將 Planning、Review 和 Retrospective 合併到同一天，形成我們的「ScrumThon」。

現在我們的團隊固定在每週二召開 ScrumThon，具體安排如下：

• 上午 11:00 至 12:00 進行本 Sprint 的 Review。
• 下午 14:00 至 18:00 進行本 Sprint 的 Retrospective 以及下一個 Sprint 的 Planning。

這樣的安排使得團隊成員擁有了更多不受打擾的工作時間。運行幾週後，我觀察到最大的改進就是未完成項目的大幅減少。

同一天進行 ScrumThon 還有另一個好處，就是建立了固定的節奏。長此以往，大家都知道這一天就是用來進行 Scrum 活動和 Sharing 的，不需要再額外預定時間來進行這些活動。

解決方案 2: Planning 直接討論 2 個 Sprint 的 Story

我的實踐是直接讓大家在 Planning 中討論 2 個 Sprint 的 Story，然後將其中 1 個 Sprint 的範圍拉入當前的 Sprint。這樣我們就能在 Planning 時順便 refine 下一個 Sprint 的內容，讓大家可以展望後面的一個 Sprint，進行更長遠的規劃。

解決方案 3: Deployment Board

由於我們是開發兼維運的團隊，前面提到過看得太淺的問題，確實造成了部署延遲的情況。為了解決這個問題，我準備了一個小白板，在上面劃分了 6 週的格線，並在上面貼上預計何時將部署到哪個環境的便利貼。每週調整一次，隨著新的週期開始，補充最後一格。這種視覺化的方式讓 QA 團隊能夠清晰地了解接下來 6 週的部署計劃，每次與 Product Owner 溝通時，直接展示這個 Deployment Board 就能一目了然。

結論

以上就是我們目前採用的 3 個實踐：

1. 同一天的 ScrumThon
2. 直接討論 2 個 Sprint 的 Planning
3. Deployment Board

ScrumThon 的實踐故事請參考下一篇唷

這些措施能否徹底解決每週 Sprint 所帶來的問題呢？讓我們拭目以待。