परिवर्तनों के जोखिम से कार्यों / बगों को वर्गीकृत करें

Question

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

हम JIRA का उपयोग करते हैं इसलिए मैंने इस अनुमान पर नज़र रखने के लिए मुद्दों को लेबल करना शुरू किया। मैंने देखा है कि बग / कार्य को वर्गीकृत करने के लिए मैंने कई मैट्रिक्स का उपयोग किया है:

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

मेरे लेबल एक तरह से गन्दे हैं क्योंकि मेरे पास एक स्पष्ट विचार नहीं था जब मैंने शुरू किया कि संभावित श्रेणियां क्या होंगी और मैं अभी भी नहीं। मैं एक नए क्षेत्र को जोड़ने का अनुरोध करने के बारे में सोच रहा हूं ("जोखिम" जैसी कोई चीज) ताकि किसी को काम सौंपने से पहले हमें एक अनुमान की आवश्यकता हो।

क्या किसी ने इससे पहले इस तरह से निपटा है?

Answer 1

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

बहु-आयामी बग ट्रैकिंग का वर्णन करने वाला एक ब्लॉग पोस्ट इसे डेवलपर दृश्य सहित संबोधित करता है: PEF और REV।

PEF मान उपयोगकर्ता के दृश्य हैं:

• पी ain - बग का सामना करने पर कितना दर्दनाक है?
• E toffort - इसके चारों ओर काम करने में कितना प्रयास करना पड़ता है?
• एफ occurququency - बग कितनी बार होता है?

आरईवी पक्ष डेवलपर के दृष्टिकोण से है:

• आर isk - फिक्स कितना जोखिम भरा है?
• E ffffort - इसे ठीक करने में कितना प्रयास करना होगा?
• V Verifiable - यह सत्यापित करना कितना आसान है कि बग ठीक हो गया है?

इनमें से प्रत्येक को 1..9 पैमाने पर मापा जाता है, जिसमें 1 कम / आसान और 9 उच्च / कठोर होता है। PEF और REV के लिए एक अंक देने के लिए संख्याओं को एक साथ जोड़ा जाता है।

वह हिस्सा जो बिट्स को संबोधित करता है:

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

REV में वर्णित प्रयास और जोखिम में ये कारक।

हां, यह कुछ ऐसा है जो पहले से लड़ा गया है। मेरे पास (अतीत में) रेडमाइन में कस्टम क्षेत्रों के लिए इस मॉडल का उपयोग किया गया था और यह यथोचित सफल था।

इसका बड़ा फायदा तब मिलता है जब आप PEF और REV स्कोर की तुलना करते हैं। यदि आपके पास 21 का पीईएफ है और 7 का आरईवी है, तो कुछ ऐसा है जो एक बड़ी जीत हो सकती है। जबकि 7 का पीईएफ और 21 का आरईवी कुछ ऐसा है, जिसे थोड़ी देर के लिए टाला जाना चाहिए क्योंकि जोखिम और प्रयास के पक्ष में लाभ को ठीक करने की संभावना है।

फिर आरईवी स्कोर को देख सकते हैं और कम जोखिम वाले चीजों को कम अनुभवी डेवलपर्स को सौंप सकते हैं (कम जोखिम, उच्च प्रयास अक्सर इस स्थिति के लिए आदर्श होते हैं)।

Comments

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

— टेकटेक

@takteek एक और बिट, जो इस से संबंधित है, खोया है। उन मीट्रिक को ड्राइव करने के लिए इस्तेमाल किया जा सकता है (यह 1-100 पैमाने उत्पन्न करता है जिसमें सभी उपयोगकर्ता पक्ष की जानकारी शामिल होती है जो मैं इसे भी देखना चाहता हूं)। इस पर ध्यान दें कि "कॉस्ट" को "संकेत" करने के लिए प्रलोभन उपयोगकर्ता के मीट्रिक में डेवलपर साइड जानकारी को शामिल नहीं करता है।

Answer 2

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

हालाँकि, आपने जो लिखा उससे आपको लगता है कि दो मुद्दे हैं:

1. आप नए या अनुभवहीन प्रोग्रामर के साथ काम कर रहे हैं।
2. आपके कोड की गुणवत्ता (ज्यादा / कुछ) संदिग्ध प्रतीत होती है।

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

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

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

Answer 3

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

मेरा सुझाव है कि एक वैकल्पिक रणनीति कोड समीक्षाओं की एक शासन संस्था है। ट्रिकी सामान (कारण के भीतर) पर काम करने के लिए newbies को काम करने दें, लेकिन उनके काम की अच्छी तरह से समीक्षा करें।

छोटी अवधि में, यह सभी के लिए अधिक काम आता है। लंबी अवधि में, आप डेवलपर्स की एक पूरी टीम के साथ समाप्त हो जाएंगे जो जटिल सामान को संभाल सकते हैं, और जहां तक ​​कोड गुणवत्ता का संबंध है, "एक ही पृष्ठ पर" हैं।