जो जटिल परियोजनाओं के विकास की गुणवत्ता, या गुणवत्ता गेट्स पद्धति के लिए फुर्तीले में जिम्मेदार होंगे

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

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



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

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

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

गुणवत्ता द्वार

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

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



हम सभी टीमों के साथ कई जांच, गुणवत्ता द्वार पर सहमत हुए, जिन्हें उन्हें जीवन चक्र के चरणों के पारित होने के दौरान पारित करना चाहिए।

कोडिंग

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

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

वितरण का निर्माण

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

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

स्मोक टेस्ट

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

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

गुणवत्ता द्वार एक ढांचे के रूप में

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

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

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


तृतीय-पक्ष पाइपलाइन का एक उदाहरण जिसमें गुणवत्ता द्वार शामिल हैं

गुणवत्ता द्वार के कार्यान्वयन के परिणाम

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

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

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

आपकी राय

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

निकोले वोरोब्योव-सरमाटोव, सर्बैंक-टेक्नोलॉजी, सेर्बवर्क्स
लेख तैयार करने में मदद के लिए मिखाइल बिशन को धन्यवाद!