面對敏捷或 DevOps 藥方，病人可能帶著各種不同的動機而來，但終歸都會提出同樣的疑問：我怎麼知道敏捷有沒有效？怎麼衡量成效？

這問題，可能在導入之後的某個時刻會問，但更有可能像戰國時代梁惠王那樣，才剛第一次接見孟子，居然劈頭就問：「叟，不遠千里而來，亦將有以利吾國乎？」

對這議題，常有兩種極端的反應。

很多人認為，在變動較少的舊時代 ¹，一次到位的工作規劃、工作分解是必備技能，但是到了現在這個變動頻仍、朝令夕改、隕石滿天飛的時代，做再多工作分解的規劃只是不切實際的浪費。

你怎麼看？

我反而認為，正是因為變動頻仍，就更需要及早進行工作分解。只不過這種工作分解，不是舊時代那種一次到位的無差別分解，而是要能夠區分近光燈與遠光燈的不同層次，也就是敏捷陣營所講究的 “granularity gradient"。

這個論點，我曾在去年的兩場導讀會，透過兩本書，作為公司內推動敏捷轉型的心態導正。² 最近我發現，這類誤解仍然普遍存在於敏捷轉型的業界，因此特地將去年那兩場導讀會的觀點稍作整理，誌於此文。

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 路線被點名的痛點，以及常見的因應之道。至於這痛點是否真的已被解決了，則留待讀者思考，不在此文的探討範圍。