आपकी फुर्तीली / स्क्रम टीम पर बग वर्क क्या है?

9

यहां हमारा है: - यदि वर्तमान स्प्रिंट में बग एक कहानी से संबंधित है, तो हम इसे ठीक कर देते हैं। - यदि बग वर्तमान स्प्रिंट में एक कहानी से संबंधित नहीं है और यह महत्वपूर्ण नहीं है, तो इसे उत्पाद के मालिक को प्राथमिकता के लिए भेजा जाता है। - यदि बग स्प्रिंट में एक कहानी से संबंधित नहीं है और यह महत्वपूर्ण है, तो हम इसे ठीक कर देते हैं।

— user11347
स्रोत

अच्छा सवाल है, लेकिन मैं इसे विस्तार से यह भी पूछूंगा कि प्रक्रिया के बारे में क्या अच्छा काम करता है और क्या नहीं ... वे क्या बदलेंगे?

— वाल्टर

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

— टॉम एंडरसन

7

वर्तमान स्प्रिंट में काम से संबंधित कुछ भी तय है, हम उन्हें कीड़े भी नहीं मानते हैं और उन्हें इस तरह से नहीं लिखते हैं। हम केवल एक बग पर विचार करते हैं यदि यह किसी चीज का हिस्सा है जिसे हमने पहले से ही माना है।

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

— जेसन
स्रोत

2

आप कैसे ट्रैक करते हैं कि बग मौजूद है? मान लीजिए कि व्यक्ति A बग को ढूंढता है और व्यक्ति B बग को ठीक करता है। क्या आपने टास्क बोर्ड में कुछ नहीं डाला है?

— user11347

2

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

इसलिए यदि आप आश्वस्त हैं कि बग्स कहानियां हैं, तो आप उनका इलाज करते हैं क्योंकि आप अनुमानों और प्राथमिकताओं के संबंध में अन्य कहानियां हैं।

— टॉम विलिस
स्रोत

"एक बग सिर्फ एक कहानी है जिसमें पहले से ही एक असफल परीक्षा है" - यह बहुत अच्छा है!

— 24नमायो

2

मुझे लगता है कि यह दृष्टिकोण करने का सबसे अच्छा तरीका यह निर्धारित करना है कि आप वास्तव में पहले बग पर विचार करना चाहते हैं।

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

मेरी कंपनी निम्नलिखित कार्यप्रणाली का उपयोग यह निर्धारित करने के लिए करती है कि बग को कब ठीक किया जाना चाहिए:

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

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

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

एक तरफ मुझे लगता है कि सबसे अच्छी बात यह है कि एक संरचना को चुनना है और फिर उसके साथ रहना है। उत्पादकता के कुछ सबसे बड़े नुकसान तब होने लगते हैं जब आप संरचना के बिना काम करना शुरू करते हैं। एक बार जब आप अपनी संरचना को नीचा दिखाना शुरू कर देते हैं, तो यह सभी डाउनहिल के लिए जाना बहुत आसान होता है।

हो सकता है कि यह आपके प्रश्न का उत्तर दे दिया हो, लेकिन ये केवल मेरे विचार हैं कि इन चीजों को कैसे संभाला जाना चाहिए।

— msarchet
स्रोत

1

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

अन्य बगों के लिए, हम आम तौर पर उन्हें समय की अनुमति के अनुसार ठीक करते हैं। यदि दबाव वाले मुद्दे हैं, तो हम कुछ कहानियों को वापस खींचते हैं और सामान्य सुविधा के काम पर वापस आने से पहले बग फिक्स पर समय व्यतीत करते हैं।

— एडम लीयर
स्रोत

1

स्प्रिंट के दौरान पाए जाने वाले कीड़े विकास का हिस्सा हैं।

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

— डेव
स्रोत