2008-09-17 12 views
12

यह एक दार्शनिक प्रश्न का एक सा है। मैं अपने सॉफ़्टवेयर में एक छोटी सी विशेषता जोड़ रहा हूं जो मुझे लगता है कि अधिकांश उपयोगकर्ताओं द्वारा उपयोग किया जाएगा, लेकिन सॉफ्टवेयर का उपयोग करने के केवल 10% बार ही। दूसरे शब्दों में, सॉफ्टवेयर बिना 3 महीने के ठीक है, लेकिन 4 या 5 उपयोगकर्ताओं ने इसके लिए पूछा है, और मैं मानता हूं कि यह वहां होना चाहिए।कौन सा बेहतर है: एक छोटी गाड़ी सुविधा शिपिंग या सुविधा शिपिंग बिल्कुल नहीं?

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

क्या करना है? क्या ऐसी सुविधा है जो वास्तव में "कुछ भी नहीं" से 90% है? मुझे पता है कि मुझे कुछ बग रिपोर्ट मिलेंगी जिन्हें मैं ठीक नहीं कर पाऊंगा: मैं उन ग्राहकों के बारे में ग्राहकों को क्या कहूं? क्या मुझे अनुत्तरित फीचर अनुरोधों या अनुत्तरित बग रिपोर्ट के साथ रहना चाहिए?

उत्तर

3

हमेशा अनुत्तरित फीचर अनुरोध और बग रिपोर्ट्स रहेगी। इसे शिप करें, लेकिन जब संभव हो तो "ज्ञात समस्याएं" और वर्कअराउंड के साथ एक रीडेम शामिल करें।

1

सटीक रूप से जीतने वाले दस्तावेज़ को दस्तावेज करें और इसे शिप करें।
सुनिश्चित करें कि उपयोगकर्ता और को जीतने के अपने दस्तावेज़ को समझें।

आप उन उपयोगकर्ताओं के निर्णय पर भी चर्चा कर सकते हैं जिन्होंने सुविधा का अनुरोध किया है: कुछ बाजार अनुसंधान करें।

सिर्फ इसलिए कि आप इसे ठीक नहीं कर सकते हैं, इसका मतलब यह नहीं है कि आप भविष्य में सक्षम नहीं होंगे। चीज़ें बदल जाती हैं।

1

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

12

सुनिश्चित करें कि लोग जानते हैं कि आप जानते हैं कि समस्याएं हैं। कि बग हैं। और उन्हें प्रतिक्रिया देने का एक आसान तरीका दें।

"4 या 5 उपयोगकर्ताओं" के साथ "बंद बीटा" रखने के बारे में क्या, जिन्होंने पहली जगह में सुविधा का सुझाव दिया था?

2

आपको इसे अपने उपयोगकर्ता के परिप्रेक्ष्य से सोचने की ज़रूरत है - जिससे कम निराशा होगी? छोटी गाड़ी कोड आमतौर पर गायब सुविधाओं की तुलना में अधिक निराशाजनक है।

0

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

1

शिप शिप, अक्सर जहाज, निरंतर रिफैक्टरिंग।

मेरा मतलब है कि, यह आपको शिपिंग से रोकने न दें, लेकिन समस्याओं को ठीक करने पर न छोड़ें।

विजयीता को हल करने में असमर्थता आपके कोड बेस में समस्याओं का संकेत है। सुविधाओं को जोड़ने से अधिक समय रिफैक्टरिंग खर्च करें।

2

पूर्णतावादी उत्तर दे सकते हैं "ऐसा न करें"।

व्यवसायी लोग "ऐसा करें" का उत्तर दे सकते हैं।

मुझे लगता है कि शेष राशि आपके ऊपर है। यदि बग गैर-महत्वपूर्ण हैं तो मैं सुविधा को वहां डालने की ओर अग्रसर हूं। अधिकांश उपयोगकर्ता आपके सॉफ़्टवेयर को उसी तरह नहीं देखते हैं जैसा आप करते हैं। आप एक शिल्पकार/कलाकार हैं, जिसका मतलब है नियमित लोगों की तुलना में आपका अधिक महत्वपूर्ण।

क्या कोई तरीका है कि आप 4-5 लोगों को बीटा संस्करण प्राप्त कर सकते हैं जिन्होंने सुविधा का अनुरोध किया था? फिर, एक बार जब आप उनकी प्रतिक्रिया प्राप्त कर लेते हैं, तो यह स्पष्ट हो सकता है कि कौन सा निर्णय लेना है।

1

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

आपकी स्थिति के आधार पर बस कुछ विचार।

1

निर्भर करता है। बग्स पर, उनकी गंभीरता और आपको कितना प्रयास लगता है कि यह उन्हें ठीक करने के लिए ले जाएगा। समय सीमा पर और आप कितना सोचते हैं कि आप इसे फैला सकते हैं। शेष कोड पर और ग्राहक इसके साथ कितना कर सकता है।

1

मैं उम्मीद नहीं करता कि कोडर्स को परीक्षण में ज्ञात समस्याओं को वितरित करने के लिए अकेले ही ग्राहक को रिहा करने दें।

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

यदि आपको कोड जारी करना होगा, तो प्रत्येक सुविधा/बग को दस्तावेज करें जिसे आप जानते हैं, और प्रत्येक को ठीक करने के लिए प्रतिबद्ध हैं।

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

0

आपको जिस महत्वपूर्ण प्रश्न का उत्तर देने की आवश्यकता है वह यह है कि यदि आपकी सुविधा एक वास्तविक व्यवसाय को हल करेगी जिसे आपने बनाया है। फिर यह केवल कार्यान्वयन को बनाने के लिए एक मामला है - "बग" को गैर-बग्स के रूप में परिभाषित करके सुविधा के इच्छित व्यवहार (जिसे डिजाइन द्वारा कवर किया जाना चाहिए) के रूप में परिभाषित करके।

यह पथों की एक बहुत ही वास्तविक पसंद के लिए उबलता है: क्या एक बग कुछ ठीक से काम नहीं करता है, जो इच्छित व्यवहार और डिजाइन का हिस्सा नहीं था? या यह केवल एक बग है अगर इरादा व्यवहार के अनुसार काम नहीं करता है?

मैं बाद में एक दृढ़ आस्तिक हूं; बग वे चीजें हैं जो काम करने के इरादे से काम नहीं करती हैं। कार्यान्वयन को डिजाइन पर कब्जा करना चाहिए, जो व्यापार की जरूरत को पकड़ लेना चाहिए। यदि कार्यान्वयन का उपयोग किसी भिन्न व्यावसायिक आवश्यकता को हल करने के लिए किया जाता है जो डिजाइन द्वारा कवर नहीं किया गया था, तो यह वह डिज़ाइन है जो गलती पर है, कार्यान्वयन नहीं; इस प्रकार यह एक बग नहीं है।

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

1

यदि मांग एक सुविधा के बजाय अब एक सुविधा के लिए है, तो मांग। आपको जहाज भेजना पड़ सकता है।

इस स्थिति हालांकि में:

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

यदि बग मौत का कारण बन सकता है या उपयोगकर्ताओं की फाइलों को खो सकता है तो उसे शिप न करें।

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

यदि बग बीएसओडी का कारण बन सकती है तो आप इसे किसके पास भेजते हैं इसके बारे में बहुत सावधान रहें।

0

किसी ऐसे व्यक्ति से आ रहा है जिसने अपने उपयोगकर्ताओं के लिए बग्गी सॉफ़्टवेयर इंस्टॉल करना है - इसे उस सुविधा के साथ सक्षम न करें।

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

संबंधित मुद्दे