तैनाती के लिए कौन जिम्मेदार है?

Question

मैं एक विनिर्माण कंपनी के लिए एक इन-हाउस डेवलपर के रूप में काम करता हूं। हम विनिर्माण प्रक्रिया के लिए सॉफ्टवेयर बनाते हैं, वास्तव में सॉफ्टवेयर को नियंत्रित नहीं करते हैं, प्रक्रिया प्रवाह की तरह अधिक।

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

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

अन्य लोगों के अनुभव क्या हैं? क्या देव टीम तैनाती करनी चाहिए या क्या हमें पूरा सॉफ़्टवेयर पीओ में सौंपना चाहिए और समर्थन प्रदान करना चाहिए?

महान प्रतिक्रियाओं का एक बहुत, धन्यवाद संक्षेप। सवाल ऐसा प्रतीत हो सकता है कि मैं काम या ज़िम्मेदारी से बाहर निकलने की कोशिश कर रहा हूं, शायद मैं थोड़ा हूं; ओ) मुझे अन्य लोगों की प्रक्रियाओं में अधिक दिलचस्पी है। जिस समस्या का हम सामना करते हैं वह यह है कि यदि देव टीम सॉफ़्टवेयर को तैनात करती है तो हम सॉफ़्टवेयर के लिए उत्पादन के लिए 24/7 समर्थन प्रदान करते हैं। कोई जांच नहीं, सिवाय इसके कि हम केवल दो ही हैं। इसलिए, हमें हर समय समर्थन प्रदान करने के बजाए विकासशील सॉफ्टवेयर पर वापस जाने की इजाजत देने के लिए मैंने सोचा कि यह "आईटी" टीम को विकास प्रक्रिया में शामिल करने में सहायक हो सकती है। उम्मीद है कि यह 'खरीद-इन' प्राप्त करेगा और फिर उन्हें तैनात करने और प्रथम स्तर का समर्थन प्रदान करने की अनुमति देगा। हमारे पास मेक्सिको में एक संयंत्र भी है और देव टीम के पास जाना और तैनाती करना मुश्किल है, डेवलपर्स से मार्गदर्शन/सलाह के साथ स्थानीय समर्थन के लिए यह अधिक समझ में आता है।

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

Answer 1

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

Answer 2

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

Answer 3

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

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

बेशक, असली दुनिया में, यह हमेशा कर्मियों के मुद्दों के कारण नहीं होता है, लेकिन यह मेरा आदर्श होगा।

Answer 4

मेरे लिए काफी सरल लगता है - यदि नहीं, तो कौन? स्क्रम का उपयोग शुरू करने से पहले क्या वास्तविक तैनाती की जिम्मेदारी किसी अन्य टीम को गिर जाएगी? यदि नहीं, तो मुझे नहीं लगता कि क्यों स्क्रम इसे बदल देगा।

Answer 5

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

यदि आपको यह पसंद नहीं है, तो इसे प्रबंधन के साथ लाएं, लेकिन अलग-अलग बताए जाने तक काम करें।

Answer 6

1. सॉफ्टवेयर प्रक्रिया पूरी नहीं होने तक काम कर रहे सॉफ्टवेयर उपयोगकर्ताओं को इसकी आवश्यकता है कि के हाथ में है - अन्यथा यह सिर्फ "shelfware"

2. है अगर वहाँ कोई और नहीं तैनाती के लिए जिम्मेदार होने की है और कॉन्फ़िगरेशन प्रबंधन, तो आप इसे हैं ;-)

Answer 7

मैं कई उत्पादों पर ज़िम्मेदारी के साथ एक dev mgr हूं। मेरे पास मेरी देव टीम तैनाती कलाकृतियों का निर्माण करती हैं, जैसे कि .war फाइलें, जिन्हें बस इसके प्रबंधक इंटरफ़ेस या वेब सेवा API का उपयोग करके टॉमकैट वेब सर्वर पर तैनात किया जा सकता है। ऐप के लिए कॉन्फ़िगरेशन सभी सेट और स्वयं को .war फ़ाइल में निहित है। इसलिए यह केवल उस व्यक्ति को लेने के लिए तैनाती करने वाले व्यक्ति के लिए सीधा है और बोलने के लिए "इसे छोड़ दें"।

यदि हमें तैनाती की आसानी का स्तर नहीं मिलता है, जहां विकास टीम से तैनाती पूरी तरह से तय की जा सकती है, तो मैं देखता हूं कि देव टीम के हिस्से पर पर्याप्त रूप से उनकी नौकरी करने में विफलता के रूप में।

कई ग्राहक साइटों को दिए गए उत्पाद को जारी करने के लिए तैनाती करने वाला व्यक्ति - यह मेरे लिए डेवलपर्स को करने के लिए एक उत्पादक गतिविधि नहीं है - उनके पास उनके विशेषज्ञता विशेषज्ञता के रूप में डिजाइन और निर्माण करने के लिए उत्पाद हैं।

हमारे संगठन में तैनाती की ज़िम्मेदारी भी पहले स्तरीय उत्पादन समर्थन जिम्मेदारी के साथ ओवरलैप करती है।

हम कुछ स्क्रम पद्धति का अभ्यास करते हैं लेकिन मैंने कभी भी इस समस्या को सॉफ़्टवेयर विकास प्रक्रिया पद्धति से बंधे हुए नहीं देखा है, प्रति से।

Answer 8

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

मैं पहली टिप्पणी से सहमत हूं - SCRUM के पास इसके साथ कुछ लेना देना नहीं है। असल में मुझे लगता है कि आपके लिए तैनाती करना बेहतर होगा क्योंकि आपको पहले हाथ पता चलेगा कि चीजें कितनी अच्छी तरह से काम कर रही हैं और उन उपयोगकर्ताओं से प्रतिक्रिया प्राप्त करने के लिए वहां रहें।

Answer 9

सॉफ़्टवेयर काम नहीं कर रहा है या सिस्टम की मृत्यु हो जाने पर 3 बजे कॉल कौन करता है? यदि यह देव टीम है तो हर तरह से तैनाती के मालिक होने की उम्मीद है (क्योंकि आप उत्पादन के मालिक हैं)।

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

यदि आपके उत्पादन नियंत्रण उन्हें कसने से कम कर रहे हैं। "दृश्यमान ओपीएस" जैसी पुस्तक उचित हाथों में नियंत्रण के उचित स्तर के तहत चीजें प्राप्त करने के लिए एक महान गाइड है।