許多敏捷手法都奠基於 timebox。那麼，為什麼有人會認為 timebox 路線是死胡同呢？有此論點的人，偏偏又是敏捷圈的重量級人物呢。

看板方法之父 David J. Anderson 在新書 Discovering Kanban 第 15 章對於 Scrum 之類基於 timebox 的方法有頗露骨的批評（光從標題 “The Tyranny of the Ever-Decreasing Timebox” 就看得出來）。正好好友 Derek 在 〈《Discovering Kanban》心得：Scrum 可能沒有你想像的那麼美好〉一文整理了這一章的摘要與閱讀心得，在網路上也引發一些討論 ¹，我便趁此機會細讀這一章。

這一章論點非常深刻。但讀著讀著，總覺得作者道出的結論 “time-constrained sprints are an evolutionary cul-de-sac, a dead end”，與我直接或間接所知的業界實踐現況，並不相符。我猜想：會不會是某個推論環節出了些問題？

因此，我嘗試用系統思考角度去梳理相關論述。我試圖用更清晰的因果關係秀出 timebox 路線被點名的痛點，以及常見的因應之道。至於這痛點是否真的已被解決了，則留待讀者思考，不在此文的探討範圍。

前言

我很喜歡 Java 大師 Joshua Bloch 在《編程的頂尖對話》所說的：

即使是想把一個很小的程式寫對也是非常難的。

認為自己程式沒有 bug 就是在愚弄自己。程式肯定有 bug，（只是）多數情況下，程式裡的 bug 夠少，足以使其完成任務。

是的，100% 正確的程式或許很難達成，或許連定義起來都很困難，但我們還是得努力趨近它，讓我們工作更有成就感，更有信心能夠交付價值，也更少因不慎流出去的瑕疵而疲於奔命。

Joshua Bloch 緊接著又說：

既然寫正確的程式那麼困難，我們就應該盡力取得幫助。所以，能減少 bug 的所有東西都是好的。這就是我是靜態型別和靜態分析的信徒的原因。

是的，我們需要動員許多力量，取得許多幫助，才能夠趨近於正確的程式。可動員的許多力量當中，無疑的 code review 是重要的基礎，可惜的是，許多團隊連這基礎都還有諸多可改善之處，這也限縮了團隊能進一步發揮的價值。

Code review 乍看之下是小事，但若認真探討起來還真是不小。在我多年輔導各種成熟度團隊的經驗中，有六個基於 code review 以及衍生出來的議題可深入探討：

1. 基本信念：品質來自正確地做事
2. 掌握基本功與領域知識
3. 凝聚團隊公約的共識
4. 嘗試更好的協同理解技巧
5. 讓進步看得見
6. 支持長久研發的措施

如果你所在的團隊已經啟動 Scrum 或 Kanban 研發流程，恭喜你，你們已經有很好的流程基礎可在這六大議題上面精進，只需要正確實施（玩真的！）你們所採用的敏捷流程。文中我會大量連結到 Scrum 及 Kanban 的要素。請確實「守」你們該守的流程，不要驟然「破」或「離」。

全文很長，如果你是現役的程式設計師，可先讀①②以瞭解 engineering disciplines；如果你是 team lead，可先讀③④以瞭解團隊動力；如果你是管理層，可先讀⑤⑥，尤其是⑤關於管理面的施力點。

Scrum 已經夠精簡了，但很多人還是因為嫌麻煩、省時間，就省略原本預定該做的事情。

雖然在 2020 之前的 The Scrum Guide 並沒有規定 Sprint Planning 要分為 Part 1 & Part 2 ¹，但這可說是 Scrum 圈公認的最佳實踐。²

如果團隊已經成熟到能以自己的方式把 Sprint Planning 做好做滿，其實也未必非得硬性劃分 Part 1 & Part 2（畢竟 Scrum 推崇基於經驗主義的自組織、自管理）。最怕的是，不明白劃分 Part 1 & Part 2 的好處，不明白 Part 2 的重點及產出，甚至單純只因「嫌麻煩」、「省時間」，就省略原本預定該在 Part 2 進行的活動，往往會導致 sprint 進行途中出現種種問題。

很多問題，追根究柢，就是當初沒有認真進行 Part 2。

我在 2015 年～2017 年間，開了 8 次【Docker 建置實戰講堂】一日課程。在那個大眾對於 Docker 還矇矇懂懂的年代，我就堅持不用貌似較簡便的 Docker Desktop，而是大膽採用 Vagrant + VirtualBox 作為統一的授課環境，讓學員儘早習慣在 Linux 平台上探索 Docker 的底層與應用。

所以，當我在 2022 年 iThome 鐵人賽看到小賴的參賽作品【那些關於 docker 你知道與不知道的事】中，是以 AWS EC2 的 Ubuntu instance 作為實作環境，現在更出版新書《Docker 實戰 6 堂課：56 個實驗動手做，掌握 Linux 容器核心技術》，就非常高興。畢竟，從最擬真的角度切入，才能夠透過自己的雙手，掌握那不變的容器技術核心。

為了在公司內推動 GCP 認證考試，必須先推動大家勤修 GCP 課程；為了推動大家勤修 GCP 課程，我得先帶頭示範。因此，我最近在 Coursera 修了許多 GCP 認證考試相關課程 ¹，感觸很深：就算不考照，用這些課程補完一些知識，還是很值得的。

這些課程深度與廣度兼具，又有搭配實作演習，有系統地吸收，會比雜亂搜尋文件的碎片化學習來得踏實。

即使以俗氣的 C/P 值角度來說，這些課程也是物超所值的。像以下這門放在 Coursera 的課：

• Google Cloud Big Data and Machine Learning Fundamentals

大家知道嗎？這樣的課，用同樣的 Google 原廠教材，改用國語發音 live 授課，在外頭可是喊價超過一萬元新台幣的。

我根據自己這些日子勤修課程的小經驗，推薦幾門有廣度有深度的課，讓想要對雲端環境有更廣更深認識的人參考。我大致將這些課程分類如下：

• 非技術的通識類
• GCP 技術：共通核心
• GCP 技術：K8s
• Dev
• DevOps & SRE
• ML & Big Data