बग ट्रैकिंग सॉफ़्टवेयर से आपको कितनी बड़ी टीम की आवश्यकता है? [बन्द है]

Question

मेरी विकास टीम सिर्फ 100% (1 डेवलपर से 2 तक) बढ़ी। मेरा नया सहकर्मी बग ट्रैकिंग सॉफ्टवेयर में निवेश करना चाहता है। क्या इतनी छोटी टीम के लिए इस तरह के सॉफ्टवेयर का लाभ है?

Comments

बग ट्रैकिंग सॉफ्टवेयर से एक लाभ की एक टीम।

— डोमिनिक मैकडोनेल

आप FogBugz के छात्र और स्टार्टअप संस्करण को आज़माना चाहते हैं - सेट करने और उपयोग करने के लिए बहुत आसान और सुविधाजनक ( fogcreek.com/fogbugz/StudentAndStartup.html )।

— मैक्सिम ज़स्लावस्की

यहां तक ​​कि <1 व्यक्ति की टीम को बग ट्रैकिंग

— सॉफवेयर की

@Vardhan एक व्यक्ति से कम की टीम? जैसे, एक गैर-मौजूद टीम?

— इक्के

@ इके .. जैसे एक व्यक्ति कई प्रोजेक्ट्स पर काम कर रहा है .. और भूल रहा है कि मल्टीपल प्रोजेक्ट्स पर क्या करना है ... मैनेजिंग कॉल 0.5 रिसोर्स है !!

— vrdhn

Answer 1

मुझे लगता है कि सभी "हां" जवाब विचार का समर्थन करने के लिए एक लंबा रास्ता तय करते हैं। लेकिन मैं इस विचार को समाप्त करने जा रहा हूं कि निर्णय कुछ प्रश्नों पर आधारित है:

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

IMO, इन प्रश्नों के उत्तर इस बारे में अधिक हैं कि आप उत्पाद को कहां देखते हैं और आप अपनी टीम को कैसे विकसित करना चाहते हैं और "2 लोग = बग ट्रैकिंग सिस्टम का कारण" के बारे में कम। बड़ा सवाल शायद यह है कि "बग ट्रैकिंग सिस्टम कॉन्फ़िगर करने और प्रबंधित करने और खरीदने की लागत के समय के लायक है?"

Comments

बहुत अच्छी तरह से डाल दिया! एक उपकरण चुनें जो आपके काम करने के तरीके को अनुकूलित करता है! अन्यथा, एक कॉर्कबोर्ड का उपयोग करें!

— एंड्रेस जान टैक

Answer 2

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

Comments

Bugzilla शायद एक वर्चुअल सर्वर में बहुत कम लागत के लिए स्थापित किया जा सकता है।

— Zachary K

Trac भी रखरखाव के लिए ज्यादा नहीं लेता है। मैं एक Trac उदाहरण के बारे में 2 साल सीधे चल रहा है और नई परियोजनाओं को जोड़ने के अलावा कुछ भी बनाए रखने के लिए कभी नहीं पड़ा है।

— whatsisname

मुझे पता है कि दोनों को बनाए रखना आसान है, बल्कि यह है कि यह एक "गैर-शून्य व्यय" है, अर्थात, मुफ्त नहीं। शायद प्रति वर्ष कुछ घंटे अगर आप सुरक्षा पैच स्थापित करना चाहते हैं, या कुछ दिन अगर आपको पुराने संस्करण से माइग्रेट करने की आवश्यकता है या आपका हार्डवेयर मर जाता है।

— l0b0

स्थापना का व्यय शून्य-शून्य है, लेकिन यदि अच्छी तरह से उपयोग किया जाता है तो यह होने के लाभ से बहुत कम होगा।

— बिलथोर

उन hg उपयोगकर्ताओं के लिए BitBucket को न भूलें।

— शोलेिंगर

Answer 3

हमारे पास पहली बार एक बहुत छोटी टीम थी जिसमें मैंने बग ट्रैकिंग सॉफ्टवेयर का उपयोग किया था और मैं चकित था कि हम कितना सामान सोच रहे थे जिसे ठीक करने के लिए हमें जरूरत थी कि किसी तरह कभी भी तय नहीं हो सके। यह पूरी तरह से लायक है चाहे आपकी टीम कितनी भी बड़ी हो।

Comments

मैं पूरी तरह से इससे संबंधित कर सकता हूं । कल ही मैंने अपनी नोटबुक खो दी थी जहाँ मैंने कुछ बग्स लिखे थे जिन्हें ठीक करने की आवश्यकता थी। अब मुझे समस्या क्षेत्र में जाने के लिए एक और दो घंटे बर्बाद करने होंगे। मैं Bugzilla या कुछ और डाउनलोड करने जा रहा हूं।

अच्छी बात। मनोवैज्ञानिक अनुसंधान बताता है कि लोग अपनी अल्पकालिक स्मृति में ~ 7 आइटम रख सकते हैं। यदि आपके पास टूडू सूची में ~ 7 से अधिक आइटम हैं, तो बग ट्रैकिंग एक अच्छा विचार है। यदि आप उन्हें किसी भी तरह से लिख रहे हैं, तो आप इसे एक स्केलेबल और व्यवस्थित तरीके से कर सकते हैं (यह अधिक प्रयास नहीं है)।

— dbkk

Answer 4

हाँ। एक हज़ार बार हाँ।

बग ट्रैकिंग के संदर्भ में भी ऐसा न सोचें, लेकिन टिकट ट्रैकिंग के रूप में।

टिकटों में आपके सभी कार्यों को देखने में सक्षम होने के कारण बहुत बड़ा लाभ होता है। आप किसी कार्य का इतिहास एक जगह रख सकते हैं। आपको पता है कि किसने और कब काम किया। आप यह कहकर विस्तृत हो सकते हैं कि किसी कार्य के लिए किस दिन क्या पूरा हुआ था।

बग ट्रैकिंग के लिए, आप अपने सभी बगों को एक स्थान पर रख सकते हैं और उन लोगों पर नज़र रख सकते हैं जो पूरे हो चुके हैं और जो अभी भी जारी हैं।

यह सिर्फ चीजों को बेहतर तरीके से प्रबंधित करने में आपकी मदद करता है।

Comments

'टिकट' ट्रैकिंग का उल्लेख करने के लिए +1। ऐसी प्रणाली में केवल बग स्टोर करना बेवकूफी होगी, अगर आप इसे व्यक्तिगत टूडू सूची, भविष्य के संस्करण की योजना के रूप में भी उपयोग कर सकते हैं, ...

— stijn

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

— टिम विलिसक्रॉफ्ट

हां इसे "बग" ट्रैकिंग न कहें। हम इसे "कार्य" ट्रैकिंग कहते हैं, क्योंकि बग एक कार्य है, लेकिन कार्य आवश्यक रूप से बग नहीं है।

— कार्सन63000

Answer 5

यह एक या अधिक की एक टीम के साथ इसके लायक है।

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

यह भी ध्यान देने योग्य है: बग-ट्रैकर्स में से कई बहुत छोटी टीमों (1-2) द्वारा उपयोग के लिए स्वतंत्र हैं, इसलिए यह ऐसा नहीं है कि आप लाभ के लिए किसी भी बड़े व्यय को लागू कर रहे हैं।

Answer 6

आपको टीम के प्रत्येक सदस्य के लिए किसी भी बग ट्रैकिंग सॉफ़्टवेयर की आवश्यकता नहीं है

• एक आदर्श फोटोग्राफिक मेमोरी है, और
• टीम के हर दूसरे सदस्य के साथ अपने विचारों को सिंक्रनाइज़ कर सकते हैं।

Answer 7

छोटा जवाब हां है।

कुछ कारण क्यों:

1. विशिष्ट संस्करणों के विरुद्ध पाए जाने वाले कीड़े को लॉग करने की क्षमता।
2. यह जानने की क्षमता कि कौन से (ज्ञात) बग अभी तक तय नहीं किए गए हैं।
3. ट्रैक जो एक बग को तय करता है जो फिर से पाया गया है।
4. डेवलपर टर्नओवर - भले ही आप लौकिक बस हो हिट ज्ञान हस्तांतरण के लिए अनुमति देता है।

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

Answer 8

यह उत्तर तर्क के YES पक्ष में वजन जोड़ने के लिए है।

मैं ज्यादातर एक टीम हूं। मैं व्यापक रूप से एसवीएन एकीकरण के साथ समस्या ट्रैकिंग (रेडमाइन) का उपयोग करता हूं।

यह वास्तव में शानदार है और मैं इसके बिना पागल हो जाऊंगा; मेरी गुणवत्ता गिर जाएगी क्योंकि मैं चीजों के बारे में भूल जाऊंगा, और मुझे काम करने के लिए जो कुछ मिला है, उसका मैं ट्रैक कर लूंगा।

उत्पादकता उपकरण:

• निर्णय आईडीई
• मुद्दा ट्रैकिंग
• स्रोत नियंत्रण

मुद्दा ट्रैकिंग; इसके बिना घर मत छोड़ो

Answer 9

यदि आपके पास कम है तो 3 आप शायद Google डॉक्स स्प्रेडशीट के साथ प्राप्त कर सकते हैं, शायद, मुझे लगता है। लेकिन वास्तव में बगज़िला या कहीं और स्थापित करने की लागत प्रोग्रामर की लागत के आगे इतनी तुच्छ है कि आप इसे करने से बेहतर हैं। (जब आप 7 से बढ़ेंगे तो यह पहले से ही होगा)

Answer 10

यहां तक ​​कि किसी की टीम किसी प्रकार के बग ट्रैकर से लाभान्वित हो सकती है, चाहे वह नोट्स की पाठ फ़ाइल हो, या कुछ पूर्ण विकसित सॉफ़्टवेयर। 2 डेवलपर्स के लिए, मैं केवल कुछ बग ट्रैकिंग सिस्टम स्थापित करने में समय लगाने की सलाह दूंगा, पैसा नहीं। परियोजना के आधार पर, आप कागज पर बग्स लिखने के साथ ठीक से प्राप्त कर सकते हैं, एक साझा ऑनलाइन दस्तावेज़ के माध्यम से एक सूची बनाए रख सकते हैं, या मुफ्त बग ट्रैकिंग सॉफ़्टवेयर जैसे कि Trac या Bugzilla का उपयोग कर सकते हैं। फोगबुग भी 45 दिनों के लिए नि: शुल्क परीक्षण के रूप में उपलब्ध है।

Answer 11

हाँ।

आपको उन्हें कुछ ट्रैक करने की आवश्यकता है कि कैसे!

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

Answer 12

निश्चित बेंटिफेट है - मैं व्यक्तिगत परियोजनाओं पर भी बग ट्रैकिंग सॉफ्टवेयर का उपयोग करता हूं। यह न केवल ट्रैकिंग बग के लिए उपयोगी है, बल्कि 'TODO' और फीचर अनुरोधों को ट्रैक करने के लिए भी उपयोगी है।

Answer 13

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

Answer 14

बस एक का उपयोग करना शुरू करें

यदि आप बस एक का उपयोग करना शुरू करते हैं, तो आप अभ्यास पर उनकी सुविधा को महसूस करना शुरू कर देंगे, बहुत कुछ संस्करण नियंत्रण सॉफ्टवेयर या उस मामले के लिए, वितरित संस्करण नियंत्रण।

विकास परिपक्वता

इससे कोई फर्क नहीं पड़ता कि आपके पास 100 या 1 की टीम है, मैंने बग ट्रैकिंग और वितरित संस्करण नियंत्रण का उपयोग करना शुरू कर दिया (अपने आप के लिए और अपने आप के लिए ही स्थानीय कमिट की वजह से बहुत समझ में आता है) और मैंने पहले से ही एक और स्तर पर महसूस किया, लेकिन नहीं केवल इतना ही, मैं अपने काम को दूसरे स्तर पर प्रबंधित कर सकता हूं ... एक स्तर पर यह मेरे बिना अधिक प्रयास किए निवेश कर सकता है।

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

Answer 15

मेरे लिए यह केवल सॉफ्टवेयर के बारे में नहीं है, बल्कि यह प्रक्रिया जो इसके चारों ओर जाती है। टेस्ट मैनेजर के रूप में मेरे दिन-प्रतिदिन की नौकरी में मैं मूल रूप से एक में रहता हूं और यह निम्नलिखित लाभ प्रदान करता है:

मुझे लगता है कि यह वास्तव में 2+ परीक्षकों और 3+ डेवलपर्स के साथ काम करता है।

डेवलपर बग फिक्सिंग प्रयासों का प्रबंधन

हम सक्रिय रूप से एक डेवलपर "बग कतार" का प्रबंधन करते हैं ताकि यह नियंत्रित किया जा सके कि उन्होंने उन्हें कितना काम सौंपा है, और यह सुनिश्चित करें कि हमारे पास टीम में बग फिक्सिंग कार्य का एक स्तरीय आवंटन है।

यह तय करना कि क्या तय हुआ और क्या नहीं

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

जब आपको मेट्रिक्स की आवश्यकता होती है

मेरे लिए बड़ी बात है मेट्रिक्स, यानी जब आप बग ढूंढने और ट्रेंड को ठीक करने में सक्षम होना चाहते हैं, तो कोड के बग्गी क्षेत्र कहां हैं, या परीक्षक कितनी जल्दी ढूंढ रहे हैं और बग्स का पुन: परीक्षण कर रहे हैं। यह बग ट्रैकिंग सिस्टम का समय है।

Answer 16

मैं आम राय से सहमत हूं कि एक टीम के सदस्य को बग ट्रैकर की आवश्यकता शुरू करने के लिए पर्याप्त है। आपके एक या दो वास्तविक उपयोगकर्ता होने के बाद भी मैं इसे अनिवार्य करूँगा, लेकिन आपकी पहली रिलीज़ से पहले यह महत्वपूर्ण है।

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

ट्रैकर के साथ कसकर संशोधन नियंत्रण के साथ एकीकृत, आप आसानी से टिकट में परिवर्तन लिंक कर सकते हैं, और संशोधन (और विकि पृष्ठ संपादन) के रूप में एक ही समय लाइन दृश्य में टिकट अपडेट देख सकते हैं।

Answer 17

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

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

Answer 18

यहाँ मेरा 2 सेंट है।

बग ट्रैकिंग के लिए मैं सिर्फ एक Google-doc स्प्रेडशीट का उपयोग करता हूं, मैं किसी को भी आमंत्रित कर सकता हूं जिसे मैं संपादित करना या देखना चाहता हूं। यह मुफ़्त है तो एक निवेश के ज्यादा नहीं। मैं वहाँ बग पर सभी कार्यों का ट्रैक रखने के लिए।

मैं अपने वेब होस्ट पर SVN भी चलाता हूं जो वेब होस्टिंग के लिए कोई अतिरिक्त लागत नहीं जोड़ता है।

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

Answer 19

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

मूल रूप से, बग को एक सख्त और औपचारिक प्रक्रिया के रूप में दर्ज करने की आवश्यकता नहीं है, जिससे आपको बग रिपोर्ट (बगज़िला, मैं आपको देख रहा हूं) भरने के लिए 30 मिनट के लिए अलग सेट करने की आवश्यकता होती है। इसका मतलब यह है कि लोग इसका इस्तेमाल नहीं करेंगे।

अंत में, बग सूची (भले ही प्रत्येक बग में पाठ के लगभग 50 अक्षर हों) बेहद मूल्यवान है। "हम्म, 1.0 रिलीज करने के लिए बाउट। मुझे लगता है कि मैंने बग की आखिरी तारीख तय कर दी है।" और प्रबंधकों के लिए यह देखना भी बहुत अच्छा है कि आप वास्तव में कुछ कर रहे हैं :)। एक टीम में, यह अधिक मूल्यवान है क्योंकि आप दोनों अपने सिर में मानसिक टू-डू सूचियों का एक अलग सेट रखने की कोशिश नहीं कर रहे हैं। और यह तय करता है कि "क्या आपने इसे ठीक किया है [वास्तव में खराब सुरक्षा बग]? उम, हाँ मैं ऐसा सोचता हूं। ठीक है, फिर 1.0 जारी करें।"

मैं भी सुविधाओं का ट्रैक रखने के लिए प्यार करता हूँ। यह थोड़ा अधिक वैकल्पिक है, लेकिन मुझे अभी भी मेरे सिर में टूडू सूची रखने के मानसिक कार्य को बंद करने में सक्षम होने से लाभ मिलता है।

इसके अलावा, देखें कि जोएल का इस बारे में क्या कहना था

Answer 20

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

हालाँकि, जैसे ही आपके पास दो या अधिक डेवलपर होते हैं, बग ट्रैकिंग सॉफ़्टवेयर नहीं होने का एक कारण नहीं है, एक नहीं।

Answer 21

हाँ। और एक सिफारिश है bitbucket http://www.bitbucket.org वे मुफ्त बग ट्रैकिंग प्रदान करते हैं और साथ ही साथ मर्क्यूरियल में मुफ्त निजी रिपोजिटरी भी प्रदान करते हैं ।

Answer 22

एक। किस मामले में यह एक टू-डू सूची की तरह है।

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

Answer 23

मुझे लगता है कि आपके प्रश्न ने आपकी गलत धारणा को उजागर किया है। इसके लिए वह टीम नहीं है जिसे बग ट्रैकिंग की आवश्यकता है, यह उत्पाद है।

तो, क्या सॉफ्टवेयर में बग ट्रैकिंग की आवश्यकता है? ठीक है, यह मदद करेगा, आपको नहीं लगता?

Answer 24

निम्नलिखित दो स्थितियाँ मौजूद होने पर यह इसके लायक नहीं हो सकता है:

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

यदि 1 या 2 मौजूद नहीं है, तो आप समस्या ट्रैकिंग से लाभान्वित होंगे।

Answer 25

नहीं

कीड़े ट्रैक न करें, उन्हें ठीक ।

यह टीम का आकार नहीं है जो मायने रखता है, यह है कि आप उन्हें ठीक करने से पहले किसी सूची में बग को देखने के लिए कितने समय से तैयार हैं।

यदि आप एजाइल / टीडीडी का उपयोग कर रहे हैं, तो आपकी बग सूची छोटी होगी, और बग लंबे समय तक सूची में नहीं रहेंगे। कोई भी ट्रैकिंग सिस्टम उस स्थिति में पर्याप्त होगा।

Comments

[मुझे बस सभी जवाबों का सामना करने के लिए कुछ कहना था]

— तृफा

आपको याद है कि बग को कैसे ठीक किया जाता है? आपको याद है कि रिलीज़ होने से पहले आपने बग को याद नहीं किया?

— अर्लज़

सॉरी यार, लगता है कि तुम एक बिंदु बनाने की कोशिश कर रहे हो, लेकिन यह लूट है।

— ड्यू

@Steven: कभी 7-अंकों की संख्या के साथ एक उत्पाद था? TDD की कोई भी राशि कई हजार उपयोगकर्ताओं को बग दर्ज करने से नहीं रोकेगी, अकेले कई मिलियन। वे आपके अंत में तय किए जाने वाले असली कीड़े भी नहीं हो सकते हैं, लेकिन आपको अभी भी उन्हें देखना होगा, डुप्लिकेट को बंद करना होगा, ग्राहकों को मूल के समाधानों की ओर इशारा करना होगा आदि। यदि आप एक-आदमी कंपनी हैं, तो आप या तो पेन / पेपर, एक्सेल, अपने खुद के डीबी का सहारा लेना पड़ता है - या आप बस इसके लिए बने कुछ सॉफ्टवेयर का उपयोग करते हैं।

— sbi

@ संदर्भ: मेरी मानसिक योग्यताएँ जिम की अस्थिर ज़रूरतों को देखने में विफल हैं (और आपकी व्याख्या का संकेत देने वाले प्रश्न में निश्चित रूप से कुछ भी नहीं है)।

— sbi