WIP限制並不是真的要限制你的進度，事實上正相反。
什麼是WIP限制？
在敏捷開發中，WIP限制決定了每種情況下的工作流中可以存續的最大工作量。限制進行中的工作數量可以更容易辨識團隊工作流中的無效工作。在情況變得更糟前，一個團隊在持續交付通道中的瓶頸是非常容易辨別的。
為什麼說WIP限制很重要？
所以現在你一定在想“趕快告訴我更多吧！”（好吧，我希望你是這麼想的。）
WIP限制通過強制讓團隊聚焦在更小的一套任務中來改善吞吐量和減少“將要完成”的工作量。從根本上來講，WIP限制鼓勵的是“完成”的文化。更重要的是，WIP限制可以讓阻礙和瓶頸顯而易見。當有明確指示現有工作遇到瓶頸時，團隊可以聚焦在阻塞問題上儘快的理解、實施和解決。一旦消除阻塞，團隊中的工作將再次開始流動。這些優勢可以確保在最短的時間內向使用者交付有價值的增量，從而使得WIP限制成為敏捷開發中一個非常有價值的工具。
“此外，多工處理只是看似時間安排緊密。”
開發期間，大家很容易會想“當我開始另一項工作的時候，我會暫停這項工作”。同時開啟兩個問題意味著在兩個事務之間前後切換或者在團隊成員之間轉移工作。降低一件事的投入加大另一件事的投入並不意味著自由-因為它會花費時間並且削弱焦點。解決一件原始問題總是好過開始並且未完成一項新工作。換句話說，WIP限制防止我們阻礙自己的流。
最後，WIP限制指出了長期閒置或過載的區域。它們幫助團隊看到整個流程中的低效事件而不僅僅是某些特定區域。
專家提示：
對於剛剛使用WIP限制的團隊，會覺得並不方便。只需要花點時間在最開始的幾次迭代中進行討論。瞭解團隊何時以及為何達到了WIP限制。起初，要抵制隨意調整WIP限制的誘惑。如果違規行為接連不斷，那就表明WIP的限制過於嚴格或者團隊的流程效率太低。
在敏捷團隊中使用WIP限制
現在你已經認可它們的價值了，那我們迴歸實際問題。
每當鋪開一條新的工作流時，團隊都要判斷並決定每種情況下的WIP限制。我們建議在監控幾次迭代確定每種情況下平均數量的工作項後再設定WIP限制。
- 根據需要調高WIP限制，以便團隊不再打擊它們。（例如“債務上限”，還有其他的嗎？）
- 每個人都有一個很大的專屬“後臺任務”用來隱藏他們的閒置時間。
- 團隊成員閒著等待更多的工作進入，而不是集中在瓶頸上。
- 在工程實踐或團隊流程中，投入更多的人時在持續的瓶頸上要優於過度改進。
敏捷團隊使用WIP限制的4個目標
與任何新活動一樣，WIP限制最初使用起來比較尷尬。而WIP限制的目標是在中期使團隊達到最優狀態，所以短期的尷尬實際上是好事。它會迫使團隊觸碰到他們流程中的一些痛點。
團隊在使用WIP 限制幾周後，就可以根據需要進行調整。正因為團隊一直在受挫，因此可以抵制調高WIP限制的誘惑。而且還能抓住機會，提高團隊整體能力-理論上，可以通過教育團隊讓每個成員獲得新技能或在某些方面提高開發過程的效率。
目標1：不斷調整單個任務的大小。
在分解需求和使用者故事時，保證單個任務的工作量不超過16個小時是非常重要的。這麼不僅可以提高團隊確切預估的能力，還能有避免瓶頸。沒有什麼能比大工作項阻塞通道更能降低團隊速度加劇WIP限制了。
專家提示：
當WIP限制有效時，一個事件的迴圈時間就會降低。迴圈時間就是完成一個事件需要的時間。
目標2：將WIP限制規劃為團隊的技能。
上面的例子是假設團隊成員的技術能力相似。如果你的團隊有技術專家，那麼當專家牽涉其中時WIP限制應該有所不同。這個時候需要建立特定於專家工作的狀態。如果在該狀態下出現瓶頸，正好可以趁機讓團隊其他成員學習一些額外的專傢俱備的技能，以此來增強整個團隊的流。
目標3：減少閒置。
當一個團隊成員出現停工期的時候，鼓勵他們去幫助上游或下游團隊成員。他們不僅能為團隊的整體生產力做出貢獻，還可以在此過程中學到一些東西。
目標4：保護一種可持續的工程文化。
WIP限制並不意味著開發人員需要急於工作以避免某些情況下工作過載。它旨在保護以保證產品質量和程式碼庫健康為前提的紮實的敏捷工作實踐。
原文作者：Dan Radigan
翻譯：吳倩倩
文章來源：Worktile技術部落格
歡迎訪問交流更多關於技術及協作的問題。
文章轉載請註明出處。