क्या अंक ट्रैकिंग सिस्टम का उपयोग करने के नुकसान के बारे में अध्ययन किया गया है? [बन्द है]

Question

मुझे ट्रैकिंग सिस्टम जारी करना पसंद नहीं है क्योंकि:

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

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

क्या मैं यहाँ अकेला हूँ? क्या समस्या ट्रैकिंग सिस्टम का उपयोग करने के नुकसान (या महान लाभ) के बारे में अध्ययन (पुस्तक / लेख / जो कुछ भी) है?

Comments

बंद करने के लिए मतदान, बहुत स्थानीयकृत। यहाँ समस्या समस्या ट्रैकिंग सिस्टम के साथ नहीं दिखती है, बल्कि कंपनी पर बग-हैंडलिंग प्रक्रिया के साथ है।

— पी। ब्रायन। मैके

आपने किस समस्या-ट्रैकिंग सिस्टम को आज़माया है (पोस्ट-इट नोट्स और व्हाइटबोर्ड के अलावा)? उनके उपयोग के आसपास क्या प्रक्रिया थी?

— FrustratedWithFormsDesigner

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

— FrustratedWithFormsDesigner

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

— s_hewitt

आप इसे पोस्ट करने के लिए स्टैक ट्रेस कैसे संलग्न करते हैं? या एक स्क्रीनशॉट? या एक त्रुटि संदेश?

— जे.के.

Answer 1

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

यदि आप बग का वर्णन नहीं कर सकते हैं तो आप इसे कैसे शुरू कर सकते हैं?

आप अपने कीड़े रखने के लिए एक जगह बनाते हैं। और अगर उनके लिए एक जगह है, तो लोग आमतौर पर बग को ठीक करने के बारे में बहुत अधिक परवाह नहीं करते हैं क्योंकि वे इसे वहां रख सकते हैं ताकि किसी दिन कोई इसे ठीक कर सके (या नहीं)।

यह सॉफ्टवेयर के साथ आपकी टीम के नहीं होने की समस्या है।

समय के साथ, बग सूचियां इतनी लंबी हो जाती हैं कि कोई भी इससे निपट नहीं सकता है, हमारा बहुत समय लगता है।

फिर अपनी टीम के साथ एक समस्या का वर्णन करते हुए।

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

Comments

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

— डेविड थॉर्नले

और अपनी टीम के साथ समस्या को ठीक करने के लिए आप Gamification का उपयोग कर सकते हैं -> en.wikipedia.org/wiki/Gamification

— mar'd

@JoaoBosco: हाथ से लिखे टिकट गुम हो जाते हैं, दुर्घटनाग्रस्त हो जाते हैं, दुर्घटना से बाहर हो जाते हैं ... जब आप ऐसे लोगों को जटिल बग बताते हैं, जिनके पास फोटोग्राफिक मेमोरी नहीं है, तो आमने-सामने की बातचीत बहुत अच्छी है। लोग बातचीत से चीजों को भूल जाएंगे , इसलिए नहीं कि वे चाहते हैं बल्कि इसलिए कि बस यही होता है।

— FrustratedWithFormsDesigner

@ जोआबोस्को: जीयूआई त्रुटियों के स्क्रीनशॉट के बारे में क्या? क्या आप उन्हें हाथ से छुड़ाएंगे? गलत डेटा आउटपुट के नमूने (यदि यह एक डेटाबेस त्रुटि है, तो क्या आप गलत डेटा के एम कॉलम के साथ n पंक्तियों को लिखने के लिए तैयार हैं )? डिजिटल कलाकृतियों के अन्य रूप जो इस दोष से जुड़े हैं कि बस चिपचिपा नोटों का अच्छी तरह से अनुवाद नहीं करते हैं? उस सभी सामान को आसानी से एक अंक ट्रैकिंग सिस्टम में टिकट से जोड़ा जा सकता है। और अगर आप बाद में अपने स्टिकी नोट को टेक्स्ट फ़ाइलों में परिवर्तित करने जा रहे हैं, तो ऐसा डेटाबेस क्यों नहीं जो आपको अपने टिकटों को क्रमबद्ध, क्रमबद्ध करने, श्रेणीबद्ध करने की अनुमति देता है, फिर थोड़ी देर के लिए समस्या-ट्रैकिंग के लिए।

— FrustratedWithFormsDesigner

@ user1062120: "यदि कीड़े रखने की कोई जगह नहीं है, तो लोग इसे अधिक बार सही करना शुरू कर देते हैं" - या वे कीड़े को अनदेखा करना और भूलना शुरू कर देते हैं। यह "लोगों को प्रेरित करने की चाल" नहीं है, बल्कि एक कमजोरी को ताकत में बदलने का एक बेतुका प्रयास है।

— माइकल बोर्गवर्ड्ट

Answer 2

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

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

1. खुले बगों में से कौन सा पहले तय किया जाना चाहिए? (ध्यान दें: एक समझदार परियोजना में, यह उत्पाद स्वामी और / या प्रबंधन द्वारा तय किया जाना चाहिए, किसी डेवलपर द्वारा नहीं - जिसके लिए उन्हें सबसे पहले सभी खुले कीड़े के बारे में पता होना चाहिए !)
2. हमारे पास कितने खुले बग हैं, और किस गंभीरता के हैं?
3. रिलीज होने के लिए तैयार होने से पहले इनमें से कौन तय किया जाना चाहिए?
4. इन सुधारों की योजना बनाने में कितना समय लगता है - अक्सर इसके लिए अग्रणी होता है: औसतन बग को ठीक करने में कितना समय लगता है?
5. पिछले रिलीज में ग्राहकों द्वारा कितने बग रिपोर्ट किए गए हैं?
6. किसने इस-और-इस बग को ठीक किया, कब, और क्या (कोड / कॉन्फ़िगरेशन / डेटा) परिवर्तनों ने फिक्स को शामिल किया?
7. हम जो प्रकाशन जारी करने वाले हैं, उसमें कौन से बग सुधार शामिल हैं?
8. ...

क्या आप अपने पोस्ट-इट नोट्स के आधार पर ऐसे सवालों के जवाब दे सकते हैं [अपडेट] बार-बार, मज़बूती से और कुशलता से [/ अपडेट] ?

हाँ, बग डेटा को एक समस्या ट्रैकर में दर्ज करने से कुछ ओवरहेड हो जाता है। हालांकि, यह संग्रहीत बग डेटा से ऊपर की तरह रिपोर्ट बनाने और सहेजने में लगने वाले समय और प्रयास से मुआवजा से अधिक है।

Comments

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

— user1062120

@ user1062120: और बाकी सभी लोग कह रहे हैं कि आप बहुत गलत हैं। पोस्ट-अपने हैं एक मुद्दा ट्रैकिंग प्रणाली, बस एक बहुत ही गरीब है कि आवश्यक सुविधाओं का एक बहुत अभाव है।

— माइकल बोर्गवर्ड

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

— Péter Török

@ user1062120, उदाहरण के लिए योजना 1 से ऊपर की पैदावार - चलो प्राथमिकता के अनुसार चिपचिपे नोटों को फिर से व्यवस्थित करें। जल्द ही पीएम ने Q2: oops से पूछा, गंभीरता से पुनर्व्यवस्थित करें। लेकिन Q1 अभी भी खुला है, इसलिए अब हम उन सभी को प्राथमिकता के आधार पर फिर से क्रमबद्ध करेंगे। उफ, 3 पोस्ट-इसके बाहर छोड़ दिए गए थे क्योंकि वे जोए के डेस्क पर थे - फिर से शुरू करें! फिर Q6 - चलो ऐतिहासिक पोस्ट के भंडारण वाले बक्से को खोदते हैं, उचित को खोजने के लिए उन सभी को हाथ से ब्राउज़ करते हैं, फिर इसकी पीठ पर स्क्रिबल को पढ़ने की कोशिश करते हैं, जिसका मतलब है कि परिवर्तनों का वर्णन करें ... उफ़, किसी ने खोला खिड़की के पास, अपनी पोस्ट को बचाने के लिए भीड़-अपनी हवा से बचने के लिए ... आदि

— Péter Török

Answer 3

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

कुछ लेख / अध्ययन जिसमें आपकी रुचि हो सकती है, इस लेख में ज़ीरा के ज़ीरा के उपयोग पर चर्चा और इस फ्रांसीसी अध्ययन में बग ट्रैकिंग सिस्टम के उपयोग पर चर्चा की गई है।

Comments

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

— user1062120

+1 संदर्भों के लिए, जो अन्वेषण थे प्रश्न में पूछे गए थे।

— मटनज

Answer 4

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

1. विकास दल
2. सिस्टम के उपयोगकर्ता

कैल हेंडरसन (पूर्व में फ़्लिकर) के पास कई मुद्दे ट्रैकर्स के डिजाइन पर एक महान पद है और वह GitHub मुद्दे पर नज़र रखने वाले (जैसा कि मैं) को प्राथमिकता देता है। इसके अलावा, गैरेट Dimon के डिजाइन को कवर किया Sifter और अधिक के लिए प्रक्रिया को सरल बनाने के लिए एक रास्ता सचित्र प्रभावी मुद्दा ट्रैकिंग । मैंने अपनी टीम के समस्या ट्रैकिंग वर्कफ़्लो को आसान बनाने में मदद करने के लिए इन दोनों पोस्टों में से कुछ विचारों को अपनाया है।

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

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

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

Comments

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

— user1062120

Answer 5

जैसे ही वे दिखाई देते हैं, महत्वपूर्ण कीड़े को मारना

ऐसा लगता है कि आप यहां खुले दरवाजे में घुस रहे हैं। यदि आप समस्या ट्रैकर का उपयोग करते हैं या नहीं, तो महत्वपूर्ण कीड़े जल्द से जल्द "मारे" जाते हैं।

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

---

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

आमने-सामने की बातचीत बनाम अंक ट्रैकिंग पर अध्ययन के बारे में, फिर से ऐसा महसूस होता है कि आप यहाँ खुले दरवाजे को तोड़ रहे हैं। अंक ट्रैकिंग एक विशिष्ट लिखित संचार है; वहाँ बहुत सारे अनुसंधान दिखा रहे हैं कि चीजों पर चर्चा करने के लिए, फेस 2फेस संचार फोन की तुलना में बहुत अधिक कुशल है जो बदले में लिखित की तुलना में बहुत अधिक कुशल है ।

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

बग सूची इतनी लंबी हो जाती है

मेरे अनुभव में, उपरोक्त एक समस्या है एक समस्या नहीं है।

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

• मुझे केवल एक ही मामला याद है जब लंबी बग सूची एक समस्या रही है। यह तब हुआ जब उच्च प्रबंधन में कुछ बेवकूफों ने एक नीति पर फैसला किया, जो डेवलपर्स को अगले दैनिक लगभग 50-100 के ढेर से बग को चुनने के लिए मजबूर करता है। कितना बेकार है। यह हमें कुछ महीनों तक दर्द में ले गया, जब तक हमें पता नहीं चला कि यह उसके सिर पर कैसे बढ़ सकता है और इसे ठीक कर सकता है।
  सुविधाजनक कार्य प्रवाह स्थापित करने में कामयाब होने के कुछ समय बाद हमने पाया कि हमारा "अंतहीन बैकलॉग" जादुई रूप से खाली हो गया है।

Comments

मैंने हाल ही में 300 से अधिक खुले बग (ज्यादातर यूआई) के माध्यम से 2.5 साल का समय बिताया है, जो एक वर्ष में अर्जित किया गया है, सभी को फ्रीलांसरों / प्रशिक्षुओं को लंबे समय के लिए सौंपा गया है, या परियोजना प्रबंधक को, जिनके पास उनसे निपटने के लिए कोई समय नहीं था। मैंने पाया कि मैं उनमें से लगभग आधे को पहले से तय कर सकता हूं या फिर प्रासंगिक नहीं। बाकी लोगों को उचित दर पर तय करने के बाद मैं उन्हें सही लोगों को सौंपता हूं। बग ट्रैकिंग सिस्टम का उपयोग खराब तरीके से किया गया था, लेकिन इसके बिना, उन सभी बग्स (कोई शो-स्टॉपर्स नहीं, लेकिन कुछ बहुत बदसूरत) निश्चित रूप से भूल गए होंगे।

— माइकल बोर्गवर्ड

@MichaelBorgwardt हाँ, इतनी लंबी सूची है कि कोई भी मेरे अनुभव में इसके साथ सौदा नहीं कर सकता है हमेशा प्रबंधनीय निकला जब तक कि 200, 400, 1000 जैसे डरावने दिखने वाले नंबरों से जमे हुए नहीं होते हैं। मैंने बस जिज्ञासा से बाहर एक त्वरित जांच की - पिछले साल के लिए मैंने 300+ मुद्दे तय किए - मैं अकेला (!)। जिज्ञासावश मैंने टीम के अन्य लोगों को यह सोचकर भी चेक किया कि शायद मैं अद्वितीय हूं - नहीं, 200-400 फिक्स / वर्ष सिर्फ एक औसत दर दिखाई देती है। 500 कीड़े, हालांकि ये देखो डरावना, 4-5 डेवलपर्स के लिए काम का सिर्फ आधा साल हो सकता है, केक का टुकड़ा :)

— gnat