本文作者：Mosky Liu （擁有多年軟體開發和團隊管理經驗，目前在 Pinkoi 擔任 Architect 一職，也有在撰寫個人 Medium）
傳統 Scrum 所需要的會議時間一直為人詬病，要怎麼保留 Scrum 的優點又不用花那麼多時間呢？在歷經嘗試後，我發展出了一套保留優點又不花那麼多時間的方法。
經典的 Scrum 是每兩週一個循環，包含 Planning、Review、Retrospective、Stand-Up 等會議，會議時間平均每週就要 2–4 小時，還不含負責人準備會議需要付出的額外時間。我的版本則是一週 0.5–1 小時，是 2–8 倍的效率差異。
我已經在無數個專案中驗證了這套方法，很多專案每週例會還遠低於一小時，同時維持著高度的向心力。想把思路分享給你，期待你也能從中得到啟發，一起用最小的成本創造最大的價值。
重新提取 Scrum 中有效的要素
軟體開發包含了許多不穩定的因素，例如修改一段程式碼看起來簡單做起來難，軟體工程師經常也是開工了才發現坑比預期多。不過也是 Scrum 擅長面對的情境，因為 Scrum 不做一次性的計畫，而是根據情況定期調整，這是讓 Scrum 有效的要素之一。
只要能夠維持計畫與覆核（Planning & Review）的節奏，也就是每次計畫的事情，下次都有完成，就能夠確認團隊的速度；甚至若能夠再確認總事項收斂，就可以預測完工時間。這是讓 Scrum 有效的要素之二。
讓 Scrum 有效的要素之三是回顧（Retrospective），在 Retro 中我們分享對於協作的 Thanks & Good，這可以在無形之中拉近成員的距離，形成團隊感；我們也在 Retro 中分享 Better & Ideas，讓協作問題有機會被說出來，進而能夠被解決。
找到了這三個要素後，我們可以以這三個要素為基礎，重新建構等效但更簡單的方法。為了敘事方便，我接著會把我的方法集稱為 Mini-Scrum — — A minimalist’s Scrum — — 下面接著介紹與傳統 Scrum 最為不同的地方。
議程 vs. 會議
若我們調整前一節提到的三個要素，就會是定期進行：
- Review：針對目前產出搜集回饋，確認或調整產出方向。
- Planning：確認下次或未來會議要看到的項目。
- 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: 釋出。
上述以後端為例，各專業各會有一張表，簡單時我會用表格來整理，整理不來時才考慮專案管理軟體，以降低維護成本。
由於是以事項為基礎，可以被其他專業夥伴覆核，無論是忘記寫完不意味著釋出（專案專業）、低估難度（軟體專業）等，都可以一眼看出來。主管關心時也可以依此解釋。
接著就是逐週確認有照時程表走了。
當然，通常不會照著時程表走。這就是重點了，這張時程表可以幫助專案負責人提前發現問題並進行處理，包含協調組內外資源、對外溝通等。老闆對於約定釋出日爆炸與專案進度 30% 爆炸的態度會完全不一樣。問題解決了再估一版時程表即可，告一個段落後，最早的時程表也能成為學習的素材，幫助下次估得更好。
專案內是照時程表，專案外溝通我會給時程表至時程表 1.5 至 2 倍時間，以上述為例就是溝通 10/16–11/13 釋出，讓自己手上有緩衝能夠幫助成員，對外溝通會逐漸縮小範圍；透過這樣的方式做好專案內、外的管理。
安排分析階段
使釋出之每週里程碑更準確的方式之一是安排事前研究，或稱分析階段。在這個階段我們要了解現狀（As-Is）、期待（To-Be）以及如何填補落差（Gap），就如同了解檯面上有紅茶、客人要鮮奶茶，所以要倒鮮奶一樣。
在安排釋出之每週里程碑前，可以先安排分析之每週里程碑，例如「調查系統現狀」「列出需求方期待」「列出需填補落差」等，並讓最後一個里程碑為「展開至釋出之每週里程碑」。先查清楚哪裡有坑，就比較不會意外掉進坑裡，使估計釋出時間更準確，做好對外溝通。
只要成員認為自己能估釋出之每週里程碑，我就會認為分析階段業已結束。經驗上除非成員很肯定，否則至少會留一週，至多我安排到過六週，相當於現狀、期待、落差各兩週。
「分析階段」在學理上是「系統分析與設計（System Analysis & Design）」，現代的軟體開發不會像過去投資那麼多時間在這個階段上，但仍可從過去的理論中獲得許多啟發。
感謝鏈
我到現在都還記得第一次在 Retro 環節收到感謝時的顫動「啊，這麼努力有被注意到呢。」我認為這是 Retro 最重要的功能，讓大家有機會表達對彼此的感謝，也是能讓團隊能走得更遠的養分。
如果團隊還不習慣這件事，我的技巧是平常就會用心觀察，記起至少一個例子備用，再問對方有沒有想感謝誰，透過這樣一個接著一個的方式，幫助大家把感謝說出口。
請務必準備真心的例子，一位工程師看起來面癱，但不見得不擅長觀察，我們每個人從小都看過多少影視作品，你我不比專業演員，一但產生懷疑，那個距離感就很難消除了。
延伸閱讀：《如何舉辦 retro meeting ?》
彈性例會週期
即使是專案小組這樣非固定的水平組織，也相當忌諱人員調動。因為會議有效率的前提是大家有相同的上下文，只要時常調動，補上下文會非常非常耗費時間。
「嗯，好像沒我的事了，我應該不用出席例會了。」人員想離開的原因之一就是認為時間投資不划算。在注意到有人員閒置，但還沒有把握可以解散專案團隊時，可以將週會改為雙週會或甚至月會，幫助你面對可能三週後突然的需求，或許是小調整，但也或許你就差那位關鍵的夥伴。
與主管的另一系列例會
如果主管不在專案團隊，可以考慮與主管（或利害關係人）有另一系列例會，我通常是安排月會，也依 Review、Planning、Retro 安排議程，以定期交換資訊，避免一次得講太多，造成表達與消化的額外成本。
延伸學習：《菜鳥 PM 首戰：教你搞定利害關係人管理》
Scrum 相關可以探討的議題實在太多了，從 2017 年闖蕩至今實在是流血流淚。這篇以與傳統 Scrum 之差異為核心，盡量勾勒 Mini-Scrum 的輪廓，其實還有很多方法細節可以討論，同樣的框架甚至也能拿來帶領功能團隊，有機會再跟大家分享。
希望你有從這篇文章獲得啟發，能夠一起用最小的成本創造最大的價值！
原文連結：《Scrum，但每週只用一小時》
