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),你有兩條路可以選擇:
- 提高 Throughput:增強實力、加快完成速度
- 限縮 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 年提出的軟體函式撰寫原則中所說的那樣
- 只做一件事
- 保持規模小
- 讓它更小一點
這看起來簡單,做起來不容易
但越是有經驗的團隊,越懂得用這樣的原則,去讓自己持續地穩定交付
結語:越小、越快、越準、越穩
所以,Little’s Law 不只是「數學公式」,它其實告訴我們一個很實用的道理:
「不要什麼都一起做,也不要什麼都做到一半」
把工作變小、做完它,再做下一件
這麼做,你會發現:
- 團隊效率變高了
- 估時準度提高了
- 客戶也更滿意了