एक आईटी उत्पाद को बेहतर बनाने के लिए सभी त्रुटियों को ठीक करने की आवश्यकता क्यों नहीं है

यह सामग्री हमारे साथी इक्वियो ने तैयार की है।



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

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

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

सात नन्हें

नई रिलीज की घोषणा के लिए एक प्रसिद्ध मजाक है, "अनुकूलित अनुप्रयोग प्रदर्शन, बग फिक्स, नए जोड़े गए।" वास्तव में, कीड़े को ठीक करना और नए को जोड़ना एक शाश्वत प्रक्रिया है, पुराने कीड़े तय हो गए हैं, लेकिन कोई भी नया कम नहीं होता है।

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

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

दृष्टि से बाहर, बैकलॉग बाहर

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

इसका सार इस प्रकार है। जब परीक्षक या उपयोगकर्ता उत्पाद में कोई बग ढूंढते हैं और इसके बारे में डेवलपर्स को सूचित करते हैं, तो बाद वाला तय करता है कि यह बग ठीक होगा या यह उत्पाद के प्रदर्शन को प्रभावित नहीं करता है, और इसलिए इसके सुधार में देरी हो सकती है या पूरी तरह से बाहर रखा जा सकता है। बैकलॉग (कार्य सूची) से। इस बग को W't Fix दर्जा दिया गया है, जिसके बाद यह डेवलपर्स के विज़न फ़ील्ड से हमेशा के लिए गायब हो जाता है। कुछ मामलों में, इस स्थिति वाले कीड़े को बैकलॉग के बहुत अंत में रखा जाता है। इसका मतलब यह है कि डेवलपर्स "केवल अपने हाथों को प्राप्त करेंगे" उन्हें केवल ठीक करने के लिए जब अन्य सभी कार्यों को हल किया जाता है।

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

बग विशेषज्ञ

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

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

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

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

चयन मानदंड

ऐसे "मामूली" बग किसी भी डेवलपर के उत्पादों में हैं।

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

बटन गलत रंग में थोड़ा सा है, इंटरफ़ेस तत्व दो पिक्सल में बाईं ओर स्थित है जो आवश्यक है - ये सभी त्रुटियां हैं जो प्रयोज्य या आवेदन के प्रदर्शन को प्रभावित नहीं करती हैं। इसलिए, उन्हें संभावित रूप से W't Fix करने के लिए जिम्मेदार ठहराया जा सकता है।

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

सामूहिक मन

जीरो बग पॉलिसी अक्सर सर्विस लेवल एग्रीमेंट (SLA) से जुड़ी होती है। आमतौर पर, डेवलपर्स के पास तकनीकी सहायता की कई लाइनें होती हैं।

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

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

यदि इन सभी कारकों को ध्यान में रखते हुए विवादास्पद स्थिति उत्पन्न होती है, तो अंतिम शब्द समर्थन की दूसरी पंक्ति के ठीक पीछे होगा और निश्चित रूप से, उत्पाद स्वामी।

संतुष्ट का अर्थ है उत्पादक

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

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

वह सब है। कंपनी "इक्वियो" के बारे में अधिक जानकारी उनकी आधिकारिक वेबसाइट पर पाई जा सकती है।

और ओटस वेबसाइट पर आप हमारे पाठ्यक्रमों के साथ खुद को परिचित कर सकते हैं और उन मुफ्त वेबिनारों में भाग ले सकते हैं जो आपकी रुचि रखते हैं।