2.6 साइकल टाइम और इसके घटक

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

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

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

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

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

साइकल टाइम लीड टाइम की व्याख्या करता है; यह इसे प्रतिस्थापित नहीं करता। दोनों को साथ में रिपोर्ट करें, साइकल टाइम को निदान के रूप में और लीड टाइम को सारांश के रूप में।
प्रतीक्षा समय आमतौर पर सक्रिय समय पर हावी होता है। सॉफ़्टवेयर डिलीवरी में अधिकांश देरी एक क़तार में निष्क्रिय बैठे काम से आती है, सक्रिय प्रयास से नहीं (विषय 2.5 इसे फ़्लो दक्षता के माध्यम से सीधे कवर करता है)।
कोई समाधान प्रस्तावित करने से पहले चरण के अनुसार विघटित करें। एक ग़लत चरण पर लक्षित समाधान प्रयास बर्बाद करता है और एक टीम को हतोत्साहित कर सकता है जिसे “तेज़ी से काम करने” के लिए कहा गया जब वास्तविक बॉटलनेक कहीं और था।
कई टीमों में एक साझा बॉटलनेक एक प्लेटफ़ॉर्म निवेश अवसर है, केवल व्यक्तिगत टीम समस्याओं की एक श्रृंखला नहीं।
साइकल-टाइम डेटा फ़्लो समय (विषय 2.4) के समान चालाकी जोखिमों के प्रति उजागर है: उन चरण सीमाओं के लिए देखें जो चुपचाप एक संख्या को बेहतर दिखाने के लिए बदल जाती हैं।

सिफ़ारिशें

हर चरण सीमा को स्पष्ट रूप से इंस्ट्रूमेंट करें

एक परिवर्तन की यात्रा को स्पष्ट, इंस्ट्रूमेंट करने योग्य सीमाओं वाले नामित चरणों में तोड़ें: कोडिंग (पहला कमिट पुल रिक्वेस्ट खोले जाने तक), पिकअप (पुल रिक्वेस्ट खोलना पहली समीक्षा तक), समीक्षा (पहली समीक्षा स्वीकृति तक), और डिप्लॉय (स्वीकृति उत्पादन तक)। विषय 1.5 के इंस्ट्रूमेंटेशन-बनाम-स्व-रिपोर्ट सिद्धांत को लागू करते हुए, हर बदलाव के लिए वर्ज़न कंट्रोल और CI/CD घटनाओं से स्वचालित रूप से टाइमस्टैंप कैप्चर करें, स्व-रिपोर्ट किए गए चरण ट्रैकिंग से नहीं।

हर चरण के भीतर प्रतीक्षा समय को सक्रिय समय से अलग करें

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

टीम-दर-टीम निदान से पहले एक साझा बॉटलनेक के लिए देखें

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

वास्तविक, चरण-विशिष्ट सुधार लक्ष्य निर्धारित करने के लिए साइकल टाइम का उपयोग करें

एक एकल “लीड टाइम को 20% घटाएँ” लक्ष्य की बजाय, जो एक टीम को कहाँ ध्यान केंद्रित करना है इस पर कोई मार्गदर्शन नहीं देता, एक चरण-विशिष्ट लक्ष्य निर्धारित करने के लिए साइकल-टाइम विघटन का उपयोग करें: “माध्यिका समीक्षा प्रतीक्षा समय को दो दिनों से चार घंटे तक घटाएँ।” एक विशिष्ट, चरण-लक्षित लक्ष्य एक टीम के लिए कार्य करना और यह सत्यापित करना दोनों आसान है कि यह वास्तव में कहीं और एक असंबंधित बदलाव की बजाय वास्तविक प्रक्रिया परिवर्तन के माध्यम से प्राप्त किया गया था।

चरण-सीमा चालाकी के लिए देखें

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

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

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

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

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

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

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

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

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

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

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

उदाहरण

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

सरकार। एक राज्य सरकार की डिजिटल सेवा टीम लीड टाइम कम करने के दबाव में थी, और शुरू में इंजीनियरों से तेज़ी से काम करने के लिए कहकर प्रतिक्रिया दी, एक स्वाभाविक लेकिन अंततः अनुपयोगी सहज ज्ञान। साइकल-टाइम विघटन ने दिखाया कि सक्रिय कोडिंग समय वर्ष-दर-वर्ष शायद ही बदला था; लगभग सारी गिरावट अठारह महीने पहले एक अनुपालन उपाय के रूप में पेश किए गए एक अनिवार्य वास्तुशिल्पीय-समीक्षा चरण में बढ़ती क़तार से आई थी। टीम ने कम-जोखिम परिवर्तनों के लिए उस समीक्षा को एक हल्की, जोखिम-स्तरीकृत प्रक्रिया में फिर से डिज़ाइन किया, वास्तव में उच्च-जोखिम परिवर्तनों के लिए पूर्ण समीक्षा कठोरता को संरक्षित करते हुए समीक्षा प्रतीक्षा समय को काफ़ी हद तक कम किया।

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

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

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

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

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

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

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

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

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

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

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

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

The Principles of Product Development Flow, by Donald G. Reinertsen (साइकल-टाइम विश्लेषण के अंतर्निहित क्यूइंग थ्योरी और बैच-आकार तर्क)।
Actionable Agile Metrics for Predictability, by Daniel S. Vacanti (सॉफ़्टवेयर डिलीवरी के लिए साइकल-टाइम और फ़्लो-आधारित माप)।
Accelerate: The Science of Lean Software and DevOps, by Nicole Forsgren, Jez Humble, and Gene Kim (लीड टाइम और डिलीवरी प्रदर्शन से इसका संबंध)।
The Goal, by Eliyahu M. Goldratt (बाधाओं का सिद्धांत, और हर जगह अनुकूलन करने की बजाय वास्तविक बॉटलनेक को खोजने और ठीक करने का सिद्धांत)।