《Discovering Kanban》心得：Scrum 可能沒有你想像的那麼美好
看板起源於 2004 年， David J. Anderson 協助微軟的 XIT 維運團隊開始，陸續總結出看板方法，在 2010 年出版《Kanban: Successful Evolutionary Change for Your Technology Business》。經過 20 多年，看板方法陸續加入更多的想法與實踐，在眾人的催促下，終於在 2023 年再版《Discovering Kanban: The Evolutionary Path to Enterprise Agility》。
這本書比較不像是看板工具書，直接教你看板是什麼，要怎麼建立團隊看板。更多的是使用看板的心法，透過 David J. Anderson 描述一個又一個的故事，從 XIT 團隊、Corbis 公司、Posit Science 公司。帶著讀者回到那個時間點，一起觀察團隊遇到什麼問題，當事人是怎麼思考的，最後是怎麼改善的，幫助我們理解看板如何做到漸進式的改變。
書本的內容非常多，我只挑了「最具爭議」的第 15 章，在這篇讀書心得中做分享。在敏捷方法中，大家已經很習慣 Sprint 這種 timebox 的限制方式，把規劃活動、開發活動、發布活動都完美的對齊。但是，大家有想過這樣的開發方式真得是最好的嗎？我們來聽聽看 David J. Anderson 怎麼說。
小批量（Small Batch）帶來的好處
軟體品質通常跟「批量大小」和「所需要的完成時間長短」相關，通常批量越大或是所需要的完成時間越長，缺陷率（defect rate）會呈現快速的成長。所以，理論上來說小批量的工作方式是我們所追求的。
有兩種方式可以限制小批量：Timebox 和 WIP Limit
我們都知道小批量有眾多的好處，在實務上有兩種可行的做法：一種是 timebox，另一種是 WIP Limit。作者認為在一個人數不多或是低成熟度的組織中，採用哪一種方法其實無所謂，兩種方法都是有效的。
然而，當組織人數開始成長時，開始需要管理風險、管理相依性、跨團隊的協作。如果還是採用 timxbox，是無法順利在組織中做擴展的。
短 Timebox 在實務上會遇到的挑戰
從客戶的角度來看，小批量可以更快的交付價值給客戶，所以會傾向使用更短的 timebox，從四週變成二週，甚至變成一週或是每天，這會讓團隊處於高度的壓力之下。
作者整理出三個「極短 Timebox」 中帶來的挑戰：
第一：短 Timebox 需要將需求切割成數個顆粒度更小的 Story，讓每一個 Story 都可以在有限的時間內完成，這會導致團隊需要做更細部的討論與開發。
第二：因為 Timebox 很短，需要把需求拆分成更小的 Story，才能讓每個 Story 可以剛好地放進一個 Sprint 中。因此，在事前需要高準確度的估算，來避免 Story 在進入開發後，無法在 Sprint 結束前完成。
第三：假如一部分的 Story 存在相依性，這些相依性可能會出現在跨團隊、跨多個 Sprint Backlog 、或是跨多個 Sprint 中做追蹤和管理。
關於需求分析…
越短的 Timxbox 會需要工程師有更好的需求分析技術，將需求切割成數個 Story，並且讓每個 Story 完美的放進一個 Sprint 中。即使經過這麼多年，各專家提出各種故事切割的技巧，還是很難找到一個公認的準則，把這件事情做得很棒。
即使我們真得有個完美的方法可以將需求拆解成 Story，那意味著我們必須在 Sprint Planning 前投資足夠多的時間將需求做拆分。另外，當產生多個 Story 以後，如果 Story 之間是有相依性的，等於我們要採用額外的管理技巧，把這些 Story 關聯在一起，這些事情等於幫自己製造了更多的麻煩。
Scrum 的運作方式必須建立在一個「很理想」的環境中，但是很多現實的狀況並非如此。有時候需求經由垂直切分（vertical slicing）後，還是很難放進一個 Sprint 中。接著，團隊可能採用水平切分（horizontal slicing），你可能會聽到 architecture story、design story、development story、test story，這些都是根據功能切分後的結果。
如果我們以價值交付的角度來看，這些過度拆分的 Story，它其實沒有符合 INVEST 原則，獨立完成時是無法交付價值給客戶的。只是讓團隊有個錯覺，我們每個 Sprint 都有完成一些東西。
關於估算…
越短的 timebox，為了讓 Story 可以在 Sprint 結束時完成，我們就需要更精準的估算來確保切割後的 Story 可以剛好放進一個 Sprint 中。
關於相依性…
想像一下，正在進行的 Story 發生了阻塞 (blocked)，因為與其他的團隊有相依性。越短的 Timebox，團隊就愈需要在 Sprint 開始前做更多縝密的規劃，避免發生相依性。
為了解決相依性的問題，大部分的敏捷方法是組成多功能的團隊 (cross-functional team)，團隊成員因為是多技能 (multiple skills)，我們期待團隊可以完成端到端的交付。當有相依問題時，這個問題就會局限在團隊內，不會產生過多與外部團隊的相依性問題。
作者認為這種想法不切實際，在一個比較小規模的組織裡，或許可以這麼做。但是當組織變大的時候，你會需要有專家來讓你的組織變得跟其他人不一樣，讓每一個人都變得一樣不會讓你的組織變得更成功。當組織內出現專家的時候，自然就會產生外部的依賴性。
我們以一個典型的 Web Application 為例子，通常團隊內會有前端工程師、後端工程師和測試人員。如果這個服務牽涉到安全和法律問題，難道我們要把安全工程師和律師納入團隊嗎？
所以我認為多功能團隊的用意良善，但也不是無限的擴張。在一個大型的組織裡，自然會需要面對跨團隊的相依性問題。最直接的一個問題就是，當你有一群開發工程師和維運工程師，到底是要組成一個 DevOps 團隊，還是 Dev 一個團隊，Ops 一個團隊，只要確保他們能夠很順暢的合作即可？
從 Timebox 的暴政中解放吧
作者在書中提到要做的兩個改變。
第一個改變，避免詢問需求是否可以放進 Sprint 中。每個需求其實都有「自然的顆粒度」，不需要刻意將需求拆分的更小。通常這些新需求，我們都曾經做過。所以可以根據過去的歷史數據，推估可能需要的完成時間。
第二個改變，避免討論需求是否因為相依性而發生延遲。過短的 timebox 造成團隊需要提早分析需求來辨識相依性，這其實是不必要的。重點是建立服務為導向的看板 (Service-Oreiented Kanban)，透過看板鼓勵多團隊的合作。
關於第一點我做點補充。在一個成熟的團隊，「自然顆粒度」的概念我是認同的，過度的拆分需求並不會帶來更多的價值交付。但是在輔導團隊時，通常是需求沒有經過適度的切分，經常需要數個月才能完成一個需求。這會造成缺乏細部的討論，在開發的過程中，會讓團隊缺乏前進的感覺。
關於第二點我也做點補充。以服務交付的角度來看，讓多團隊的需求用一個共同的看板做追蹤與管理。當其中一個需求發生阻塞有了相依性，透過視覺化的技巧，強調出這些有相依性的工作。讓相關的團隊一起面對，一起做解決這個相依性的問題。
後記：Kanban 提供另一種選擇
Scrum 描述的世界很美好，在一個理想的環境中，盡可能的遵守 Scrum 方法可以帶來很大的好處。但是現實是殘酷的，如果你的環境不是那麼完美，該怎麼辦呢？
在實踐 Scrum 的過程中，經常會遇到幾個常見的問題。需求拆分成 Story 後，這些 Story 還是沒辦法放進一個 Sprint 中；估算經常不準確，無法正確預估每個 Sprint 應該安排多少工作量；Sprint 結束後，有一半的工作必須遞延到下個 Sprint；版本發佈無法在 Sprint 結束時發生。
當我們帶著這些問題去請教熟悉 Scrum 的敏捷教練，這些教練都會認為團隊成員的紀律不夠，沒有好好的遵守 Scrum 方法。想像一下，公司花了大筆的金錢僱用優質的工程師，卻歸罪於他們不遵守紀律，怎麼聽起來怪怪的。
如果你遇到諸多 Scrum 的問題，或許 Kanban 提供你另一種選擇。Kanban 強調的是「Start with what you do now」，從團隊現在怎麼做就怎麼做，我們不做太多的改變，只是將工作流程視覺化。經常的檢視看板和數據，用科學化的方式做漸進式的改善。
David J. Anderson 這本書目前只有英文版，推薦給想要理解看板方法演變的朋友。
如果對於看板認證課程有興趣的朋友，也可以找 Kanban University 的認證講師「柳丁老師」。
如果你喜歡我的文章，歡迎「拍手」給我支持，或是「Follow」我，讓我提供更多的優質文章給你。
