**:
在製品與前置時間基本為線性關係,減少在製品數量就能減少前置時間。
利特爾法則(little』s law)作為乙個非常樸素的原理,為看板方法奠定了乙個理論基礎,看似簡單的公式背後卻有其複雜的一面。
利特爾法則的公式是這樣的:
平均吞吐率=在製品數量/平均前置時間
舉個例子,假設你正在排隊買快餐,在你前面有19個人在排隊,你是第20個,已知收銀視窗每分鐘能處理乙個人的點餐需求,求解你的等待時間。
如果你已經決定要排隊,並且站到了隊尾,那麼在製品數量就是20(個),平均吞吐率是1(人/分鐘)。
從你站到隊尾的時候開始,一直到你點完餐,這個時間就是你的「前置時間」。
即使我們沒有學習過利特爾法則,也可以輕易地算出來:
1 = 20 / x
x = 20(分鐘)
因為在一段時間之內,保持工作量飽滿的話,我們每天能做多少工作基本是一定的,所以吞吐率基本上不會發生太大變化。
如果這個時候我們想縮短平均前置時間,也就是等待的時間,利特爾法則告訴我們:可以通過減少在製品數量來達成這個目標。
在這個例子中,就是減少排隊者的數量。
這也很好理解,10個人的佇列和20個人的佇列,前者需要等待的時間會更短。 [1]
如上面所說,在製品數量和前置時間是成正比的,縮短前置時間的最有效手段就是減少在製品數量。
前置時間的增長會導致交付週期變長,這一點基本毋庸置疑。
前置時間的增長會導致交付的可**性下降,俗話說「夜長夢多」,長時間停留在某乙個階段會帶來一些額外的風險。
如果我們的交付週期比需求變化週期更長,那麼會有更多的緊急任務,所以交付週期變長會導致更多的緊急任務。
如果我們管理不好緊急任務的插入,會增大我們的在製品數量。
如果交付團隊的可**性很低的話,那麼會影響到it研發組織和業務部門的信任關係,當業務部門無法**乙個需求提交給研發部門什麼時候能交付的時候,那麼唯一可行的手段就是一次性把要做的事情全部都壓給研發部門,直接增大了研發部門的在製品數量。
同時在製品數量的增長會帶來的另外乙個後果就是故障發現得很晚,這一點在過去三四十年的軟體工程方**中都得到了驗證。
發現的故障需要資源和時間來進行修復,帶來的就是在製品數量的上公升和前置時間的增長。
05 看板方法 在製品
00.我們將剖析在製品 work in process,wip 的概念。含義 進行中的工作 流程中的工作。01.在製品是指你手頭正在處理的所有事情,包括正在處理的任務 等著被驗證或者部署工作項 還有那些雖然還沒開始處理,單已經等在你的收件箱裡的事情。也就是,所有那些需要完結,才能交付最終客戶價值的半...
05 看板方法 在製品
00.我們將剖析在製品 work in process,wip 的概念。含義 進行中的工作 流程中的工作。01.在製品是指你手頭正在處理的所有事情,包括正在處理的任務 等著被驗證或者部署工作項 還有那些雖然還沒開始處理,單已經等在你的收件箱裡的事情。也就是,所有那些需要完結,才能交付最終客戶價值的半...
06 看板實踐 限制在製品
00.找乙個合適的在製品限制不僅僅取決於上下文,而且依賴於你想要達到的目標,並且是乙個移動的目標。01.實際情況的確如此 所在組織持續改進的動力有多大 團隊的規模以及團隊可投入工作的時間 正在處理的工作項的型別和規模 更低比更高好 人員閒置或者工作閒置 沒有限制是不對的 02.通常更低的在製品限制比...