If you’re new to leading Scrum events, knowing what to do can be tough. Having a set agenda can make things easier for you and your team. It helps everyone know what to expect.

I’ve got my own agendas that work for me, but it’s a good idea to get different takes. Why not ask ChatGPT to suggest some? The examples you’ll see here came from ChatGPT 4 and were adapted by me. Use them as a guide and tweak them to fit what your team needs.

讀別人的程式是一件苦差事，不僅需要具備對應的領域知識，也得了解對方的程式書寫邏輯與風格。因此，為了讓程式碼容易被人理解，整潔程式碼是必須持續精進的技藝。

在 code review 進行實質審查之前，我喜歡先做一點點形式審查，尤其是某些 code smell，臭味暴風半徑大到甚至連領域知識的外行人都聞得到。

我很常遇到不必要的巢狀迴圈或條件判斷式。經驗告訴我，除非真的是要設計出什麼高大尚的演算法或者刷題，否則，這有相當大的機率是需要進一步 refactor 的。

像以下這段程式，即使我故意把領域知識相關細節用 conditionXX 馬賽克掉了，你還是可以明顯聞到 bad smell：迴圈 + 條件判斷式，ABCDEF 深達 6 層，你能夠很快捕捉到箇中邏輯嗎？

許多敏捷手法都奠基於 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。