2.7 क्यूइंग थ्योरी

अवलोकन और प्रेरणा

क्यूइंग थ्योरी प्रतीक्षा रेखाओं का गणितीय अध्ययन है। यह सॉफ़्टवेयर इंजीनियरिंग मेट्रिक्स पर एक पुस्तक के लिए एक अजीब मेल जैसा लगता है जब तक आप यह नहीं देखते कि एक डिलीवरी पाइपलाइन का कितना हिस्सा वास्तव में एक क़तार है: एक समीक्षक की प्रतीक्षा में एक पुल रिक्वेस्ट, एक CI रनर की प्रतीक्षा में एक कमिट, उठाए जाने की प्रतीक्षा में एक टिकट, एक प्रतिक्रिया की प्रतीक्षा में एक ग्राहक सहायता संदेश। विषय 2.4 पहले ही फ़्लो लोड और फ़्लो समय का परिचय दे चुका है और दिखाया है कि एक वैल्यू स्ट्रीम को अधिक भारित करना डिलीवरी को तेज़ी से धीमा कर देता है, और विषय 2.5 और 2.6 ने दिखाया कि अधिकांश डिलीवरी समय प्रतीक्षा समय है, काम का समय नहीं। क्यूइंग थ्योरी वह अंतर्निहित गणित है जो बताता है कि वह सब सत्य क्यों है, केवल एक देखा गया पैटर्न नहीं।

एकल सबसे उपयोगी परिणाम है लिटिल का नियम, संचालन शोधकर्ता John Little द्वारा 1961 में सिद्ध किया गया एक प्रमेय: एक स्थिर प्रणाली में औसत आइटम संख्या उस औसत दर के बराबर होती है जिस पर आइटम आते हैं, हर आइटम द्वारा प्रणाली में बिताए गए औसत समय से गुणा किया गया। विषय 2.4 ने पहले ही इस परिणाम का उपयोग फ़्लो फ्रेमवर्क के अपने नामों के तहत किया, फ़्लो लोड आगमन दर गुणा फ़्लो समय के बराबर है। इस पुस्तक की व्यापक शब्दावली में यह वर्क इन प्रोसेस (विषय 2.5) नए काम की आगमन दर गुणा साइकल टाइम (विषय 2.6) के बराबर के रूप में भी पढ़ा जाता है। यह कोई अंगूठे का नियम या कुछ अध्ययनों में देखा गया सहसंबंध नहीं है। यह एक प्रमाण है जो किसी भी स्थिर क़तार के लिए सत्य है, चाहे क़तार क्या प्रोसेस कर रही हो या यह कैसे तय करती है कि आगे क्या काम करना है।

एक बड़ी टीम के लिए, वह सामान्यता मुद्दा है। लिटिल का नियम आपको एक सैनिटी चेक देता है जो समान रूप से काम करता है चाहे क़तार एक कानबान बोर्ड हो, एक मैसेज ब्रोकर हो, या एक साझा CI पाइपलाइन हो। यदि आपकी मापी गई वर्क इन प्रोसेस, आगमन दर, और साइकल टाइम लगभग समीकरण को संतुष्ट नहीं करते, तो आपकी तीन संख्याओं में से एक ग़लत है, आमतौर पर इसलिए क्योंकि “प्रगति में” या “आया हुआ” के रूप में क्या गिना जाता है इसकी एक असंगत परिभाषा है। एंटरप्राइज़ और सरकारी संगठन एक साथ ऐसी दर्जनों क़तारें चलाते हैं, साझा कोड समीक्षा पूल, साझा परीक्षण वातावरण, साझा स्वीकृति बोर्ड, और लिटिल का नियम एक ख़राब मेट्रिक परिभाषा को इससे पहले पकड़ने के लिए उपलब्ध सबसे सस्ता उपकरण है कि यह एक ख़राब स्टाफ़िंग या प्रक्रिया निर्णय को चलाए।

प्रमुख सिद्धांत

लिटिल का नियम एक प्रमाण है, कोई अनुमानात्मक नहीं। किसी भी स्थिर क़तार के लिए, वर्क इन प्रोसेस आगमन दर गुणा साइकल टाइम के बराबर है, और यह इस बात की एक तेज़ जाँच है कि क्या आपके डिलीवरी मेट्रिक्स आंतरिक रूप से सुसंगत हैं।
उपयोग प्रतीक्षा समय के साथ रैखिक रूप से नहीं बढ़ता। जैसे-जैसे एक साझा संसाधन पूर्ण उपयोग के क़रीब पहुँचता है, क़तारबद्धता देरी तेज़ी से बढ़ती है, धीरे-धीरे नहीं। 95% व्यस्त चलने वाला एक संसाधन अक्सर 80% चलने वाले से कई गुना अधिक प्रतीक्षा कर रहा होता है, केवल “थोड़ा बुरा” नहीं।
एक क़तार का औसत उसके सबसे बुरे मामले को छुपाता है। केवल औसत प्रतीक्षा समय की रिपोर्ट करना उस लंबी, दर्दनाक पूँछ को छुपाता है जो क्षमता के क़रीब है, ठीक वही जिसके विरुद्ध विषय 1.6 चेतावनी देता है जब औसत की बजाय प्रतिशतक का उपयोग करने की बात आती है।
एक क़तार को कैसे परिभाषित किया जाता है इसके साथ किसी भी अन्य मेट्रिक जितनी आसानी से चालाकी की जा सकती है। क्या कुछ “आया हुआ,” “प्रगति में,” या “सेवित” गिना जाता है यह एक चुनाव है, और इसे काम के साथ वास्तव में जो होता है उसे बदले बिना एक डैशबोर्ड को बेहतर दिखाने के लिए ट्यून किया जा सकता है।
एक पाइपलाइन आमतौर पर क़तारों की एक क़तार होती है। एक डिलीवरी पाइपलाइन कई चरणों को एक साथ जोड़ती है, और सबसे धीमा चरण पूरी श्रृंखला के लिए गति निर्धारित करता है चाहे बाक़ी कितनी तेज़ी से चलें।

सिफ़ारिशें

भरोसा करने से पहले अपनी संख्याओं की जाँच के लिए लिटिल के नियम का उपयोग करें

अपनी टीम की मापी गई औसत वर्क इन प्रोसेस, प्रति सप्ताह नई आइटमों की इसकी औसत आगमन दर, और इसका औसत साइकल टाइम लें, और जाँचें कि क्या वर्क इन प्रोसेस लगभग आगमन दर गुणा साइकल टाइम के बराबर है। जब ऐसा नहीं होता, तो यह न मानें कि थ्योरी ग़लत है। वास्तविक कारण के लिए देखें: एक चरण सीमा जिसे असंगत रूप से गिना गया, ऐसा काम जो “अवरुद्ध” बैठा है लेकिन फिर भी प्रगति में गिना जाता है, या एक आगमन दर जिसे साइकल टाइम से अलग विंडो में मापा गया। यह एकल जाँच अधिकांश टीमों द्वारा किसी भी अन्य तरीक़े से खोजी गई ख़राब इंस्ट्रूमेंटेशन से अधिक पकड़ती है।

हर साझा, क्षमता-बाधित संसाधन के लिए सीधे उपयोग को ट्रैक करें

उन संसाधनों की पहचान करें जिन्हें आपकी डिलीवरी पाइपलाइन कई टीमों में साझा करती है, एक कोड समीक्षा पूल, एक CI क्लस्टर, एक स्टेजिंग वातावरण, और मापें कि हर एक कितना व्यस्त चलता है इसकी उपलब्ध क्षमता के अनुपात के रूप में, इसे इसकी सीमा के क़रीब चलाने की योजना बनाने से पहले। एक साझा समीक्षक समूह पूर्ण क्षमता के क़रीब चलने से समीक्षा-क़तार प्रतीक्षा समय उत्पन्न होता है जो उस मामूली माँग वृद्धि से कहीं तेज़ी से बढ़ता है जिसने उन्हें कारणित किया, ठीक वही गतिशीलता जो विषय 2.9 की सलाह के पीछे है कि समय-से-पहली-समीक्षा को एक अग्रणी संकेतक के रूप में देखें।

आगमन दर, सफलता दर, विफलता दर, और स्किप दर को अलग करें

क़तार छोड़ने वाली हर चीज़ को एक एकल “थ्रूपुट” या “सेवा दर” संख्या में संक्षिप्त करने का विरोध करें। चार चीज़ों को अलग-अलग ट्रैक करें: काम कितनी तेज़ी से आता है, इसका कितना हिस्सा सफलतापूर्वक समाप्त होता है, कितना विफल होता है और पुनःकार्य की आवश्यकता होती है, और कितना किसी के इसे पूरा करने से पहले छोड़ दिया जाता है या चुपचाप गिरा दिया जाता है। एक पाइपलाइन जो तेज़ दिखती है क्योंकि इसकी स्किप दर चुपचाप बढ़ी है वास्तव में अधिक नहीं पहुँचा रही है, और केवल इन चार दरों को अलग-अलग ट्रैक करना ही आपको यह दिखाएगा।

बहु-चरण पाइपलाइनों को क़तारों की एक क़तार के रूप में मॉडल करें

एक डिलीवरी पाइपलाइन, या किसी भी बहु-चरण प्रक्रिया, एक घटना जीवनचक्र, एक भर्ती पाइपलाइन, को “समय” के एक अविभेदित द्रव्यमान की बजाय क़तारों की एक श्रृंखला मानें। समग्र आगमन दर पहले चरण द्वारा निर्धारित होती है, समग्र पूर्णता दर अंतिम चरण द्वारा, और पाइपलाइन की कुल त्रुटि और स्किप गिनती हर चरण की अपनी गिनतियों का योग है। यह फ़्रेमिंग आपको तुरंत बताती है कि किस चरण में निवेश करना लायक़ है: उच्च उपयोग और उच्च विफलता या स्किप दर के सबसे बुरे संयोजन वाला, वह नहीं जो इंस्ट्रूमेंट करना सबसे आसान होता है।

केवल थ्रूपुट को नहीं, उपयोग को ध्यान में रखते हुए स्टाफ़िंग और WIP सीमाएँ निर्धारित करें

जब आप तय करते हैं कि एक टीम को कितने समीक्षकों या CI रनरों की आवश्यकता है, तो क्षमता को औसत आगमन दर से बिल्कुल मेल खाने के लिए आकार न दें। औसतन 100% उपयोग पर चलने वाली एक क़तार का व्यवहार में प्रभावी रूप से अनंत प्रतीक्षा समय होता है, क्योंकि वास्तविक आगमन असमान होते हैं, पूरी तरह चिकने नहीं। जान-बूझकर हेडरूम की योजना बनाएँ, और “हमारे समीक्षक लगभग हमेशा व्यस्त हैं” को आने वाले प्रतीक्षा समय के बारे में एक चेतावनी संकेत मानें, कुशल संसाधन का प्रमाण नहीं।

समझौते: लाभ और हानि

दृष्टिकोण	लाभ	हानि
कोई औपचारिक क़तार मॉडल नहीं, अंतर्ज्ञान-आधारित स्टाफ़िंग	शुरू करने में तेज़; टीम के लिए कोई नई शब्दावली नहीं	लगातार यह कम आँकता है कि पूर्ण क्षमता के क़रीब प्रतीक्षा समय कैसे विस्फोटित होता है
मौजूदा मेट्रिक्स पर एक सैनिटी चेक के रूप में लिटिल का नियम	सस्ता, किसी नई टूलिंग की आवश्यकता नहीं, ख़राब परिभाषाओं को जल्दी पकड़ता है	केवल सुसंगति की जाँच करता है, अपने आप में कारण का निदान नहीं करता
पूर्ण क़तार अनुकरण (आगमन वितरण, कई सर्वर)	लोड के तहत प्रतीक्षा-समय व्यवहार की सबसे सटीक भविष्यवाणी	वास्तविक सांख्यिकीय कौशल और रखरखाव की आवश्यकता जिसे अधिकांश टीमें बनाए नहीं रख पाएँगी
गहन मॉडलिंग के बिना साझा संसाधनों पर उपयोग ट्रैकिंग	सरल, कार्रवाई योग्य, भागते प्रतीक्षा समय के सबसे बड़े एकल कारण को पकड़ता है	यह कुछ नहीं बताता कि उपयोग अधिक क्यों है या अंतर्निहित कारण के बारे में क्या करना है

केंद्रीय तनाव है कठोरता बनाम अपनाना। एक पूर्ण क़तार अनुकरण सबसे सटीक उत्तर देता है, लेकिन लगभग कोई भी इंजीनियरिंग टीम एक नहीं बनाएगी और बनाए नहीं रखेगी, और एक मॉडल जिस पर कोई भरोसा नहीं करता या अपडेट नहीं करता वह किसी मॉडल से भी बुरा है। लिटिल का नियम और बुनियादी उपयोग ट्रैकिंग कुछ सटीकता छोड़ते हैं लेकिन किसी विशिष्ट सांख्यिकीय कौशल की आवश्यकता नहीं रखते और सीधे उन मेट्रिक्स में फिट होते हैं जो एक टीम विषय 2.4 से 2.6 के लिए पहले से एकत्र करती है। उन सस्ते, अपनाने योग्य जाँचों को डिफ़ॉल्ट मानें, और पूर्ण अनुकरण को उस दुर्लभ मामले के लिए आरक्षित रखें जहाँ एक एकल साझा संसाधन, एक बड़ा CI फ़्लीट, एक विशेष समीक्षा पूल, निवेश को न्यायोचित ठहराने के लिए पर्याप्त महंगा है।

अपनी टीम के साथ चर्चा करने के प्रश्न

क्या हमारी मापी गई वर्क इन प्रोसेस, आगमन दर, और साइकल टाइम वास्तव में लिटिल के नियम को संतुष्ट करते हैं, और यदि नहीं, तो क्यों नहीं? यह एक ख़राब मेट्रिक परिभाषा के लिए उपलब्ध एकल सबसे तेज़ निदान है। वास्तविक संख्याओं के साथ मिलकर गुज़रें, और यदि समीकरण लगभग नहीं टिकता, तो जाँच को ख़ारिज करने की बजाय बेमेल को एक विशिष्ट परिभाषात्मक असंगति तक ट्रेस करें।
हमारी डिलीवरी पाइपलाइन में कौन-से साझा संसाधन पूर्ण उपयोग के क़रीब चल रहे हैं, और क्या हम वास्तव में उनकी उपयोग संख्या जानते हैं? अधिकांश टीमें एक ऐसे संसाधन का नाम ले सकती हैं जो “हमेशा व्यस्त महसूस होता है” लेकिन कभी सीधे इसका उपयोग नहीं मापा। दो या तीन सबसे बाधित साझा संसाधनों की पहचान करें और हर एक के लिए एक वास्तविक संख्या प्राप्त करें।
क्या हम सफलता, विफलता, और स्किप को एक थ्रूपुट संख्या में मिला रहे हैं, और यदि हम उन्हें अलग करते तो हम क्या देखते? एक एकल “पूर्ण की गई आइटमें” गिनती बढ़ सकती है जबकि गुणवत्ता गिरती है या काम चुपचाप छोड़ दिया जाता है। हाल की अवधि के थ्रूपुट की तीन अलग-अलग संख्याओं के रूप में पुनर्गणना करें और चर्चा करें कि विभाजन क्या उजागर करता है जो मिश्रित संख्या ने छुपाया।
हमारी पाइपलाइन में वास्तविक बॉटलनेक कहाँ है, सबसे धीमा चरण जो इसके नीचे की हर चीज़ के लिए गति निर्धारित करता है? टीमें अक्सर उस चरण को तेज़ करने में निवेश करती हैं जो सुधारना सबसे आसान है, न कि वह जो वास्तव में कुल थ्रूपुट को सीमित करता है। उच्च उपयोग और उच्च विफलता या स्किप दर के सबसे बुरे संयोजन वाले चरण की पहचान करें।
यदि हमने अपने सबसे बाधित साझा संसाधन में क्षमता जोड़ी, तो क्या प्रतीक्षा समय वास्तव में सुधरेगा, या क्या माँग बस इसे भरने के लिए विस्तारित हो जाएगी? यह प्रश्न एक वास्तविक क्षमता कमी को एक माँग समस्या से अलग करता है, और उत्तर यह बदल देता है कि सही समाधान अधिक हेडकाउंट है, एक WIP सीमा है, या क़तार में प्रवेश करने से पहले काम को प्राथमिकता देने के तरीक़े में बदलाव है।
क्या हमने कभी “प्रगति में” या “आया हुआ” के रूप में क्या गिना जाता है इसे इस तरह फिर से परिभाषित किया है जिसने काम के साथ वास्तव में जो हुआ उसे बदले बिना एक डैशबोर्ड को बेहतर दिखाया? यह पिछले वर्ष के वास्तविक उदाहरणों के साथ ईमानदारी से और विशेष रूप से पूछने लायक़ है, इसे एक काल्पनिक चिंता मानने की बजाय।

क्षेत्र दृष्टिकोण

स्टार्टअप। मुट्ठी भर इंजीनियरों के साथ, अधिकांश क़तारें इतनी छोटी होती हैं कि औपचारिक क़तार विश्लेषण अत्यधिक है। उपयोगी आदत छोटी है: ध्यान दें जब एक व्यक्ति, अक्सर सबसे वरिष्ठ इंजीनियर, वास्तविक रूप से एक साझा संसाधन बन गया है जिस पर बाक़ी सब कुछ प्रतीक्षा करता है, और इसे बिना किसी औपचारिक मॉडल के भी नाम देने लायक़ एक उपयोग समस्या के रूप में मानें।

छोटा व्यवसाय। एक छोटे व्यवसाय टीम को शायद ही कभी अपने एक या दो वास्तव में साझा संसाधनों पर उपयोग ट्रैक करने से अधिक परिष्कृत किसी चीज़ की आवश्यकता होती है, अक्सर एक अकेला समीक्षक या एक अकेली डिप्लॉय पाइपलाइन, और उस बिंदु के लिए देखना जहाँ “आमतौर पर उपलब्ध” चुपचाप “आमतौर पर बॉटलनेक” बन जाता है। एक स्प्रेडशीट पर्याप्त है; इस पैमाने पर समर्पित टूलिंग आवश्यक नहीं है।

एंटरप्राइज़। एंटरप्राइज़ पैमाने पर साझा संसाधन तेज़ी से बढ़ते हैं: एक केंद्रीय प्लेटफ़ॉर्म टीम, एक साझा सुरक्षा समीक्षा बोर्ड, दर्जनों उत्पाद टीमों की सेवा करने वाला एक साझा CI फ़्लीट। ये ठीक वे संसाधन हैं जहाँ उपयोग ट्रैकिंग अपनी क़ीमत कमाती है, क्योंकि एक एकल अधिक भरा हुआ साझा संसाधन इस पर निर्भर हर टीम के लिए चुपचाप डिलीवरी समय को ख़राब कर सकता है, और किसी भी व्यक्तिगत टीम के अपने मेट्रिक्स एक ऐसा कारण उजागर नहीं करेंगे जो उनकी अपनी पाइपलाइन के बाहर रहता है।

सरकार। बहु-एजेंसी और बहु-विक्रेता डिलीवरी कार्यक्रम अक्सर काम को साझा स्वीकृति बोर्डों, साझा सुरक्षा प्रत्यायन प्रक्रियाओं, और साझा परीक्षण वातावरणों के माध्यम से रूट करते हैं जिन्हें कोई भी अकेली टीम नियंत्रित या अपने दम पर आकार नहीं दे सकती। इन साझा द्वारों का क़तार विश्लेषण, आगमन दर, क्षमता, उपयोग, अक्सर क्षमता जोड़ने या द्वार तक पहुँचने से पहले काम को बैच करने के तरीक़े को बदलने के लिए एक व्यावसायिक मामले के लिए उपलब्ध सबसे स्पष्ट प्रमाण है।

उदाहरण

एंटरप्राइज़। एक क्लाउड अवसंरचना प्रदाता की आंतरिक प्लेटफ़ॉर्म टीम ने देखा कि परिवर्तनों के लिए लीड टाइम (विषय 2.10) उसके साझा CI फ़्लीट पर निर्भर हर उत्पाद टीम में रेंग रहा था, भले ही किसी भी व्यक्तिगत टीम ने अपने काम करने के तरीक़े में बदलाव नहीं किया था। एक उपयोग विश्लेषण ने पाया कि फ़्लीट मुख्य घंटों के दौरान 90% से अधिक व्यस्त चल रहा था, उस बिंदु से बहुत आगे जहाँ क्यूइंग थ्योरी भविष्यवाणी करती है कि प्रतीक्षा समय धीरे-धीरे की बजाय तेज़ी से बढ़ता है। प्लेटफ़ॉर्म टीम ने CI क्षमता जोड़ी और एक निष्पक्ष-हिस्सा शेड्यूलिंग नीति पेश की ताकि किसी एक टीम की गतिविधि का उछाल क़तार को एकाधिकृत न कर सके। माध्यिका CI प्रतीक्षा समय एक महीने के भीतर आधे से अधिक गिर गया, प्रमाण कि बॉटलनेक हमेशा से एक साझा, अदृश्य क़तार रहा था।

सरकार। एक राष्ट्रीय परमिट एजेंसी की डिजिटल सेवा टीम ने दो वर्षों तक आवेदन प्रोसेसिंग को एक एकल “प्रति सप्ताह बंद किए गए मामले” थ्रूपुट संख्या के रूप में ट्रैक किया, और संख्या स्थिर दिखती थी। एक क़रीबी विश्लेषण, उस संख्या को स्वीकृत, अस्वीकृत, और लंबी देरी के बाद आवेदकों द्वारा छोड़े गए मामलों में विभाजित करते हुए, ने पाया कि उसी अवधि में परित्याग दर लगभग तिगुनी हो गई थी जबकि स्वीकृतियाँ स्थिर रहीं। केसवर्कर क़तार पर लागू लिटिल के नियम ने दिखाया कि वर्क इन प्रोसेस टीम के बताए गए औसत प्रोसेसिंग समय से कहीं अधिक बढ़ गया था, जिसका अर्थ है कि मामले चुपचाप एक ऐसी स्थिति में ढेर हो रहे थे जिसे “प्रतीक्षारत” के रूप में नहीं गिना गया था। एजेंसी ने हर खुले मामले को ईमानदारी से गिनने के लिए अपनी केस-ट्रैकिंग परिभाषाओं का पुनर्गठन किया और उपयोग को 85% से नीचे रखने के लिए आकार वाली केसवर्कर क्षमता जोड़ी, अब थ्रूपुट संख्या के साथ-साथ एक स्थायी परिचालन लक्ष्य के रूप में ट्रैक किया जाता है।

व्यावसायिक तर्क: प्रेरणाएँ, ROI, और TCO

बुनियादी क़तार विश्लेषण लागू करने का प्रतिफल यह है कि यह “पाइपलाइन धीमी महसूस होती है” को एक विशिष्ट, बचाव योग्य निर्णय में बदल देता है, इस साझा संसाधन में हेडरूम जोड़ें, इस मिश्रित मेट्रिक को इसके वास्तविक घटकों में विभाजित करें, वास्तविक कारण को चूकने वाले “तेज़ी से काम करो” के अस्पष्ट धक्के की बजाय। ऊपर का क्लाउड अवसंरचना उदाहरण, व्यक्तिगत टीमों के व्यवहार में किसी भी बदलाव की बजाय एक क्षमता और शेड्यूलिंग समाधान से आधा प्रतीक्षा समय, वह पैटर्न है जिसे यह विश्लेषण विश्वसनीय रूप से उत्पन्न करता है: समाधान लगभग हमेशा हर डाउनस्ट्रीम टीम को एक बॉटलनेक के आसपास तेज़ी से चलने के लिए कहने से सस्ता होता है जिसे वे देख नहीं सकते।

अपनाने की कुल लागत वास्तव में कम है। लिटिल के नियम और उपयोग ट्रैकिंग को किसी नई टूलिंग की आवश्यकता नहीं है उससे परे जो विषय 2.4 से 2.6 पहले से आपसे एकत्र करने के लिए कहते हैं: आगमन दर, वर्क इन प्रोसेस, और साइकल टाइम। निवेश अधिकांशतः विश्लेषणात्मक अनुशासन है, संख्याओं की एक दूसरे के विरुद्ध जाँच करना और साझा संसाधनों पर उपयोग की समय-समय पर समीक्षा करना इससे पहले कि वे संगठन की अगली अस्पष्ट लीड-टाइम गिरावट बनें।

विरोधी-पैटर्न और नुक़सान

एक साझा संसाधन की क्षमता को उसकी औसत आगमन दर से बिल्कुल मेल खाने के लिए आकार देना: जब भी माँग संक्षेप में भी असमान होती है उच्च उपयोग और भागते प्रतीक्षा समय की गारंटी देता है।
केवल औसत प्रतीक्षा समय की रिपोर्ट करना, कभी एक प्रतिशतक नहीं: उस लंबी पूँछ को छुपाता है जो इसमें प्रतीक्षा करने वाले लोगों के लिए सबसे अधिक मायने रखती है।
सफलता, विफलता, और स्किप को एक थ्रूपुट संख्या में मिलाना: इस विषय के केंद्र में चालाकी वेक्टर। दबाव में एक टीम स्किप दर को चुपचाप बढ़ने देकर थ्रूपुट को स्वस्थ दिखा सकती है, छोड़े गए टिकट, चुपचाप गिराए गए अनुरोध, ऐसा काम जिसे कभी विफलता के रूप में नहीं गिना जाता। गार्डरेल आगमन, सफलता, विफलता, और स्किप दर को चार अलग-अलग, दृश्यमान संख्याओं के रूप में ट्रैक करना है, वही अनुशासन जो विषय 1.2 इस पुस्तक के हर मेट्रिक के लिए माँगता है, ताकि एक बढ़ती स्किप दर एक स्थिर थ्रूपुट चार्ट के पीछे न छिप सके।
“हमारे लोग हमेशा व्यस्त हैं” को एक तारीफ़ मानना: यह उच्च उपयोग का एक लक्षण है, लंबे, अप्रत्याशित प्रतीक्षा समय का प्रमुख कारण।
वर्क इन प्रोसेस को चुपचाप सिकोड़ने के लिए “प्रगति में” को फिर से परिभाषित करना: काम को इसे पूरा करने में कितना समय लगता है यह बदले बिना एक अनगिनत स्थिति, “अवरुद्ध,” “रोक पर,” में स्थानांतरित करता है, और लिटिल के नियम की जाँच को तोड़ता है जो अन्यथा इसे पकड़ लेती।
यह मान लेना कि एक बार बनाए जाने के बाद एक क़तार मॉडल को किसी रखरखाव की आवश्यकता नहीं है: आगमन पैटर्न और क्षमता लगातार बदलती है, और एक पुराना मॉडल आत्मविश्वास से ग़लत भविष्यवाणियाँ उत्पन्न करता है।

परिपक्वता मॉडल

स्तर 1, आरंभ: किसी भी क़तार को स्पष्ट रूप से नहीं मापा जाता; प्रतीक्षा समय की चर्चा “चीज़ें धीमी महसूस होती हैं” के रूप में किस्सों के रूप में की जाती है।
स्तर 2, विकास: कम से कम एक पाइपलाइन के लिए आगमन दर, वर्क इन प्रोसेस, और साइकल टाइम को ट्रैक किया जाता है, लेकिन कभी लिटिल के नियम या साझा संसाधनों पर उपयोग के विरुद्ध जाँचा नहीं जाता।
स्तर 3, मानकीकरण: लिटिल का नियम डिलीवरी पाइपलाइनों में एक नियमित सुसंगति जाँच है, और सबसे महत्वपूर्ण साझा संसाधनों के लिए उपयोग को स्पष्ट रूप से ट्रैक किया जाता है।
स्तर 4, प्रबंधन: हर महत्वपूर्ण क़तार के लिए सफलता, विफलता, और स्किप दर को अलग-अलग ट्रैक किया जाता है, और क्षमता निर्णय उपयोग लक्ष्यों का उपयोग करते हैं, केवल औसत माँग नहीं।
स्तर 5, संयोजन: संगठन अपनी प्रमुख पाइपलाइनों को क़तारों की क़तार के रूप में मॉडल करता है, व्यवस्थित रूप से वास्तविक बॉटलनेक की पहचान करता है, और विशिष्ट क्षमता या प्रक्रिया परिवर्तनों की ओर इशारा कर सकता है जो क़तार विश्लेषण के कारण किए गए, जिनके लिए दिखाने के लिए मापा गया प्रतीक्षा-समय सुधार है।

चर्चा के लिए विचार

हमारी एक डिलीवरी पाइपलाइन चुनें और जाँचें कि क्या इसकी संख्याएँ आज लिटिल के नियम को संतुष्ट करती हैं।
हमारे संगठन में उस एकल साझा संसाधन का नाम लें जिसे अधिकांश लोग “हमेशा व्यस्त” मानने पर सहमत होंगे, और इसकी वास्तविक उपयोग संख्या खोजें।
यदि हमने पिछले चौथाई के लिए इसे सफलता, विफलता, और स्किप दरों में विभाजित किया तो हमारा थ्रूपुट चार्ट कैसा दिखेगा?
यदि हमें इस वर्ष ठीक एक साझा संसाधन में क्षमता जोड़नी पड़ती, तो कौन-सा, और इसे न्यायोचित ठहराने के लिए क्या प्रमाण होगा?

मुख्य निष्कर्ष

लिटिल का नियम, वर्क इन प्रोसेस आगमन दर गुणा साइकल टाइम के बराबर है, एक प्रमाण है, कोई अनुमानात्मक नहीं, और यह इस बात की उपलब्ध सबसे सस्ती जाँच है कि क्या आपके डिलीवरी मेट्रिक्स आंतरिक रूप से सुसंगत हैं।
प्रतीक्षा समय धीरे-धीरे नहीं बल्कि तेज़ी से बढ़ता है जैसे-जैसे उपयोग पूर्ण क्षमता के क़रीब पहुँचता है। “हमेशा व्यस्त” को एक चेतावनी संकेत मानें, तारीफ़ नहीं।
आगमन दर, सफलता दर, विफलता दर, और स्किप दर को अलग-अलग ट्रैक करें; उन्हें एक थ्रूपुट संख्या में मिलाना इस विषय का केंद्रीय चालाकी वेक्टर है।
एक बहु-चरण पाइपलाइन को क़तारों की एक क़तार के रूप में मॉडल करें, और उच्च उपयोग और उच्च विफलता या स्किप दर के सबसे बुरे संयोजन वाले चरण में निवेश करें, उस चरण में नहीं जो सुधारना सबसे आसान है।
कुछ ही टीमें बनाए रख पाएँगी ऐसे एक पूर्ण क़तार अनुकरण की तुलना में सस्ती, अपनाने योग्य जाँचों, लिटिल का नियम और उपयोग ट्रैकिंग, को प्राथमिकता दें।

संदर्भ और आगे पढ़ने के लिए

Little, John D. C. “A Proof for the Queuing Formula: L = λW.” Operations Research, 1961.
Kleinrock, Leonard. Queueing Systems, Volume 1: Theory. Wiley-Interscience, 1975.
Wescott, Bob. The Every Computer Performance Book: How to Avoid and Solve Performance Problems on the Computer Systems You Work With. CreateSpace Independent Publishing Platform, 2013.
Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.
Vacanti, Daniel S. Actionable Agile Metrics for Predictability. Actionable Agile Press, 2015.