क्या एजाइल की टीमों को रोजाना नई सुविधाएँ देनी चाहिए?

Question

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

हमारे अधिकांश देवता प्रतिदिन लगभग 2 घंटे बैठक और अन्य उद्यमी उपरि से हार जाते हैं। इसका मतलब यह है कि किसी भी 6-घंटे (सर्वोत्तम) अवधि में, हमें क्यूए के साथ खेलने के लिए एक पूर्ण सुविधा का उत्पादन करने के लिए डिज़ाइन करना, लिखना, यूनिट-टेस्ट, निर्माण और तैनात करना (पर्याप्त नोट्स जारी करना) है। मैं समझता हूं कि बिल्ड / तैनात / रिलीज नोटों को एक उचित CI सेटअप के साथ स्वचालित किया जा सकता है, लेकिन हम अभी तक वहां नहीं हैं।

हमारे पास अपना सर्वर-साइड कोड लिखने वाला एक बड़ा अपतटीय दल भी है, और 12 घंटे का समय अंतर इसे और भी कठिन बना देता है।

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

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

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

Answer 1

इन दिनों एजाइल के नाम पर जो अपराध होते हैं, वे मुझे दुखी करते हैं। बहुत से लोग इस संक्रमण को बनाने में कठिन समय बिता रहे हैं।

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

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

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

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

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

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

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

Comments

+1: बहुत बढ़िया जवाब। वास्तव में "चुस्त" का मतलब कुछ अच्छे परिप्रेक्ष्य होना चाहिए।

— जिम जी।

Answer 2

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

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

Comments

मैंने सवाल को खराब बताया। मैं वास्तव में रोजाना नई सुविधाओं को देने की व्यवहार्यता के बारे में पूछ रहा था, न कि किसी मौजूदा उत्पाद को दैनिक बिल्डरों द्वारा तोड़े जाने के बारे में। मैंने सवाल अपडेट किया है।

— जोशुआ स्मिथ

@JoshuaSmith: यदि आप कहानियाँ काफी छोटी हैं, तो हर दिन नया सामान रखना पूरी तरह से संभव है। और यदि आपके पास निरंतर एकीकरण सर्वर है, तो टूटे हुए उत्पाद का विकल्प नहीं है। यदि कोई सुविधा तैयार नहीं है, तो यह सर्वर के साथ सिंक नहीं है, या एक निजी शाखा में किया गया है। मैं पहला उपाय पसंद करता हूं।

Answer 3

संक्षिप्त उत्तर: नहीं । यह सिर्फ दैनिक पूरा नहीं किया जा सकता है।

हालांकि, फुर्तीली टीम प्रत्येक स्प्रिंट में काम करने वाले सॉफ़्टवेयर टुकड़े या उपयोगकर्ता की कहानियों को वितरित करने वाली थी । आमतौर पर प्रगति और बाधाओं को देखने के लिए प्रतिदिन स्थिति बैठक आयोजित की जाती है।

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

Comments

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

— जॉन लियोन

आइए स्पष्ट करें: "जब तक उपयोगकर्ता कहानी नहीं की जाती और जाँच नहीं की जाती, तब तक आप क्यूए को कुछ भी लोड नहीं कर सकते।"

— एल युसुबोव

थोड़ा और स्पष्टीकरण: एक कहानी तब तक नहीं की जाती है जब तक कहानी के लिए कोड का परीक्षण नहीं किया गया है।

— ब्रायन ओकले

@ElYusubov यह भी मेरी समझ थी कि हम प्रत्येक स्प्रिंट के अंत में नई सुविधाओं / कहानियों को देने वाले थे, जो पूरी तरह से उचित है।

— जोशुआ स्मिथ

Answer 4

नहीं, हर दिन नई सुविधाएँ देने की अपेक्षा नहीं होनी चाहिए। सभी सुविधाओं को इतने छोटे आकार में नहीं तोड़ा जा सकता है कि विकास के 6 घंटे के समय में डेवलपर की सुविधा समाप्त हो सके।

यदि आप स्क्रैम कर रहे हैं, तो आपको न्यूनतम 2 सप्ताह के स्प्रिंट में होना चाहिए, जिसमें आकार को 0 से 8 दिन तक समाप्त होने के लिए लगभग आकार होना चाहिए। उत्पाद के मालिक से वादा किया गया है कि नए, परीक्षणित और सत्यापित सही काम कोड दिए जाएं जो स्प्रिंट के अंत में उत्पादन में लगाए जा सकते हैं। (नोट: आपको वास्तव में इसे उत्पादन में लगाने की ज़रूरत नहीं है लेकिन लक्ष्य यह है कि यदि आप चाहते हैं तो यह हो सकता है)

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

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

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

Comments

यह वही है जो हम अब करते हैं, लेकिन नई सुविधाएँ शायद ही कभी पूरा होने में एक दिन लेती हैं, विशेष रूप से अपतटीय शामिल।

— जोशुआ स्मिथ

जो ठीक है, फुर्तीला / डरावना है बस कहता है कि यह स्प्रिंट के अंत में संभावित shippable कोड देगा, नई सुविधाएँ भी नहीं! कई स्थानों पर पूरे स्प्रिंट होते हैं जहां यह केवल प्रदर्शन में सुधार कर रहा है या कोड को साफ कर रहा है। कोई भी स्थान जो आपसे प्रत्येक दिन एक नई सुविधा प्राप्त करने की अपेक्षा करता है, जो आपको फायदा उठाने के लिए घोटाले का दुरुपयोग कर रहा है।

— एलन बार्बर

Answer 5

यह वास्तव में परियोजना के आकार पर निर्भर करता है; यदि परियोजना एक बड़ी है तो इसे प्राप्त करने के लिए कोई संभव तरीका नहीं है।

दैनिक (या इससे भी अधिक बार) बनाता है जो निरंतर एकीकरण उपकरण से बाहर निकलता है, इसका मतलब काम करने वाले सॉफ़्टवेयर नहीं है; यह मुश्किल से कोड का मतलब है।

Comments

कुछ मायनों में मुझे लगता है कि QA को रोजाना कुछ नए फीचर्स मिलना एक बड़े प्रोजेक्ट पर आसान होना चाहिए। उदाहरण यदि आपके पास 5 देव / देव टीमें हैं, तो आप उन्हें अगले सप्ताह से एक दिन में प्रत्येक ऑफसेट को 1 सप्ताह के लिए कर सकते हैं।

— डैन नीली

Answer 6

कई परियोजनाएं हैं जो दैनिक बिल्डरों को वितरित करती हैं, जो निरंतर एकीकरण के लिए धन्यवाद, काम कर रहे सॉफ़्टवेयर हैं। कम से कम सिद्धांत में।

इसका मतलब है कि यह जरूरी नहीं है कि नई सुविधाएँ हों। शायद कुछ मामूली बग फिक्स, या कुछ भी नहीं।

सिद्धांत रूप में, यदि आप अपने QA को प्रतिदिन अधिक कार्य प्रदान करने में असमर्थ हैं, तो आपको या तो डेवलपर की संख्या बढ़ानी होगी या परीक्षकों की संख्या कम करनी होगी। भयानक विचार!

आपका काम चीजों को प्राप्त करना है।

QA को बताएं कि ऐसा करने पर उन्हें परीक्षण करने के लिए कुछ मिलेगा। आपको उन्हें यह समझाने की आवश्यकता है कि क्यों।

Comments

एक हजार बार, यह। मैंने प्रोजेक्ट लीड को बताया कि क्यूए को काम पर रखना मेरी टीम की ज़िम्मेदारी नहीं है और इसे ज़ोरदार तरीके से झेला गया।

— जोशुआ स्मिथ

अधिक ठोस तथ्यों के साथ वापस आने का प्रयास करें: Developersurvivalguide.com/how-to-convince-your-boss

@JoshuaSmith: मैंने अपना उत्तर आपके हाल के संपादन से मिलान करने के लिए संपादित किया है, लेकिन मुझे डर है कि यह वह उत्तर नहीं है जिसकी आपको तलाश है ...

Answer 7

मुझे लगता है कि आप "सीआई" के विचार के बारे में भ्रमित हैं। आप मार्टिन फाउलर के इस बेहतरीन लेख पर जाना चाह सकते हैं कि सीआई किस तरह से काम करते हैं । आपको अपने सवाल का सही जवाब देना चाहिए।