👸 ✌🏾 🈂️ आंतरिक दहन इंजन पर सितारे। तकनीकी ऋण के साथ लड़ाई से बचे 🀄️ ⏏️ 👨🏽‍🎤

तकनीकी ऋण से लड़ाई कैसे बची? यदि आपके पास एक गंभीर चरण की विरासत है तो क्या करें? लेख में, तीन मामलों के उदाहरण का उपयोग करते हुए, मैं यह पता लगाने का प्रस्ताव करता हूं कि तकनीकी ऋण के साथ काम करने की प्रक्रिया का निर्माण कैसे किया जाए और इसके लिए कौन से इंजीनियरिंग का उपयोग किया जाए।

मेरा नाम डेनिस है, मैं व्रीके में बैकेंड टीम लीड हूं। मैं अपनी टीम में डिलीवरी के लिए और कई टीमों में डेवलपर्स के विकास के लिए जिम्मेदार हूं। ऐसा हुआ कि लगभग मेरा सारा अनुभव फिनटेक में काम कर रहा है। मैंने दो बड़े बैंकों के लिए काम किया है, और अब मैं व्रीके में काम करता हूं।

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

Wrike एक SaaS टीम सहयोग समाधान है जिसे हम अपने ग्राहकों को बेचते हैं। हम विकास को व्यवस्थित करने के लिए Wrike का उपयोग करके Wrike बनाते हैं।

व्रीक ने तीस स्क्रम टीमों का विकास किया। यह सेवा 24/7 उपलब्ध है, इसलिए हम जो निर्णय लेते हैं वह विश्वसनीय होना चाहिए। अगर कुछ गलत होता है, तो यह लगभग सभी टीमों के काम को प्रभावित करेगा।

स्टारशिप क्यों?

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

तकनीकी ऋण क्या है?

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

लेख में, तकनीकी ऋण द्वारा मैं उन विशेषताओं, समाधानों या दृष्टिकोणों को समझूंगा जो आगे के उत्पाद विकास में हस्तक्षेप करते हैं। ऊपर वर्णित सभी समस्याएं तकनीकी ऋण का परिणाम हैं। ये विशिष्ट कारण हैं: वह क्यों है और आपको उसके साथ काम करने की आवश्यकता क्यों है।

तकनीकी ऋण एल्गोरिथम

तकनीकी ऋण के साथ प्रभावी ढंग से काम करने के लिए, आपको तीन बुनियादी प्रश्न पूछने होंगे।

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

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

अब देखते हैं कि एक उदाहरण के रूप में कई मामलों का उपयोग करके वास्तविकता में एल्गोरिदम कैसे काम करता है।

पहला मामला

एक एप्लिकेशन है जो ग्राहकों से ऑर्डर के साथ काम करता है - ऑर्डर मैनेजमेंट सिस्टम। आवेदन बहुत पहले, 2010 में लिखा गया था, और उस समय की नवीनतम तकनीकों पर बनाया गया है। आवेदन पिछले 9 वर्षों से उत्पादन में सफलतापूर्वक संचालित हो रहा है, लेकिन आज व्यवसाय समझता है कि नए बाजारों पर कब्जा करना और सिस्टम को और विकसित करना आवश्यक है। उसी समय, डेटा को सहेजना और सिस्टम में नई कार्यक्षमता बढ़ाना महत्वपूर्ण है।

यह पता चला है कि ऐसी तकनीकें हैं जो लंबे समय से मृत हैं, लेकिन ऐसे डेटा भी हैं जो खो नहीं सकते हैं। पुरानी तकनीकों का उपयोग करके सभी सुविधाओं को एक आवेदन में लागू नहीं किया जा सकता है। इसलिए, स्थिति, पूरी तरह से ईमानदार होने के लिए, कुछ इस तरह दिखता है:

यहाँ समस्या पुराने ढाँचों में नहीं है, लेकिन उस स्थिति में जो हमारे पास है: आवेदन समर्थित नहीं है, एक दशक पहले के ढाँचों के लिए डेवलपर्स को ढूंढना लगभग असंभव है। हमें इसके बारे में कुछ करना होगा।

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

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

दूसरा मामला

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

हम डेटा प्रारूप और इस डेटा को डेटाबेस में प्राप्त करने के तरीके से खुश नहीं हैं। लेकिन आपको इसे सावधानी से ठीक करने की आवश्यकता है, कई निर्भरताएं हैं।

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

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

तीसरा मामला

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

दो मजेदार विरासत तथ्य:

यह निश्चित रूप से काम करता है।
कोई नहीं जानता कि यह कैसे काम करता है। यही कारण है कि विरासत।

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

यहां कई दृष्टिकोण हैं जो मदद कर सकते हैं, खासकर यदि आपदा का पैमाना कोड की मात्रा में काफी बड़ा है:

. Java , , , . , , , , ;
. , , , . , , . , ;
-.

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

यहां विरासत की मात्रा कम कर दी गई थी, क्योंकि इस क्षण हम पहले से ही आवेदन में जो चाहते हैं उसे दर्ज करना शुरू कर रहे हैं।

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

अक्सर ऐसा होता है कि व्यावसायिक उद्देश्यों के लिए एक बार बनाया गया समाधान 100% पर उपयोग किया जाता था, और आज यह केवल 30% और 70% पर वर्तमान लक्ष्यों के साथ प्रतिच्छेद करता है - नहीं। आज की वास्तविकताओं में, ये 70% महत्वपूर्ण नहीं हैं। आपके द्वारा लिखे गए परीक्षण 30% पर प्रकाश डालेंगे। कोटेड टेस्ट चलाने के बाद, आप समझ सकते हैं कि किस कोड का उपयोग नहीं किया गया है, इसे हटाएं और अपने समाधान की कनेक्टिविटी और जटिलता को कम करें।

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

नया समाधान सरल, समझने योग्य होना चाहिए और विशेष रूप से आज और विशिष्ट तात्कालिक लक्ष्यों के लिए आपकी समस्या को हल करना चाहिए। अधिकता में जाने की आवश्यकता नहीं है, क्योंकि हम आज के अंतिम लक्ष्य को बंद कर रहे हैं।

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

काम को कैसे व्यवस्थित करें

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

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

यहाँ मैं इस अवधारणा को कुछ भिन्न रूप में उपयोग करता हूँ। डेऑन की परिभाषा से, मैं इस बात का विवरण समझता हूं कि किसी विशेष पुनरावृत्ति के उत्पादन में जाने पर अनुप्रयोग में क्या परिवर्तन होगा।

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

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

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

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

आप इस तरह के बदलावों से खुद को कई तरह से बचा सकते हैं:

— . , , - , .
, . git hook, git commit git push. unit test, , - , , , : .

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

अंतिम मालिक के माध्यम से कैसे प्राप्त करें

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

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

आप एक समय कोटा पर सहमत हो सकते हैं। उदाहरण के लिए, डेवलपर्स का 10% समय तकनीकी ऋण पर काम करने के लिए समर्पित होगा। ऐसा कोटा तकनीकी ऋण से छुटकारा पाने की अनुमति नहीं देगा, लेकिन इसे प्रफुल्लित नहीं होने देगा।

जाहिर है, तकनीकी ऋण के बारे में बात करना मुश्किल है, अगर यह स्पष्ट नहीं है कि बातचीत वास्तव में क्या है। इसलिए, आपकी टीम में एक तकनीकी बैकलॉग होना चाहिए, जिसमें ऐसे कार्य हैं जिनका मूल्यांकन और विकासकर्ताओं द्वारा प्राथमिकता दी गई है।

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

शायद लक्ष्य तुरंत संयोग नहीं करेंगे, लेकिन एक चौथाई या एक साल में भी। लेकिन यह आपको समझने की अनुमति देगा कि व्यवसाय कब परिवर्तन के लिए तैयार होगा।

यदि आप लक्ष्यों को सिंक्रनाइज़ करने का प्रबंधन करते हैं, तो आपको सभी बोनस प्राप्त होंगे: प्राथमिकता, संसाधन और सभी काम का संगठन। उत्पाद स्वामी आपको ऐसा करने में मदद करेगा। मुख्य कार्य उसके साथ सहमत होना है।

संपूर्ण

जब हम उत्पाद के प्रमुख क्षेत्रों में परिवर्तन के बारे में बात करते हैं, तो एक सरल चार-चरण एल्गोरिथ्म जटिल हो जाता है:

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

इस एल्गोरिथ्म और प्रक्रिया को व्यवस्थित करने के लिए मेरी सिफारिशों का उपयोग करते हुए, आप किसी भी तकनीकी ऋण के साथ काम कर सकते हैं।

लेख बैठक में मेरे भाषण पर आधारित है, आप वीडियो रिपोर्ट देख सकते हैं ।

आंतरिक दहन इंजन पर सितारे। तकनीकी ऋण के साथ लड़ाई से बचे