एविएटर से नया: इंजीनियरिंग दक्षता का आकलन करने वाला कैलकुलेटर

इंजीनियरिंग उत्पादकता को मापना एक जटिल प्रक्रिया है - डेवलपर्स अपना समय कैसे व्यतीत करते हैं इसकी पूरी तस्वीर प्राप्त करना कठिन है। उत्पादकता मापने का एक सामान्य तरीका DORA या SPACE जैसे सिस्टम मेट्रिक्स का विश्लेषण करना है। उद्योग मानकों की तुलना में टीम की उत्पादकता को समझने के लिए ये बेहद उपयोगी मीट्रिक हो सकते हैं। उनमें से प्रत्येक मेट्रिक्स में गोता लगाने से यह भी जानकारी मिल सकती है कि टीम को धीमा करने वाला क्या कारण है।

लेकिन कभी-कभी, समय की "छिपी हुई जेब" भी होती है जो डेवलपर्स अपने पूरे दिन खर्च करते हैं जिसे उत्पादकता पर प्रभाव डालने वाला नहीं माना जा सकता है। हालाँकि, जब हम उन चीज़ों को जोड़ना शुरू करते हैं, तो संख्याएँ चिंताजनक हो सकती हैं।

उदाहरण के लिए, इस बात पर विचार करें कि एक डेवलपर एक परतदार परीक्षण को डिबग करने में कितना समय व्यतीत करता है, यह पता लगाने में कि क्या यह उनके परिवर्तन के कारण विफल हुआ है या नहीं। या किसी डेवलपर द्वारा बिताया गया समय जो मेनलाइन बिल्ड विफलता को हल करने का प्रयास कर रहा है।

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

कैलकुलेटर इस बात पर ध्यान केंद्रित करता है कि डेवलपर वर्कफ़्लो में निर्माण और परीक्षण विफलताओं के कारण आपका और आपकी टीम का कितना समय बर्बाद होता है।

यदि आप इसकी तुलना DORA मेट्रिक्स से करते हैं, तो परिवर्तनों के लिए लीड समय निर्माण और परीक्षण अस्थिरता से काफी प्रभावित होता है। इस कैलकुलेटर का उपयोग करके उस प्रभाव का आकलन किया जा सकता है।

यह काम किस प्रकार करता है

हम आपसे आपकी GitHub गतिविधियों और आप GitHub शाखाओं का उपयोग कैसे करते हैं, उसके आधार पर डेटा इनपुट करने के लिए कहते हैं। नीचे दी गई वास्तविक गणनाओं को समझाने के लिए, आइए उनमें से प्रत्येक को चर निर्दिष्ट करें:

एम - पीआर प्रति दिन विलय हो गया

एक्स - एक सप्ताह में मेनलाइन विफलता

टी - औसत सीआई समय

एफ - परतदारता कारक %

इन इनपुट के आधार पर, हम अनुमान लगाते हैं कि आपकी इंजीनियरिंग टीम बिल्ड विफलताओं के प्रबंधन और परतदार परीक्षणों से निपटने में साप्ताहिक कितना समय बर्बाद करती है। आइए एक-एक करके परिणामों पर गौर करें।

ठीक करने में घंटों बर्बाद हुए

यह गणना करता है कि मेनलाइन बिल्ड विफलता का पता चलने पर पहचानने, ट्राइएज करने, ठीक करने और बिल्ड को दोबारा पास कराने में कितने घंटे बर्बाद हुए। आमतौर पर, एक बड़ी टीम में, कोई व्यक्ति टूटे हुए मेनलाइन निर्माण को नोटिस करेगा और रिपोर्ट करेगा।

हम मानते हैं कि एक मेनलाइन बिल्ड विफलता में डिबग और फिक्स करने के लिए औसतन 1-3 डेवलपर्स शामिल होते हैं। यदि हम समस्या की रिपोर्ट करने और उसे ठीक करने में लगने वाले समय के लिए औसतन एक घंटे का समय मानते हैं, तो हम समस्या को ट्रैक करने, जांच करने और हल करने में (2*T + 1) घंटे खर्च कर रहे हैं।

इसका मतलब है कि यदि सप्ताह में एक्स विफलताएं होती हैं, तो हम हर दिन मेनलाइन बिल्ड विफलताओं से लड़ने के लिए डेवलपर समय में (( 2 डेव * एक्स/5 * (2*टी + 1)) घंटे खर्च कर रहे हैं।

मर्ज संबंधी विवादों को सुलझाने में घंटों बर्बाद हुए

रोलबैक और मर्ज विरोध आगे समस्याएँ पैदा कर सकते हैं। यह मानते हुए कि लगभग 2% पीआर हैं जिनमें टूटे हुए निर्माण समय ((2*टी + 1) * एक्स/5) की विंडो के दौरान मर्ज विरोध होता है, और एम/8 पीआर हर घंटे आते हैं, हम ((2*) खर्च करेंगे टी + 1) * एक्स/5) * 0.02 * इन संघर्षों को सुलझाने में एम/8 बर्बाद हुआ।

टूटे हुए भवनों के कारण साप्ताहिक सीआई विफलताएँ

यदि टीम अपनी फीचर शाखाओं को आधार बनाने के लिए गोल्डन ब्रांच का उपयोग नहीं कर रही है, तो वे संभवतः एक असफल मेनलाइन शाखा के शीर्ष पर फीचर शाखाएं बनाएंगे। चूँकि किसी भी समय बनाए गए पीआर की संख्या मेनलाइन के आधार पर फीचर शाखाओं की औसत संख्या के समान होगी, इससे हर दिन होने वाली सीआई विफलताओं की संख्या (2 * टी + 1 घंटा) * एक्स / 5 * एम / 8 होगी। .

सीआई को हल करने का समय

लगभग पंद्रह मिनट के संदर्भ के साथ प्रत्येक निर्माण विफलता में हैंडल को स्विच करना, यानी (2 * टी + 1 घंटा) * एक्स / 5 * एम / 8 * सीआई विफलताओं के साथ हर दिन 0.25 घंटे का डेवलपर समय बर्बाद होता है।

परतदार परीक्षणों को दोबारा चलाने में समय व्यतीत हुआ।

इसी तरह, परतदार परीक्षणों के साथ, यह जांचने के लिए संदर्भ स्विचिंग समय की आवश्यकता होती है कि परीक्षण परतदार था या वास्तविक, और परीक्षणों को दोबारा चलाने में प्रति रन औसतन पंद्रह मिनट लगते हैं। परतदारता कारक के आधार पर, डेवलपर्स हर दिन (0.25 * एम * एफ / 100) घंटे बर्बाद करेंगे।

दक्षता में सुधार

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

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

यहाँ भी प्रकाशित किया गया है.