最近小孩老生病，經常跑醫院，經歷了無數次的排隊，即心煩又無可奈何，不自覺對排隊理論做了一些思考，對看板方法中的限制在製品有一些新的感觸。
排隊論
- 網上查了一些資料，排隊系統包括三個組成部分：輸入過程、排隊規則和服務機構。
- 輸入過程考察的是顧客到達服務系統的規律。它可以用一定時間內顧客到達數或前後兩個顧客相繼到達的間隔時間來描述，一般分爲確定型和隨機型兩種。
- 例如，病人按照預約時間前來看病，還有高鐵、班機等都屬於確定型輸入。隨機型的輸入是指在一定時間內顧客到達數服從一定的隨機分佈，比如沒有預約的病人。
- 排隊規則分爲等待制、損失制和混合制三種。
- 當顧客到達時，所有服務機構都被佔用，則排隊等候，即爲等待制。等待制中，爲顧客進行服務的次序可以是先到先服務，或後到先服務，或是有優先權服務（如急救病人）。如果顧客來到後看到服務機構沒有空閒立即離去（如餐館人太多），則爲損失制。有些系統因留給顧客排隊等待的空間有限，因此超過所能容納人數的顧客必須離開系統（醫院預約系統、景區限制預約人數），這種排隊規則就是混合制。
- 服務機構可以是一個或多個服務檯。多個服務檯可以是平行排列的，也可以是串連排列的。服務時間一般也分成確定型和隨機型兩種。
- 例如，自動沖洗汽車的裝置對每輛汽車沖洗（服務）時間是相同的，因而是確定型的。而隨機型服務時間則服從一定的隨機分佈，比如醫生看病的時間。
- 排隊論有三大重要指標：隊長、逗留時間、系統負荷水平，可細分爲以下六個指標：
- ①系統負荷水平：它是衡量服務檯在承擔服務和滿足需要方面能力的尺度；
- ②系統空閒概率：系統處於沒有顧客來到要求服務的概率；
- ③隊長：系統中排隊等待服務和正在服務的顧客總數；
- ④隊列長：系統中排隊等待服務的顧客數；
- ⑤逗留時間：一個顧客在系統中停留時間，包括等待時間和服務時間；
- ⑥等待時間：一個顧客在系統中排隊等待時間。
- 評價一個排隊系統的好壞要以顧客與服務機構兩方面的利益爲標準。就顧客來說總希望逗留時間越短越好，從而希望服務檯個數儘可能多些，但是就服務機構來說，增加服務檯數，就意味着增加投資，增加多了會造成浪費，增加少了要引起顧客的抱怨甚至失去顧客？所以要想系統效能最大化，就要均衡考慮隊長、逗留時間、系統負荷這三個因素。
利特爾法則
- 1961年，麻省理工大學斯隆商學院的教授John Little根據排隊論提出了利特爾法則（little’s law，也叫裏特定律）。該法則的公式爲：生產週期=存貨數量×生產節拍。其中，存貨數量，指原材料和在製品的數量，生產節拍，指每生產一個產品所要的時間。因爲它揭示了生產過程的規律，告訴我們，縮短生產週期可以縮短生產節拍，也可以減少存貨數量，在精益生產中得到了廣泛應用。
- 後來引申出吞吐率的概念，在多個領域被應用：
在項目中的應用
- 假設團隊吞吐率不變，如何能提高項目團隊的產出哪？
- 一、限制在製品
- 如果生產率沒有明顯變化，那麼WIP越大，則前置時間越長，即要完成已經開始的工作需要更長的時間。所以，爲了在截止時間之前完成交付，我們必須減少在製品數量。儘管看起來違反直覺，但需要記住的是：限制WIP有助於降低前置時間。
- 然而，很多時候項目被塞入越來越多任務，通常人們相信，並行開展多個任務能夠提升生產力。然而，與機器不同的是，人類並不善於以並行處理的方式執行。增加在製品還會增加出錯概率，增加某項任務修改和返工的時間，從而降低吞吐率。最終，到截止時間，產生很多已經開始但還未結束的工作無法交付，於是尋求進度延期。
- 當然WIP也不是越低越好，WIP底了，資源未被充分利用，等於系統空閒概率提升，系統負荷水平降低，所以團隊應通過迭代逐漸找到適合自己的WIP。
- 二、降低前置時間
- 降低前置時間，包括減少等待時間和工作時間。因爲團隊生產率已假設沒有明顯變化，那麼工作時間就基本是固定的，只能考慮如何減少等待時間。這可以通過兩個方面來優化：
- 1、輸入過程的優化，比如把需求的輸入由隨機型人爲的調整爲確定型，即按照固定迭代交付，只有排列到這個迭代的需求才納入開發。
- 2、排隊規則的優化，比如採用前面說的優先權服務，即對需求排優先級：緊急需求、普通需求、固定時間需求、技術債。
- 基於以上的思考，可以得出幾個結論：
- 1、項目延期時，我們往往最先想到的是增加資源，但這不是最優的方法，一方面會增加溝通成本；另一方面，會增加在製品數量，進而增加前置時間，即反而更容易延期。這時候應該考慮是否存在低優先級的需求可以剔除，減少在製品；還有當前的瓶頸在哪裏，如何提高瓶頸資源的利用率等。
- 2、解除阻塞的重要性：某項工作阻塞，那麼這項工作的執行人就無法提供服務，導致資源浪費。
- 3、特性團隊比組件團隊更有利於項目交付，特性團隊可以專注於特性的端到端交付，減少並行工作，防止價值流阻塞，提高系統負荷水平；而組件團隊需要兼顧團隊間的優先級，且容易受制於關聯團隊的進度影響，不得不併行交付多個版本，導致前置時間增加。這也是成功推行敏捷開發的前提條件，如果無法從組織結構上改變，建議可以成立虛擬團隊。
