पहला संस्करण जारी करें!

परिचय

अच्छी तरह से स्थापित और पूर्ण प्रक्रियाएं हमारे लिए नहीं हैं! यह उबाऊ है जब सब कुछ पहले से ही सेट किया गया है और घड़ी की तरह काम करता है, लेकिन यह मांग की जानी चाहिए। और उसके बाद, किए गए काम पर खुशी मनाएं और एक बार फिर से जांच लें कि सब कुछ कैसे अच्छा है ...

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

इस संबंध में, अक्सर ऐसी परिस्थितियां होती हैं जब ग्राहक को न्यूनतम परीक्षण के बाद एक काफी कच्चे "विकास" कोड के साथ आपूर्ति की जाती है। इससे कई परेशानियों का सामना करना पड़ता है।

N.N.U

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

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

पोस्ट 1: मुख्य विकास शाखा में कोड अस्थिर है

इस मामले में, ग्राहक पर कोड को अपडेट करने का दृष्टिकोण केवल समस्याएं लाएगा। संस्करण में व्यक्त कोड टुकड़ा को ठीक करना और ग्राहक से संस्करण के साथ केवल कोड स्थापित करना आवश्यक है।

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

कई परियोजनाओं में गुणवत्ता नियंत्रण और परीक्षण विभाग नहीं होता है, अक्सर कोई परीक्षण नहीं होता है। सभी विकास मुख्य शाखा में किए जाते हैं। यहाँ इस तरह की परियोजनाओं के लिए 1 पोस्ट किया गया है।

संस्करण जारी करें

आपका कोड मुश्किल से संकलित है, कई त्रुटियां हैं, घातक और बहुत नहीं, ग्राहक सिस्टम के प्रकार और व्यवहार से ग्रे चालू करना शुरू कर देता है? संस्करण जारी करें!

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

प्रेरणा

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

आकर्षण आते हैं

संस्करण के विमोचन के सकारात्मक पहलुओं में, हम भेद कर सकते हैं:

• उत्पाद के "संदर्भ बिंदु" का निर्माण;
• ग्राहक को नई कार्यक्षमता प्राप्त करने के लिए विनियमित;
• उत्पाद की स्थिरता और गुणवत्ता में सुधार;
• टीम की सामान्य लय;
• व्यापक उत्पाद विकास योजना के अवसर;
• विकास की "नियंत्रणशीलता";
• अधिक नए लोगों को पेश किए बिना आसानी से त्रुटियों को ठीक करें।

विपक्ष

परियोजना के शुरुआती चरणों में पहला संस्करण जारी करने के नुकसान भी हैं:

• ग्राहक द्वारा "ट्रेसर शूटिंग" । हर कोई इसके लिए तैयार नहीं है;
• रिलीज संस्करण के लिए नया काम;
• पुनरावृत्ति के लिए ग्राहक को नई कार्यक्षमता का वितरण धीमा करना।

मैं इस संभावना को बाहर नहीं करता हूं कि प्रत्येक पाठक पहले क्रूड संस्करण के रिलीज के कुछ प्लसस और मिन्यूज़ का हवाला दे सकेगा।

निष्कर्ष

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

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

एनएनयू - शून्य प्रारंभिक शर्तें।