मुझे लगता है कि आप अपनी चिंताओं को मिला रहे हैं। और आपकी ओर से ऐसा कुछ भी नहीं है जिसे आपको बदलने की आवश्यकता है।
उत्पादकता एक संकेत है कि कितनी जल्दी एक परियोजना पूरी हो जाएगी। प्रोजेक्ट मैनेजर और बाकी सभी लोग जानना चाहेंगे कि प्रोजेक्ट कब डिलीवर होगा। उच्च या तेज उत्पादकता का मतलब है कि हम जल्द ही परियोजना को वितरित करेंगे।
बग्स की दर उत्पादकता से जुड़ी नहीं है, बल्कि परियोजना के आकार की है। उदाहरण के लिए, आपके पास कोड की Nप्रति Yलाइनें बग हो सकती हैं । उस मीट्रिक के भीतर कुछ भी नहीं है जो कहता है (या परवाह करता है!) कितनी जल्दी कोड की उन पंक्तियों को लिखा जाता है।
इसे एक साथ बाँधने के लिए, यदि आपके पास उच्च उत्पादकता है, तो हाँ, आप बग को और तेज़ी से लिखेंगे। लेकिन आप वैसे भी बग की संख्या के लिए जा रहे थे क्योंकि यह परियोजना के आकार से बंधा है।
यदि कुछ भी हो, तो उच्च उत्पादकता का मतलब है कि आपके पास उन बगों का शिकार करने के लिए परियोजना के अंत में अधिक समय होगा या डेवलपर आपके द्वारा बनाए गए बगों को खोजने में तेज होगा। 1
अपने प्रश्न के अधिक व्यक्तिगत पहलुओं को संबोधित करने के लिए।
यदि आपका बॉस आपके द्वारा बनाए जाने वाले कीड़े की दर के विपरीत आपके द्वारा बनाए जाने वाले कीड़े की संख्या पर सख्ती से देख रहा है, तो एक शैक्षिक सत्र क्रम में है। बनाई गई बग की संख्या एक समर्थन दर के बिना अर्थहीन है।
उस उदाहरण को चरम पर ले जाने के लिए, कृपया अपने बॉस को बताएं कि मुझे आपका वेतन दोगुना चाहिए। क्यों? मैंने आपके प्रोजेक्ट पर बिल्कुल बग नहीं बनाया है और इसलिए मैं आपसे बहुत बेहतर प्रोग्रामर हूं। क्या? वह एक समस्या है कि मैं कोड की एक भी लाइन का उत्पादन नहीं किया है आपकी परियोजना को लाभ होगा? आह। अब हमें समझ है कि दर क्यों महत्वपूर्ण है।
ऐसा लगता है कि आपकी टीम में प्रति कहानी बिंदुओं के मूल्यांकन के लिए मैट्रिक्स है। यदि और कुछ नहीं है, तो इसे बनाए गए बग की कच्ची संख्या द्वारा मापा जाना बेहतर है। आपके सर्वश्रेष्ठ डेवलपर्स को अधिक बग बनाने चाहिए क्योंकि वे अधिक कोड लिख रहे हैं। क्या आपके बॉस ने उस ग्राफ को बाहर फेंक दिया है या कम से कम एक और श्रृंखला को इसके पीछे फेंक दिया है जिसमें दिखाया गया है कि कितने कहानी अंक (या जो भी व्यवसाय मूल्य आप मापते हैं) बग की संख्या के साथ। वह ग्राफ एक अधिक सटीक कहानी बताएगा।
1
इस विशेष टिप्पणी ने इस ओर अधिक ध्यान आकर्षित किया है कि इसका इरादा क्या था। तो चलिए थोड़ा पांडित्यपूर्ण (आश्चर्य, मुझे पता है) और इस प्रश्न पर अपना ध्यान केंद्रित करना चाहिए।
इस सवाल का मूल गलत काम (ओं) को देखने वाले एक प्रबंधक के बारे में है। वे कच्चे बग के योग देख रहे हैं जब उन्हें पीढ़ी दर बनाम पूरे किए जाने वाले कार्यों को देखना चाहिए। चलो "कोड की पंक्तियों" या कहानी बिंदुओं या जटिलता या जो भी हो, के खिलाफ मापने पर जुनूनी नहीं। यह सवाल हाथ में नहीं है और वे चिंताएं हमें अधिक महत्वपूर्ण प्रश्न से विचलित करती हैं।
जैसा कि ओपी द्वारा लिंक में दिया गया है, आप परियोजना के आकार के हिसाब से शुद्ध रूप से एक निश्चित संख्या में कीड़े की भविष्यवाणी कर सकते हैं। हां, आप विभिन्न विकास और परीक्षण तकनीकों के माध्यम से इस संख्या को कम कर सकते हैं। फिर, यह इस सवाल का मुद्दा नहीं था। इस प्रश्न को समझने के लिए, हमें यह स्वीकार करने की आवश्यकता है कि किसी दिए गए आकार की परियोजना और विकास पद्धति के लिए, हम "पूर्ण" विकसित होने के बाद एक निश्चित संख्या में बग देखेंगे।
तो चलिए अंत में इस टिप्पणी पर वापस आते हैं कि कुछ पूरी तरह से गलत समझा गया। यदि आप दो डेवलपर्स के लिए तुलनात्मक रूप से कार्य असाइन करते हैं, तो उत्पादकता की उच्च दर वाले डेवलपर दूसरे से पहले अपना कार्य पूरा कर लेंगे। इसलिए अधिक उत्पादक डेवलपर के पास विकास विंडो के अंत में अधिक समय उपलब्ध होगा। उस "अतिरिक्त समय" (अन्य डेवलपर की तुलना में) का उपयोग अन्य कार्यों के लिए किया जा सकता है जैसे कि उन दोषों पर काम करना जो एक मानक विकास प्रक्रिया के माध्यम से समाप्त हो जाएंगे।
हमें उनके शब्द पर ओपी लेना होगा कि वे अन्य डेवलपर्स की तुलना में अधिक उत्पादक हैं। उन दावों के भीतर कुछ भी नहीं निकलता है कि ओपी या अन्य उत्पादक उत्पादक अपने काम में फिसड्डी साबित हो रहे हैं। यह बताते हुए कि कम कीड़े होंगे यदि वे फीचर पर अधिक समय बिताते हैं या सुझाव देते हैं कि डिबगिंग इस विकास समय का हिस्सा नहीं है, तो यह याद किया जाता है कि क्या पूछा गया है। कुछ डेवलपर्स दूसरों की तुलना में तेज़ हैं और तुलनीय या बेहतर गुणवत्ता वाले काम का उत्पादन करते हैं। दोबारा, उन लिंक को देखें जो ओपी अपने प्रश्न में देता है।