Scrum,但每週只用一小時

Mosky Liu
9 min readSep 11, 2021

--

傳統 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 給了我這些嘗試的機會,尤其是包容我無效嘗試的夥伴,以及同儕之間寶貴的經驗交流,才能讓我打磨出這些有效的方法。

--

--

Mosky Liu

認真寫長文很快樂ㄛ ৻( •̀ ᗜ •́ ৻)