डेवलपर्स को बगों को प्राथमिकताएं कैसे प्रभावित करें और तदनुसार उनका इलाज करें?

Question

हमारे पास एक बग प्रक्रिया है जो वर्तमान में काम कर रही है।

हमारे पास बग के 3 स्तर हैं:

• P1 बग: बग्स जो उपयोगकर्ताओं को काम करने से रोकता है। उन्हें मौके पर ही हल करना होगा।
• पी 2 बग: कीड़े जो प्रभावित कर रहे हैं लेकिन उपयोगकर्ता काम कर सकते हैं
• पी 3 बग: कीड़े जो प्रभावित नहीं कर रहे हैं और जहां उपयोगकर्ता काम कर सकते हैं।

P1 अनिवार्य है और मौके पर ही निपटा जाना चाहिए। लेकिन पी 2 और पी 3 के लिए, हम मामले के आधार पर एक मामले का न्याय करते हैं।

हमारे पास 3 स्तरों के साथ, टीम के पास पी 2 और पी 3 से निपटने के बजाय ग्राहकों द्वारा पूछे जाने वाले अधिक नए नए विकास पर काम करने की प्रवृत्ति है, जो लगभग तत्काल जरूरी नहीं है।

प्रश्न निम्नलिखित हैं:

क्या मुझे P4 होने की तरह, प्राथमिकता का एक और स्तर जोड़ना चाहिए?

क्या मुझे इस सप्ताह की तरह गैर जरूरी टिकटों से निपटने के लिए भी उन्हें लक्ष्य प्रदान करना चाहिए, जब कोडिंग कार्य नहीं सौंपा जाता है, तो आपको कम से कम 1 पी 2 का इलाज करना चाहिए?

वर्तमान में, हमारे पास ऐसे उद्देश्य नहीं हैं जैसे मैंने ऊपर उठाया लेकिन मेरी चिंता यह है कि उन्हें ऐसे उद्देश्य देना क्रूर हो सकता है। यह बात निश्चित है कि मुझे उद्देश्यों के बारे में उनसे बात करने की आवश्यकता है, टीम विशेष रूप से चर्चा में शामिल होना पसंद करती है जब हम उद्देश्य निर्धारित कर रहे होते हैं।

अपडेट करें:

---

मुझे इस प्रश्न को समानता के रूप में प्रस्तावित किया गया था । हालाँकि यह बिलकुल भी नहीं है।

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

Comments

के संभावित डुप्लिकेट मैं प्रबंधन कैसे समझाने तकनीकी कर्ज से निपटने के लिए कर सकते हैं?

— gnat

आमतौर पर प्राथमिकता स्तर प्राथमिकता क्रम के रूप में उपयोगी नहीं है ... "बग एक्स" "बग वाई" की तुलना में अधिक महत्वपूर्ण है। यदि आप p4 जोड़ते हैं तो अंततः आपको p5 और p3.5 चाहिए

— sudo rm

आप इतने सारे P1 समस्या युक्त हैं तो अपने डेवलपर्स के सभी हमेशा उन्हें फिक्सिंग के बजाय P2 / पी 3 पर काम कर रहा है, तो आप कुछ कर रहे व्यस्त हैं कि बहुत गलत। कुछ समय के लिए और अधिक सुविधाएँ न जोड़ें। आर्किटेक्चरल (या कर्मियों) समस्याओं को कम करने और ठीक करने पर ध्यान केंद्रित करें जो लगभग निश्चित रूप से इनमें से कई बग पैदा कर रहे हैं। यदि आप C ++ में कोडिंग कर रहे हैं, उदाहरण के लिए, सुनिश्चित करें कि आप RAII का उपयोग हर जगह पर कर सकते हैं, ताकि आप मैन्युअल रूप से भूल न जाएं .release()।

— निधि मोनिका का मुकदमा

आपका लक्ष्य क्या है? क्या आप चाहते हैं कि डेवलपर्स बग फिक्स पर अधिक और नई सुविधाओं पर कम काम करें? कृपया अपने प्रश्न को स्पष्ट करने के लिए संपादित करें। इसके अलावा, कृपया बताएं कि डेवलपर्स वर्तमान में कैसे प्राप्त करते हैं या काम पर जाते हैं? क्या तय किया जाता है कि किस पर काम किया जाता है?

— १२

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

— मटनज़

Answer 1

आम तौर पर आपके पास कीड़े के लिए दो कुल्हाड़ी होती हैं: गुरुत्वाकर्षण और आवृत्ति।

तो जाहिर है कुछ गंभीर और अक्सर सर्वोच्च प्राथमिकता है। हालाँकि, ऐसा कुछ जो गंभीर होता है, लेकिन शायद ही कभी ऐसा होता है कि इसे लगभग उसी तरह तौला जाना चाहिए जो गंभीर नहीं है लेकिन अक्सर होता है। इसलिए आपको 1 से 3 तक गुरुत्वाकर्षण की दर और 1 से 3 तक की आवृत्ति को ध्यान में रखते हुए, जिस प्रकार के कीड़े को आप ठीक करना चाहिए, वे हैं जो गुरुत्वाकर्षण 1, आवृत्ति 3 और गुरुत्वाकर्षण 3, आवृत्ति 1 द्वारा परिभाषित विकर्ण को पार करते हैं।

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

एक त्रुटि जो उपयोगकर्ता हर बार देखता है और जब भी प्रोग्राम लॉन्च होता है, उसकी आवृत्ति 3 होती है। आवृत्ति 1 के साथ एक त्रुटि कुछ होने वाली है जो कि शायद ही कभी होती है। फिर, यदि आप निश्चित नहीं हैं, तो 2 शायद असाइन करने के लिए एक सुरक्षित नंबर है।

यह ज्यादातर गुरुत्वाकर्षण 3 या आवृत्ति 3 के साथ बग के साथ एक बग का गठन करने पर व्यक्तिपरक है, लेकिन अपने सामान्य ज्ञान का उपयोग करें। गुरुत्वाकर्षण 1 के साथ एक बग, आवृत्ति 2 शायद एक गलत वर्तनी वाला लेबल है। गुरुत्वाकर्षण 2 के साथ एक बग, आवृत्ति 1, डेटाबेस कनेक्शन डाउन होने पर उचित त्रुटि हैंडलिंग हो सकती है।

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

इसके अलावा, सुविधा के लिए, आप पा सकते हैं कि आप गुरुत्वाकर्षण या आवृत्ति के लिए पत्र ग्रेड प्रदान करना पसंद करते हैं, इसलिए आप कह सकते हैं कि बग एक B3 त्रुटि है, और यह गुरुत्वाकर्षण और आवृत्ति दोनों स्पष्ट है।

सौभाग्य!

Comments

वास्तव में, बग्स के लिए केवल एक मीट्रिक है - आरओआई - यह तय करने के लिए कितना खर्च होगा कि कंपनी इसे ठीक नहीं करने के लिए कितना खो देती है। तुलना करें कि सुविधाओं के लिए। बेशक, आप कैसे गणना करते हैं कि मीट्रिक गुरुत्वाकर्षण, आवृत्ति, आदि शामिल है

— corsiKa

@ कोरसी, हां ROI एक समग्र मीट्रिक है: "वापसी" और "निवेश"। और बग के लिए, वापसी को "गुरुत्वाकर्षण" और "आवृत्ति" के एक संयोजन के रूप में तैयार किया जा सकता है।

— पॉल ड्रेपर

@corsiKa, गुणवत्ता के निर्णयों के ठंडे खून वाले स्वार्थी विश्लेषण वास्तव में बेहद गैर जिम्मेदाराना है। यह वही तर्क है जो दवा कंपनियों को प्रभावकारिता परीक्षण कानूनों को दरकिनार करने की ओर ले जाता है यदि वे प्रतिकूल प्रभावों की गंभीरता और आवृत्ति के बावजूद बाजार पर "इसके साथ दूर हो सकते हैं" या लाभदायक दवाओं को रख सकते हैं। यह वही अपरिवर्तनीयता है जो असुरक्षित उपभोक्ता रूटर्स और "स्मार्ट" उपकरणों से बना है, क्योंकि निर्माता अच्छी सुरक्षा में किसी भी डॉलर के मूल्य को नहीं देख सकते हैं। गुरुत्वाकर्षण और आवृत्ति MUCH "नीचे लाइन प्रभाव" की तुलना में बेहतर मैट्रिक्स हैं।

— वाइल्डकार्ड

@Wildcard मैं सचमुच एक कम्युनिस्ट हूं, इसलिए मैं 100% आपसे सहमत हूं कि वे बेहतर हैं। यह इस तथ्य को नहीं बदलता है कि यह कैसे सॉफ्टवेयर कंपनियों को चलाया जाता है, और उस ज्वार के खिलाफ जा रहा है, जब तक कि आप कंपनी नहीं चलाते हैं, आपको डूब जाएगा। हालांकि यह ध्यान देने योग्य है, यह स्वार्थी नहीं है। यह एकल-सेवा है, लेकिन यह एकल स्वयं नहीं है, यह कंपनी है। बस उसे फेंक रहे हैं।

— corsiKa 20

@Wildcard और corsiKa कंपनी एक बड़ी नहीं है और हम यह कहने का जोखिम नहीं उठा सकते हैं कि "ओह, हम पैसे खोने जा रहे हैं, तो चलो कुछ करें अन्यथा हम इसे अभी भी जारी रखें"। हालांकि, चीजों की भव्य योजना में, मुझे विश्वास नहीं है कि आपके द्वारा उल्लिखित दृष्टिकोण लंबे समय में टिकाऊ है। लोग - ग्राहक बेवकूफ से बहुत दूर हैं। जो कंपनियां इस तरह के सुसमाचार का प्रचार कर रही हैं, सूर्य, उनका नाम लेने के लिए अब यहां नहीं हैं। मैं खाता प्रबंधन में लंबे समय से काम कर रहा हूं कि पैसा उस तरह से अर्जित नहीं होता है। किसी के लिए, यदि आप ऐसी कंपनी के लिए काम करते हैं, जहां कंपनी में निष्ठा का अभाव है 1 / n

— एंडी के

Answer 2

यह वास्तव में जो आपको अधिक महत्वपूर्ण मानता है, उसे उबालता है। P2 बग या नई सुविधा?

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

डेवलपर्स को उन कार्यों को चुनने की अनुमति नहीं है जिन पर वे काम करते हैं। यही प्रोजेक्ट मैनेजर का काम है। किसे यह सुनिश्चित करना चाहिए कि बजट से पहले परियोजना में शामिल महत्वपूर्ण विशेषताओं में से सबसे बड़ी संख्या संभव है।

यह वास्तव में सबसे महत्वपूर्ण बात है। "एक सप्ताह में कम से कम 1 पी 2 फिक्स" जैसे सरल नियम वास्तव में इस लक्ष्य की मदद नहीं करते हैं।

Comments

प्राथमिकताएं बताने में परेशानी यह है कि आप जो भी बकेट ग्रैन्युलैरिटी चुनते हैं, वह हमेशा एक से अधिक बकेट के साथ खत्म होती है। आपको चीजों को क्रम में रखने की ज़रूरत है, न कि केवल यह कहें कि "ये सब सर्वोच्च प्राथमिकताएं हैं!"

— इवान

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

— कासपर्ड

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

— कास्परेडी

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

— इवान

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

— बाल्ड्रिक

Answer 3

एक सॉफ्टवेयर के लिए यह एक बहुत ही सामान्य चक्र है कि जब तक कुछ नहीं देता तब तक गैर-राजनीतिक कीड़े ढेर हो जाते हैं, फिर एक बड़ी घटना होती है और उनमें से कई एक समय में तय हो जाते हैं; हो सकता है कि एक बड़े नए रिलीज से पहले केवल एक बुंटिफ्ट या एक स्प्रिंट समर्पित करके, या सॉफ्टवेयर ईओएल होने और ढेर-ओ-बग्स से बचे रहें।

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

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

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

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

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