1. 程式人生 > >【敏捷開發每日一貼】看板原理一:裡特定律

【敏捷開發每日一貼】看板原理一:裡特定律

看板原理一:裡特定律

裡特定律(Little's Law)源自排隊理論,是IT系統性能建模中最廣為人知的定律。

裡特定律揭示了前置時間Lead Time)、在製品數量Work In Progress,WIP)和吞吐率Throughput)之間的關係。

前置時間 - Lead time:只請求進入到系統 與 請求驗收完成之間的時間段。前置時間按照所經過的時間(分鐘、小時等)來度量。一個請求可以是一個需求、一個使用者故事、一個異常、物料、一個來自使用者的請求等。

在製品數量 - Work inprogress (WIP):正在被處理的請求(工作單元)數量,正在被處理指這些請求已經進入到系統中,但是還沒有產出。

吞吐率 - Throughput:在一確定時間內離開系統的工作單元數量,例如3個使用者故事/天、10個任務/迭代。

看板方法實際上是一種提升研發吞吐量的方法!

WIP越大,前置時間越長,即要完成已經開始的工作需要更長的時間。換言之,為了滿足開發或服務的截止時間,我們必須減少在製品數量,或者在開始新工作之前完成在製品。

然而,在很多情況中發生了恰好相反的情況:為使整個專案可以“跑”得更快,團隊開始處理更多工。希望保持大量進行中工作的另一個原因是:以此來達到高資源利用率。

無論什麼原因,假設吞吐率不發生變化,在製品的增加會使完成在製品所需的時間(即前置時間)同時增加。

裡特定律對專案經理的作用

裡特定律是瞭解軟體開發團隊或軟體運營團隊真實效能的工具。

提供可預測性舉個簡單的例子,如果我們必須實現50個需求,團隊的平均能力是5個需求/周,我們所需的時間是:
50 個需求 / 5 個需求每週 = 10 周。揭示了工作批量越大,處理時間(前置時間)越長。

解釋了為什麼多工導致延期而非加速工作完成。通常人們相信,並行開展多個任務能夠提升生產力。因此,許多公司中共同的做法是將多個任務分配給一個人。然而,與機器不同的是,人類並不善於以並行處理的方式執行。增加在製品還會增加某項任務修改和返工的時間,從而降低吞吐率。最終,工作執行所需的時間不夠了,並且已經開始但還未結束的工作開始堆積。簡言之,裡特定律有利於找到在製品與前置時間之間的平衡。

為達到最佳WIP限制提供了基礎。

如果WIP限制低於最佳水平,就會有未充分利用的資源並且效能低下。如果WIP限制超出了最佳水平,工作單元就開始在佇列中堆積並同樣是效能降低。

有助於理解阻塞一項工作或必須解決錯誤對專案或服務截至時間的影響。這兩種情況都會降低吞吐率並因此增加前置時間。

總之,正確的使用裡特定律可以有助於獲得平穩的工作流,並提升專案和IT服務的可預測性。在製品數量(WIP)是影響專案效能和軟體開發或服務完成所需時間的關鍵因素。限制WIP降低前置時間,此外還會減少工作流程中的浪費。