मैंने कुछ सहयोगियों से पूछा कि यह क्या हो रहा है, और उन्होंने उल्लेख किया कि अगर बग में प्राथमिकता का स्तर नहीं है, तो यह बहुत दुर्लभ है कि बग को डेवलपर का ध्यान जाता है, जो वास्तव में समझ में आता है
दरअसल, अगर आप मुझसे पूछें तो यह नहीं है। प्राथमिकता के जितने अधिक (उपयोग किए गए) स्तर, उतनी ही अधिक जानकारी। यदि आप प्रभावी रूप से केवल एक ही प्राथमिकता रखते हैं, तो यह वही है जिसमें कोई प्राथमिकता नहीं है।
और चूंकि आपके पास अभी भी निपटने के लिए कीड़े की समान संख्या है, और इसे करने के लिए मैनहोर्स की समान मात्रा है, यह इस प्रकार है कि कुछ अन्य अनुमानी का उपयोग किया जाएगा, संभवतः अशक्त एक - "पहले आओ, पहले पाओ"। और इसलिए अब आपके पास बग प्राथमिकता वाली मीट्रिक है, सिवाय इसके कि आगमन का समय है और अब आपके नियंत्रण में नहीं है।
यह बग फिक्सिंग के लिए आवंटित नहीं किए जा रहे पर्याप्त संसाधनों का एक लक्षण हो सकता है (कुछ नीतियाँ हैं जैसे " बग्स तय होने तक कोई नई सुविधाएँ नहीं हैं " जो वहां मदद कर सकती हैं। जोएल ने अनुमोदन किया ; सीमाओं और परिणामों को समझना एक व्यावसायिक निर्णय है )।
एक परियोजना में मैंने काम किया, आने वाली कीड़े "बिना प्राथमिकता के बफर" में जमा हो गईं और हर सोमवार हम बग सूची की समीक्षा करेंगे, कठिनाई का अनुमान (एक बहुत मोटा अनुमान; अधिक बार हम सिर्फ "औसत" में नहीं डालते हैं) और उन्हें उपलब्ध समय के अनुसार क्रमबद्ध करें। यह सूची को उबाऊ, निर्बाध या विचार-से-कठिन कीड़े से टकराती थी; ऑफसेट करने के लिए, पर्यवेक्षकों और विपणन के पास प्रति सप्ताह एक निश्चित संख्या में क्रेडिट थे जो वे पसंदीदा बगों की प्राथमिकता को टक्कर देने के लिए खर्च कर सकते थे, और अनसुलझी बगों के लिए प्रतिपूर्ति की गई थी (यह एक सीमा तय करता है कि डेवलपर-तिरस्कृत बग को कितना विलंबित किया जा सकता है) ।
कीड़े को मर्ज करना, रद्द करना और विभाजित करना भी संभव था; मुझे याद है कि एक मॉड्यूल जो इतनी निराशाजनक रूप से त्रुटिपूर्ण था कि हमने कुछ बीस या तीस बग रिपोर्ट एक ही "खरोंच से इस बात को फिर से लिखना" में डूब गया, जो तब "स्पष्ट रूप से मनहूस चीज के इनपुट और आउटपुट", "परीक्षण को स्पष्ट रूप से विभाजित करता है"। इनपुट सुनिश्चित करने के लिए और आउटपुट युक्ति से मेल खाते हैं ", इत्यादि। अंतिम आइटम "पुनर्नवीनीकरण कागज पर पुराने कोड को प्रिंट करना, इसे लॉन पर बाहर लाना और इसे आग लगाना था" (हमने वह भी किया था। मुझे याद है कि यह कितना अच्छा लगा। हमने स्तवन को चालू कर दिया; यह काफी प्रफुल्लित करने वाला था। )।
कुछ परेशान होने के बाद, हमारे पास सप्ताह की टू-डू सूची थी, जिसे "डू कैन", "हो सकता है" और "नहीं कर सकते" में विभाजित किया गया था जो अगले सप्ताह तक टकरा गए थे। यह वह जगह है जहां कुछ अतिरिक्त घपलेबाजी हुई: हमने बग को आवंटित करने के लिए पचास घंटे कहा था, और हम पहले बीस को ठीक करने के लिए 95% सुनिश्चित थे। प्रबंधन दृढ़ता से चाहता था कि इक्कीसवीं बग को ठीक किया जाए और उसके पास कोई क्रेडिट नहीं बचा था; फिर हम "बग डू" लिस्ट में से एक के साथ उस बग को स्वैप करने की पेशकश करेंगे, या कोई कहेगा कि "मुझे कुछ दिनों के लिए FooBazFeature सबटाइम से हटा दें और मैं इसे कर दूंगा", या हम कहेंगे "हमें और अधिक चाहिए मानव शक्ति "।
प्रणाली ने किसी को संतुष्ट नहीं किया, वास्तव में, लेकिन यह माना जाता था (कम से कम डेवलपर्स के बीच) एक अच्छा संकेत है।
कुछ अतिरिक्त नकारात्मक पैटर्न जो बदल गए, प्रबंधकों के हिस्से पर "इच्छाधारी सोच" थे ("आपने कहा कि बग 572 में आठ घंटे की आवश्यकता होती है। यह अस्वीकार्य है। इसे चार बनाएं" और "डीबग बाय फिएट" ("जो भी आप चाहते हैं)" लेकिन ये चालीस बग अगले सप्ताह बड़े डेमो से पहले तय होने चाहिए। आपके पास अधिक समय नहीं हो सकता है, आपके पास अधिक लोग नहीं हो सकते हैं ")। इसके अलावा बॉक्सर सिंड्रोम ("मैं कड़ी मेहनत करूंगा"), जो थोड़े समय के लिए बहुत अच्छी तरह से काम करने के लिए जाता था , लेकिन आमतौर पर एक डेवलपर को बाहर निकलने या हरियाली वाले चरागाहों के लिए छोड़ दिया जाता था।