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 不只是「數學公式」，它其實告訴我們一個很實用的道理：
「不要什麼都一起做，也不要什麼都做到一半」
把工作變小、做完它，再做下一件
這麼做，你會發現：
- 團隊效率變高了
- 估時準度提高了
- 客戶也更滿意了