利特爾法則(Little’s Law)作為一個非常樸素的原理,為看板方法奠定了一個理論基礎(chǔ),看似簡單的公式背后卻有其復(fù)雜的一面。
利特爾法則的公式是這樣的:
平均吞吐率=在制品數(shù)量/平均前置時(shí)間
舉個例子,假設(shè)你正在排隊(duì)買快餐,在你前面有19個人在排隊(duì),你是第20個,已知收銀窗口每分鐘能處理一個人的點(diǎn)餐需求,求解你的等待時(shí)間。
如果你已經(jīng)決定要排隊(duì),并且站到了隊(duì)尾,那么在制品數(shù)量就是20(個),平均吞吐率是1(人/分鐘)。
從你站到隊(duì)尾的時(shí)候開始,一直到你點(diǎn)完餐,這個時(shí)間就是你的“前置時(shí)間”。
即使我們沒有學(xué)習(xí)過利特爾法則,也可以輕易地算出來:
1 = 20 / x x = 20(分鐘)
因?yàn)樵谝欢螘r(shí)間之內(nèi),保持工作量飽滿的話,我們每天能做多少工作基本是一定的,所以吞吐率基本上不會發(fā)生太大變化。
如果這個時(shí)候我們想縮短平均前置時(shí)間,也就是等待的時(shí)間,利特爾法則告訴我們:可以通過減少在制品數(shù)量來達(dá)成這個目標(biāo)。
在這個例子中,就是減少排隊(duì)者的數(shù)量。
這也很好理解,10個人的隊(duì)列和20個人的隊(duì)列,前者需要等待的時(shí)間會更短。 [1]
如上面所說,在制品數(shù)量和前置時(shí)間是成正比的,縮短前置時(shí)間的最有效手段就是減少在制品數(shù)量。
前置時(shí)間的增長會導(dǎo)致交付周期變長,這一點(diǎn)基本毋庸置疑。
前置時(shí)間的增長會導(dǎo)致交付的可預(yù)測性下降,俗話說“夜長夢多”,長時(shí)間停留在某一個階段會帶來一些額外的風(fēng)險(xiǎn)。
如果我們的交付周期比需求變化周期更長,那么會有更多的緊急任務(wù),所以交付周期變長會導(dǎo)致更多的緊急任務(wù)。
如果我們管理不好緊急任務(wù)的插入,會增大我們的在制品數(shù)量。
如果交付團(tuán)隊(duì)的可預(yù)測性很低的話,那么會影響到IT研發(fā)組織和業(yè)務(wù)部門的信任關(guān)系,當(dāng)業(yè)務(wù)部門無法預(yù)測一個需求提交給研發(fā)部門什么時(shí)候能交付的時(shí)候,那么唯一可行的手段就是一次性把要做的事情全部都壓給研發(fā)部門,直接增大了研發(fā)部門的在制品數(shù)量。
同時(shí)在制品數(shù)量的增長會帶來的另外一個后果就是故障發(fā)現(xiàn)得很晚,這一點(diǎn)在過去三四十年的軟件工程方法論中都得到了驗(yàn)證。
發(fā)現(xiàn)的故障需要資源和時(shí)間來進(jìn)行修復(fù),帶來的就是在制品數(shù)量的上升和前置時(shí)間的增長。
以上所有的事情我們放到同一張圖中,可以看到下面的情況,實(shí)線表示兩者之間存在因果關(guān)系,同時(shí)還是正比的,因增大,果也會增大。虛線表示兩者之間存在的因果關(guān)系是反比的,因增大,果會減小。
因果回路圖
而在這眾多因素之中,只有在制品數(shù)量是我們能夠最有效的直接加以干預(yù)的。
而只有前置時(shí)間我們是可以直接觀測的。
就像我們正在開車一樣,我們踩油門的時(shí)候,速度表會發(fā)生變化,從60邁到100邁,但我們真正關(guān)心的并不是儀表盤的變化,而是真正汽車行駛的速度。
所以我們采用控制在制品數(shù)量的手段,通過觀測前置時(shí)間的變化來觀察我們的改進(jìn)是否有效,但更重要的是整個系統(tǒng)是否正在向著更好的方向邁進(jìn)。
我們用直覺感受一下,在制品數(shù)量如果越低越好,那限制到1怎么樣?限制到0怎么樣呢?
很顯然,在制品數(shù)量如果過低的話,團(tuán)隊(duì)成員可能會產(chǎn)生空閑的現(xiàn)象,很大一部分產(chǎn)能會被浪費(fèi)掉,那在制品數(shù)量限制到多少是最合適的呢?
我們都知道,一個任務(wù)如果2周能完成,兩件任務(wù)串行,需要的時(shí)間是4周,但兩件任務(wù)并行,絕不是2周能完成,有可能5周的時(shí)間都完成不了,所以直覺上在制品數(shù)量過高也不能帶來產(chǎn)能的上升。
所以一個樸素的原則就是:團(tuán)隊(duì)中每個人在任意時(shí)刻,手中只有一件事的時(shí)候,效率是最高的。團(tuán)隊(duì)的在制品數(shù)量低于這個值,會造成產(chǎn)能的浪費(fèi),如果高于這個值,會造成前置時(shí)間的變長。
那我們再用定量的方式模擬一下吧。
假設(shè)我們有一個三階段的開發(fā)流程:分析、開發(fā)、測試,平均每張卡片需要4天時(shí)間分析、5天時(shí)間開發(fā)、6天時(shí)間測試。
為了簡化計(jì)算,我們把分析、開發(fā)、測試三個階段設(shè)一個總的在制品數(shù)量限制。 [2]
模擬看板
當(dāng)我們有1個分析人員、1個開發(fā)人員、1個測試人員的時(shí)候,會得到下面這個結(jié)果:
WIP平均前置時(shí)間平均產(chǎn)能1150.072150.133180.164240.165290.166350.167410.168470.169520.1610580.16
折線圖這個實(shí)驗(yàn)可以重復(fù),有興趣的同學(xué)可以自己寫代碼重復(fù)一下。
[1]: 道理看似很簡單,但放在軟件研發(fā)領(lǐng)域就變得非常復(fù)雜,我們需要平衡需求和產(chǎn)能之間的關(guān)系,控制隊(duì)列長度實(shí)際上就是在控制期望和承諾。在尊重事實(shí)的前提下,我們盡量讓隊(duì)列的長度變短,不去承諾不切實(shí)際的東西。
[2]: 所謂“排隊(duì)”,實(shí)際上軟件開發(fā)真正的“收銀窗口”就是最終交付的環(huán)節(jié),在這個環(huán)節(jié)之前的所有需求其實(shí)都是一個隊(duì)列,隊(duì)列的末尾就是我們最近承諾的一個需求。所以一旦我們承諾了無法立刻著手的需求,那么就會產(chǎn)生極大的浪費(fèi)。
聯(lián)系客服