Post

Little’s Law 是什麼?

在看 A User Story Primer 的時候,裡面有提到的「Little’s Law」

出於好奇沒看過這個東東,就查了一下便記錄一下唄

Little’s Law 是什麼?為什麼你該在意它?

讓我們從一個現實又殘酷的例子開始說起:

公司倒閉,因為客戶不爽,客戶不爽,是因為交付太慢(Lead Time 太長)

→ 白話文就是:你隨便答應客戶一個功能,結果老是拖很久才交件,客戶當然會不爽!

這其實正是 Little’s Law 想告訴我們的事

當我們交付太慢,不只會讓客戶不滿、流失,甚至會讓整間公司陷入危機

而 Little’s Law 提供了一個簡單但強大的方法,幫我們解釋:

為什麼交付慢?我們要怎麼讓交付變快?

Little’s Law 的公式

1
WIP = Throughput × Cycle Time
  • WIP(Work In Progress):正在進行中的工作數量
  • Throughput(吞吐量):單位時間內完成的工作數量
  • Cycle Time(週期時間):一項工作從開始到完成所花的平均時間

這個公式也可以重組為:

1
Cycle Time = WIP ÷ Throughput

換句話說,如果你想要縮短交付時間(Lead Time / Cycle Time),你有兩條路可以選擇:

  1. 提高 Throughput:增強實力、加快完成速度
  2. 限縮 WIP:一次不要做太多事,專注把手上工作做好

User Story 要夠小,才能流動得快

我們都知道:「小批量比大批量更容易流動」,這不只是在製造業適用,在軟體開發也一樣

如果我們的 User Story 太大,可能會:

  • 一次迭代做不完 → 拖到下個 Sprint 才交付
  • 無法快速 Release → 無法即時產生價值
  • 無法估準 → 團隊常常誤判工作量

因此,我們應該讓每一張 Task、每一件工作都「小到能在短時間內完成」,這樣不但更快交付,也更容易調整優先順序

這背後的原理,正是 Little’s Law:

如果你想讓交付時間(Cycle Time)變短,除了提升速度(Throughput),也可以試著減少同時進行的工作數量(WIP)

系統超載時,就像高峰時段的高速公路

當我們的系統工作量太大,就會像「高峰時段的高速公路」一樣,開始塞車、效率變差

想像一下:

  • 摩托車能快速穿梭(就像小 Task),但汽車和卡車(像大型 Task)在高峰時段就會動彈不得
  • 當系統使用率超過 80%,大型 Task 不只跑得慢,它們造成的延遲會比小 Task 大得多
  • 更糟的是週期時間會忽快忽慢,完全無法預測

這就像你原本跟客戶說「這週可以交付」,但系統突然一塞,你根本不知道到底什麼時候做得完

這種情況會導致:

  • 團隊失去信譽
  • 承諾常常跳票
  • 計劃變得不可靠

所以我們才強調:不要讓團隊滿載(最好控制在 80% 以下),也不要一次做太多 Task

小工作 ≠ 小價值,反而更容易落地

你可能會想:「我們做的功能這麼複雜,不可能拆這麼小吧?」

但其實把 Story 拆小 不代表就沒有價值,反而會:

  • 降低複雜性 → 比較容易估準時間
  • 快速驗證方向 → 可以早點調整,不會做白工
  • 更容易釋出 → 提高團隊成就感與信心

這與我們在撰寫 Clean Code 時所接受的建議相呼應,正如 Robert Martin在他 2009 年提出的軟體函式撰寫原則中所說的那樣

  1. 只做一件事
  2. 保持規模小
  3. 讓它更小一點

這看起來簡單,做起來不容易

但越是有經驗的團隊,越懂得用這樣的原則,去讓自己持續地穩定交付

結語:越小、越快、越準、越穩

所以,Little’s Law 不只是「數學公式」,它其實告訴我們一個很實用的道理:

「不要什麼都一起做,也不要什麼都做到一半」
把工作變小、做完它,再做下一件

這麼做,你會發現:

  • 團隊效率變高了
  • 估時準度提高了
  • 客戶也更滿意了

參考資料

This post is licensed under CC BY 4.0 by the author.