Scrum，但每週只用一小時

傳統 Scrum 所需要的會議時間一直為人詬病，要怎麼保留 Scrum 的優點又不用花那麼多時間呢？在歷經嘗試後，我發展出了一套保留優點又不花那麼多時間的方法。

經典的 Scrum 是每兩週一個循環，包含 Planning、Review、Retrospective、Stand-Up 等會議，會議時間平均每週就要 2–4 小時，還不含負責人準備會議需要付出的額外時間。我的版本則是一週 0.5–1 小時，是 2–8 倍的效率差異。

我已經在無數個專案中驗證了這套方法，很多專案每週例會還遠低於一小時，同時維持著高度的向心力。想把思路分享給你，期待你也能從中得到啟發，一起用最小的成本創造最大的價值。

一起用最少時間創造最大價值！Photo by Thomas Bormans.

重新提取 Scrum 中有效的要素

軟體開發包含了許多不穩定的因素，例如修改一段程式碼看起來簡單做起來難，軟體工程師經常也是開工了才發現坑比預期多。不過也是 Scrum 擅長面對的情境，因為 Scrum 不做一次性的計畫，而是根據情況定期調整，這是讓 Scrum 有效的要素之一。

只要能夠維持計畫與覆核（Planning & Review）的節奏，也就是每次計畫的事情，下次都有完成，就能夠確認團隊的速度；甚至若能夠再確認總事項收斂，就可以預測完工時間。這是讓 Scrum 有效的要素之二。

讓 Scrum 有效的要素之三是回顧（Retrospective），在 Retro 中我們分享對於協作的 Thanks & Good，這可以在無形之中拉近成員的距離，形成團隊感；我們也在 Retro 中分享 Better & Ideas，讓協作問題有機會被說出來，進而能夠被解決。

找到了這三個要素後，我們可以以這三個要素為基礎，重新建構等效但更簡單的方法。為了敘事方便，我接著會把我的方法集稱為 Mini-Scrum — — A minimalist’s Scrum — — 下面接著介紹與傳統 Scrum 最為不同的地方。

議程 vs. 會議

若我們調整前一節提到的三個要素，就會是定期進行：

1. Review：針對目前產出搜集回饋，確認或調整產出方向。
2. Planning：確認下次或未來會議要看到的項目。
3. Retro：針對協作搜集回饋，確認或調整協作細節。

傳統 Scrum 會為每一項召開專屬會議，Mini-Scrum 則建議每週例會即可，並依上述項目安排議程，例如：

9/11 Awesome Project Sync-Up Outline

1. (Review) @Mosky 分享專案目標與規劃。[–2:10pm]
2. (Review) 續 1，請大家給予回饋。[–2:20pm]
3. (Planning) 確認下週會看到的項目，可能需要 ＠Raymond 了解程式面現狀等等。[–2:30pm]

Mini-Scrum 的會議重心會放在 Review，在軟體開發過程中實在有太多的不確定性，需要透過不停迭代來找到符合大家想像的版本，包含了點子、計畫（目標、路線圖、時程等）、需求、圖表（流程圖、時序圖等）、規格、設計稿、原型、候選版本、報告、分析等等，不勝枚舉。

傳統 Scrum 對於 Planning 有如 Planning Poker、Impact Effort Matrix 這樣的方法，來幫助大家建立對複雜度、優先序的共識；Mini-Scrum 則建議專案負責人粗排後與需求方和開發方確認即可。自己曾經化簡了一版 Impact Effort Matrix 幫助排序，現在偶爾會用，但多數時候不太需要，也是因此發現絢麗的方法幫助真的有限。

傳統 Scrum 對於 Retro 則有更多方法，甚至有專門規劃 Retro 的工具；Mini-Scrum 則建議以 Thanks/Good/Better/Ideas 來規劃議程就相當有效，尤其是 Thanks & Good。許多方法都是為了引出 Better & Ideas，但其實比起那些鋪陳，專案負責人私下詢問比那些方法有效率百倍。Retro 我通常是四週安排一次 15–30 分鐘的議程，例如：

(Retro) 這四週釋出了⋯⋯，協作上有沒有想要感謝、覺得做得好的地方？
(Retro) 有沒有覺得可以做得更好的事、更好的方向？

連結成員 vs. Stand-Ups

傳統 Scrum 推薦每日站會（Daily Stand-Ups）以進行及時溝通；Mini-Scrum 則推薦在專案開案或人員加入時，清楚介紹成員在專案的角色與責任（Role & Resposibility），並連結成員（甚至專案外成員），明確指出可以在例會外多深入討論，幫助形成彈性的溝通管道，會比制式的每日站會有更好的溝通效果。

「Mosky 的角色是 Project Owner & Second Backend，負責照顧專案時程、幫忙系統設計覆核等，有需要可以找他討論，像是會延遲、不確定系統設計好不好時。」「Lidan 負責後端開發，⋯⋯。」「Lidan 有時程、系統設計相關問題可以找 Mosky。」我可能會這樣說。

小群討論常常比大群討論來得有效率，除了小群比較好約，小群也比較容易講到每個人都聽得懂，甚至比較容易做出高品質的決策。只要連結好專案內外成員，就可以用高效率的方式機動討論，減少對制式會議的依賴，必要時讓決策回到專案例會覆核即可。

每週里程碑

在成員清楚了解現狀與期待後，我會請成員列出填補落差所需要做的所有事情，再把事情整理進一張週時間表，形成每週里程碑（Weekly Milestones），例如：

9/25: 完成 Awesome 系統後端實作。
10/2: 完成 Awesome 系統後端－前端整合。
10/9: 送出 code review。
10/16: 釋出。

上述以後端為例，各專業各會有一張列表，簡單時我會用表格來整理，整理不來時才考慮使用專案管理軟體，以最小化維護成本。

由於是以事項為基礎，可以被其他專業夥伴覆核，無論是忘記寫完不意味著釋出（專案專業）、低估難度（軟體專業）等，都可以一眼看出來。主管關心時也可以依此解釋。

也建議專案負責人要確定自己與里程碑負責人理解一致，例如產品設計師設計了 A、B、C 部分構成 S 系統，結果不同平台工程師理解到的 A 都不一樣，都說 A 做完了，最後無法構成 S 系統就非常尷尬了。專案負責人要非常清楚專案如何被拆解，並利用設計稿等視覺化的方式確定每位工程師有相同的認知。

接著就是逐週確認有照時程表走了。

當然，通常不會照著時程表走。這就是重點了，這張時程表可以幫助專案負責人提前發現問題並進行處理，包含協調組內外資源、對外溝通等。老闆對約定釋出日爆炸與專案進度 30% 爆炸的態度會完全不一樣。

小規模調整可以劃記舊里程碑，寫上新的里程碑；大規模調整可以備份舊版，直接重寫。告一個段落後，舊的版本也能成為很棒的學習素材，幫助下次估得更精準。

專案內是照時程表，專案外溝通我會給時程表至時程表 1.5 至 2 倍時間，以上述為例就是溝通 10/16–11/13 釋出，讓自己手上有緩衝能夠幫助成員，對外溝通會逐漸縮小範圍；透過這樣的方式做好專案內、外的管理。

安排分析階段

使里程碑更準確的方式之一是安排事前研究，或稱分析階段。在這個階段我們要了解現狀（As-Is）、期待（To-Be）以及如何填補落差（Gap），就如同了解檯面上有紅茶、客人要鮮奶茶，所以要倒鮮奶一樣。

在安排釋出之每週里程碑前，可以先安排分析之每週里程碑，例如「調查系統現狀」「列出需求方期待」「列出需填補落差」等，並讓最後一個里程碑為「展開至釋出之每週里程碑」。先查清楚哪裡有坑，就比較不會意外掉進坑裡，使估計釋出時間更準確，做好對外溝通。

只要成員認為自己能估釋出之每週里程碑，我就會認為分析階段業已結束。經驗上除非成員很肯定，否則至少會留一週，至多我安排到過六週，相當於現狀、期待、落差各兩週。

※「分析階段」在學理上是「系統分析與設計（System Analysis & Design）」，現代的軟體開發不會像過去投資那麼多時間在這個階段上，但仍可從過去的理論中獲得許多啟發。

感謝鏈

我到現在都還記得第一次在 Retro 環節收到感謝時的顫動「啊，這麼努力有被注意到呢。」我認為這是 Retro 最重要的功能，讓大家有機會表達對彼此的感謝，也是能讓團隊能走得更遠的養分。

如果團隊還不習慣這件事，我的技巧是平常就會用心觀察，記起至少一個例子備用，再問對方有沒有想感謝誰，透過這樣一個接著一個的方式，幫助大家把感謝說出口。

請務必準備真心的例子，一位工程師看起來面癱，但不見得不擅長觀察，我們每個人從小都看過多少影視作品，你我不比專業演員，一但產生懷疑，那個距離感就很難消除了。

彈性例會週期

即使是專案小組這樣非固定的水平組織，也相當忌諱人員調動。因為會議有效率的前提是大家有相同的上下文，只要時常調動，補上下文會非常非常耗費時間。

「嗯，好像沒我的事了，我應該不用出席例會了。」人員想離開的原因之一就是認為時間投資不划算。在注意到有人員閒置，但還沒有把握可以解散專案團隊時，可以將週會改為雙週會或甚至月會，幫助你面對可能三週後突然的需求，或許是小調整，但也或許你就差那位關鍵的夥伴。

與主管的另一系列例會

如果主管不在專案團隊，可以考慮與主管（或利害關係人）有另一系列例會，我通常是安排月會，也依 Review、Planning、Retro 安排議程，以定期交換資訊，避免一次得講太多，造成表達與消化的額外成本。

Scrum 相關可以探討的議題實在太多了，從 2017 年闖蕩至今實在是流血流淚。這篇以與傳統 Scrum 之差異為核心，盡量勾勒 Mini-Scrum 的輪廓，其實還有很多方法細節可以討論，同樣的框架甚至也能拿來帶領功能團隊（functional team），有機會再跟大家分享。

希望你有從這篇文章獲得啟發，能夠一起用最小的成本創造最大的價值！

延伸閱讀

1. Scrum，但每週只用一小時・細節篇－Mosky：追劇就是要整季追！
2. 那些加倍會議效率的小秘訣－Mosky：如何帶好每一場專案會議？
3. 給回饋好難？你需要那條「路」－Mosky：如何引入像 Mini-Scrum 這樣的新方法？
4. 三個步驟確保 150% 的生產力－Mosky：身為專案負責人，如何讓成員更投入在專案中？
5. Mosky’s Extended-SDLC – Dropbox Paper：個人公開筆記，是我安排每週里程碑時很常參考的框架，避免漏事。
6. Mosky’s Mini-Scrum – Dropbox Paper：個人公開筆記，有精簡但完整的 Mini-Scrum 方法記載。

鳴謝

沒有人天生就會帶專案，這些方法是經過無數嘗試所摸索出來的，要特別謝謝我所任職的 Pinkoi 給了我這些嘗試的機會，尤其是包容我無效嘗試的夥伴，以及同儕之間寶貴的經驗交流，才能讓我打磨出這些有效的方法。