एक सप्ताह का रिलीज़ चक्र: मैं इसे कैसे संभव बनाता हूं?

Question

मेरी कंपनी (3-वर्ष पुराने वेब उद्योग स्टार्टअप) में, हमें उत्पाद टीम के साथ लगातार यह कहते हुए समस्या होती है कि "आआआह यह अब एक संकट पैच है!" (हर कोई नहीं करता है?)

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

13 डेवलपर्स और 6 स्थानीय / 9 अपतटीय परीक्षक हैं; सिद्धांत यह है कि केवल 4 डेवलपर्स (और सभी परीक्षक) समान संख्या में रिलीज पर काम करेंगे, जब तक कि काम का एक टुकड़ा नहीं आता है कि वास्तव में अन्य देवों में से एक से कुछ विशिष्ट विशेषज्ञता की आवश्यकता होती है। प्रत्येक चक्र में दो दिन के देव कार्य और दो दिन के क्यूए कार्य (प्लस 1 दिन का स्कूपिंग / ट्राइएज / ...) होगा।

मेरे प्रश्न हैं:

(ए) क्या किसी को रिलीज चक्र की लंबाई के साथ अनुभव है?

(ख) क्या किसी ने रिलीजिंग साइकल की इस लंबाई के बारे में भी सुना है?

(c) यदि (a) या (b), पृथ्वी पर आप इसे कैसे काम करते हैं? (बचने के लिए कोई भी नुकसान, आदि की सराहना की जाती है।)

(घ) यदि यह प्रयास विफल हो जाता है तो हम नुकसान को कैसे कम कर सकते हैं?

Comments

"संकट की नौकरी" से आपका क्या मतलब है?

— जादूगर

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

— अर्काटितो

Answer 1

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

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

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

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

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

Answer 2

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

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

"एक समय दृष्टिकोण पर 4" मेरे लिए एक स्पष्ट कट विजेता की तरह नहीं लगता है। इसका मतलब है कि निरंतर संदर्भ स्विचिंग, जिसका अर्थ है कम दक्षता।

याद रखें, यदि आप लगातार बदलाव करने की जल्दी कर रहे हैं, तो आप उन परिवर्तनों में गलतियाँ करने की अधिक संभावना रखते हैं, और जब आप ऐसा कर रहे होते हैं तो कुछ और तोड़ देते हैं।

Comments

अगर मैं @ वोंको के शानदार जवाब के लिए अपनी टिप्पणी जोड़ सकता हूं ... हमारी कंपनी ने ओपी के समान काम करने में कई साल बिताए। 6 या देवों से 16 तक बढ़ते हुए। लगभग 2 साल पहले, हमने एजाइल जाने का फैसला किया। हमने एक Sr. Dev w / Agile अनुभव को किराए पर लिया, 2 सप्ताह की पुनरावृत्तियों को स्विच किया, निरंतर एकीकरण को लागू किया, आदि ... हम अभी भी एक पाठ्यपुस्तक की दुकान से दूर हैं और यह समय-समय पर ऊबड़-खाबड़ है, लेकिन हमने वास्तव में संदर्भ में कटौती की है स्विचिंग, जो एक बड़ी जीत है।

— देवसोलो

Answer 3

सॉफ़्टवेयर उद्योग में एक सप्ताह से कम की रिलीज़ साइकिल निश्चित रूप से हासिल की गई है। वे तकनीक को निरंतर वितरण (जिसे निरंतर तैनाती भी कहा जाता है ) कहते हैं।

एक कंपनी है जो दिन में 50 बार रिलीज होती है। यह ब्लॉग पोस्ट बताता है कि वे इसे कैसे करते हैं ।

Answer 4

प्रबंधन ने कुछ समय यह सोचने में बिताया है कि इन "संकट नौकरियों" की आवृत्ति को कैसे कम किया जाए और इस समाधान के साथ आया है कि हम हर हफ्ते एक रिलीज होने जा रहे हैं।

लगता है कि आपके प्रबंधतंत्र विश्व विजेता हैं ... आपकी टीम में निवेश क्यों नहीं किया गया? आप देखेंगे कि समस्याएँ उन्हें दूर कर देंगी।

(ए) + (बी) आईएमएचओ, आपकी टीम के आकार के अनुसार यह दो सप्ताह अधिकतम होना चाहिए। एक सप्ताह एक आदमी शो या बहुत छोटी टीमों (जैसे 2 या 3) के लिए काम करेगा।

(c) + (d) लेकिन आपकी टीम या प्रोजेक्ट के आकार की परवाह किए बिना, सबसे पहली चीज जो मैं करता हूं, वह है बिल्ड एंड डिप्लॉयमेंट को ऑटोमेटाइज करना। यदि किसी प्रोजेक्ट के शुरुआती दिनों में ऐसा करने से हफ्तों की बचत होती है तो मैं दिनों को बचाता हूं।

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

सब कुछ फाइल तैनाती से डेटाबेस अपग्रेड, बैकअप, सूचना, रिपोर्टिंग, सहित ...

Comments

पूरी तरह से निश्चित नहीं है कि आप यहां क्या प्रस्ताव दे रहे हैं - क्या आप कह रहे हैं कि समस्या प्रबंधन को संबोधित करना चाहिए टीम भावना की कमी है? या आप कह रहे हैं कि मैं टीम भावना की कमी का प्रदर्शन करके यह पता लगाने की कोशिश कर रहा हूं कि यह काम कैसे किया जाए (और सफलता की संभावनाओं के बारे में घबराकर)?

— अर्काटितो

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