तकनीकी ऋण पर डेवलपर्स के समय को कैसे रोकें

तुम्हें पता है कि वह क्या है। स्प्रिंट में आपकी ज़रूरत की हर चीज़ को दिखाना पहले से ही बहुत मुश्किल है, लेकिन तकनीकी ऋण वापस करने के लिए आपको अभी भी डेवलपर्स के 10-20% कहीं और खोजने की आवश्यकता है। यदि आपने कभी इसके लिए समय बनाने की आवश्यकता का बचाव किया है, तो आप जानते हैं कि यह महाकाव्य अनुपात के धर्मयुद्ध जैसा है।

लेकिन आप ऐसा कर सकते हैं, और इस गाइड में हम यह पता लगाएंगे कि वास्तव में कैसे।

मैंने बहुत सी बैठकें देखी हैं, जहाँ पर इस प्रश्न को बहुत समय व्यतीत किया गया है। तर्क आम तौर पर आधारहीन होते हैं, और भावनाएं उच्च चल सकती हैं - और कमरे में सबसे तेज आवाज के साथ जीत होती है।

दुविधा यह है: यदि व्यवसाय का दबाव ऊपरी हाथ हो जाता है, तो आपकी कंपनी बहुत अधिक तकनीकी ऋण प्राप्त करने का जोखिम उठाती है - और फिर डेवलपर्स अपनी प्रेरणा खो देते हैं, कंपनी तकनीकी दिवालियापन की ओर आती है, और आपके प्रतियोगी आपको हरा देते हैं। यदि आप डेवलपर्स के दबाव को दूर करते हैं, तो कंपनी बहुत कम तकनीकी ऋण लेने का जोखिम उठाती है, और फिर आपके प्रतियोगी उत्पादों और सुविधाओं को तेजी से प्रदान करने, बाजार पर कब्जा करने और बाद में अपने तकनीकी ऋण को वापस करने के लिए प्राप्त लाभ का उपयोग करने में सक्षम होंगे। आप फिर से हार रहे हैं।

सामान्य ज्ञान का सुझाव है कि विकास टीमों को कोड आधार की एक सहज समझ विकसित करनी चाहिए, जहां तकनीकी ऋण, साथ ही कंपनी के लिए इसके परिणाम भी होते हैं, जिससे संगठन के भीतर आत्मविश्वास पैदा होता है। यदि आपका मुख्य वास्तुकार और संस्थापक कहता है कि आपको अभी रिफैक्टरिंग करने की आवश्यकता है, तो आप (आमतौर पर) बस इसे लेते हैं और करते हैं।

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

खैर, यह प्रक्रिया में कुछ विज्ञान जोड़ने का समय है।

तकनीकी ऋण के लिए साइट और बजट की समान विश्वसनीयता क्या है

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

सबसे अच्छी साइट विश्वसनीयता प्रबंधन टीमें प्रबंधित तकनीकी ऋण के संदर्भ में अपनी साइट विश्वसनीयता बजट के साथ काम करती हैं। साइट विश्वसनीयता Google द्वारा प्रचलित एक अवधारणा है; वह सॉफ्टवेयर को "अप और रनिंग" स्थिति में रखने के लिए ज़िम्मेदार है, लेकिन, दिलचस्प बात यह है कि Google जैसी कंपनियां 100% तक का समय लाने का लक्ष्य नहीं रखती हैं। कारण यह है कि 99.99% का एक अपटाइम Google उत्पादों के लिए वास्तविक उपयोगकर्ताओं के लिए असाधारण रूप से विश्वसनीय होने के लिए पर्याप्त है। और यह अंतिम 0.01% हासिल करना बहुत मुश्किल है, और इसके लिए लड़ने का कोई मतलब नहीं है।

इसलिए, यदि यह प्रति वर्ष कुल 52 मिनट डाउनटाइम देता है, तो Google इस आंकड़े को जितना संभव हो उतना करीब लाने की कोशिश करेगा; लेकिन सब कुछ जो एक वर्ष में 52 मिनट से कम है, अतिरिक्त जोखिम उठाने और अपने ग्राहकों को जल्दी से कोई भी आशाजनक सुविधा प्रदान करने का एक अवसर है।

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

यदि आपका तकनीकी ऋण लाल क्षेत्र में है, तो आपको इसे आंशिक रूप से चुकाने की आवश्यकता है। यदि वह ग्रीन ज़ोन में है, तो आप अधिक जोखिम और अधिक ऋण ले सकते हैं। आपका लक्ष्य ऋण की राशि को यथासंभव आदर्श के करीब रखना है। दूसरे शब्दों में, यदि आप ग्राफ़ के लाल भाग के चरम पर हैं, तो तकनीकी ऋण का आदर्श बजट A ⇒ B. है। यदि आप ग्राफ़ के हरे भाग के अवसाद में हैं, तो आदर्श बजट C ⇒ B. केवल इतना याद रखें कि A ⇒ C तकनीकी ऋण के लिए बहुत बड़ा बजट है। ।

चूंकि तकनीकी ऋण को मापा जा सकता है (हमने एक अन्य लेख में इसके बारे में लिखा है), यह अब केवल एक अवधारणा नहीं है - यह पूरी तरह से व्यावहारिक जरूरतों को पूरा करता है।

अपने तकनीकी ऋण बजट का अधिकतम लाभ कैसे प्राप्त करें

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

एंजेलिसिस्ट में दूरस्थ टीम समन्वयक एंड्रियास क्लिंगर , ने अपने लेख में यह अच्छी तरह से सेट किया है कि इनहेरिटेड कोड के बड़े मामलों को फिर से भरना।

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

सीधे शब्दों में कहें, तो आपका लक्ष्य यह पता लगाना है कि दो चीजें कहां ओवरलैप होती हैं: आप वर्तमान स्प्रिंट, महीने या तिमाही में क्या काम करेंगे, और आपके कोड आधार के उन हिस्सों में जो तकनीकी ऋण हैं। इस चौराहे के क्षेत्र में ऋण का भुगतान करें, लेकिन परे नहीं।

और यह यहाँ है कि विज्ञान कला को पूरक करता है। आप उन क्षेत्रों की पहचान करने के लिए डेटा का उपयोग कर सकते हैं जहां आपको निकट भविष्य में तकनीकी ऋण का भुगतान करने की आवश्यकता है:

• अपने कोड आधार में कमजोर स्वामित्व वाली फ़ाइलों को हाइलाइट करें, क्योंकि कोड स्वामित्व आपके कोड आधार की भलाई का एक प्रमुख संकेतक है। इसके बारे में हमारे लेख में "कोड आधार की भलाई के लिए आवश्यक कॉर्पोरेट संस्कृति की एक विशेषता" ।
• इन फ़ाइलों के लिए सामंजस्य और युग्मन को मापें और सूची में केवल कमजोर स्वामित्व, कम कनेक्टिविटी और उच्च गियर वाली फ़ाइलों को छोड़ दें। आप हमारे लेख "तकनीकी ऋण को मापने के लिए उद्योग के नेता अध्ययन का उपयोग" इन संकेतकों में से प्रत्येक के बारे में अधिक जान सकते हैं।
• समस्याग्रस्त फ़ाइलों का सबसेट निर्धारित करने के लिए इन फ़ाइलों में से प्रत्येक के लिए आवर्ती गतिविधि (मंथन) की गणना करें। माइक्रोसॉफ्ट के एक अध्ययन के अनुसार, सक्रिय रूप से बदलती फाइलें सिस्टम की कुल फाइलों का केवल 2-8% हिस्सा बनाती हैं, लेकिन वे सभी परिवर्तनों का 20–40% खाते हैं, और वे सभी कीड़े के 60-90% के लिए जिम्मेदार हैं।
• अपने त्रैमासिक योजनाओं के लिए फ़ाइलों की परिणामी सूची से संबंधित हैं। क्या आपकी योजनाओं में सूचीबद्ध कोई भी सुविधा आपको उन समस्या फ़ाइलों के सबसेट पर काम करने की आवश्यकता है जिन्हें आपने उल्लिखित किया है? यदि हाँ, इन फ़ाइलों को फिर से तैयार करने से संबंधित लक्ष्य निर्धारित करें, आवश्यक मात्रा में काम का मूल्यांकन करें और विशिष्ट डेवलपर्स को कार्य सौंपें, अधिमानतः जो संबंधित फाइलें हैं। इस योजना को अपनी योजनाओं में शामिल करें।

आरंभ करने के लिए, हमारे मुफ़्त VSCode एक्सटेंशन पर एक नज़र डालें - यह आपको लगातार निगरानी रखने और सबसे जरूरी तकनीकी ऋणों का भुगतान करने में मदद करेगा।

तकनीकी ऋण के साथ दीर्घकालिक संबंध में प्रवेश करें

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

आइए फिर से स्पष्ट करें: यह एक चांदी की गोली नहीं है जिसे वर्ष में एक बार इस्तेमाल किया जा सकता है और फिर भुला दिया जा सकता है। आपको अपने तकनीकी कर्तव्य को बेहतर तरीके से जानना होगा। प्रत्येक स्प्रिंट के सभी संकेतकों पर अपनी प्रगति को ट्रैक करें और तकनीकी भलाई प्राप्त करने के लिए पूरी प्रक्रिया में सुधार जारी रखें।

हमने ऐसा करने के कई तरीकों के बारे में लिखा है, इसलिए सही प्रेरणा बनाने के लिए, स्वामित्व के आधार पर एक विकास संस्कृति की खेती करने और डेवलपर्स को सम्मानित करने के बारे में पढ़ें जो तकनीकी ऋण वापस करते हैं ।