बग फिक्सिंग कार्यों के लिए कहानी अंक: क्या यह स्क्रैम के लिए उपयुक्त है?


50

मैं सोच रहा हूं कि क्या हमें बग फिक्सिंग कार्य करने के लिए कहानी बिंदुओं को असाइन करना चाहिए या नहीं। JIRA, हमारे मुद्दों पर नज़र रखने वाले सॉफ़्टवेयर में बग प्रकार के मुद्दों के लिए कहानी बिंदु फ़ील्ड नहीं है (यह केवल स्टोरी एस और एपिक s के लिए है)।

क्या हमें कहानी अंक फ़ील्ड के लागू समस्या प्रकारों में बग समस्या प्रकार जोड़ना चाहिए ? पक्ष और विपक्ष क्या होते हैं? क्या यह स्क्रैम के लिए उपयुक्त होगा?


1
FYI करें, हालाँकि बग्स को डिफ़ॉल्ट रूप से इंगित नहीं किया जा सकता है , जिसे Jira में बदला जा सकता है
दोगुना 1

जवाबों:


55

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

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

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

तो हाँ, हर तरह से, बग को कहानी अंक असाइन करें। आप बग बनाम फीचर्स, और बग के खिलाफ बग को प्राथमिकता कैसे दे रहे हैं? आपको दोनों के लिए विकास के प्रयास के कुछ माप की आवश्यकता है, और यह तुलनात्मक रूप से बेहतर है।

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


3
मैं एक उत्तर लिखने के बीच में था जो आपके लगभग समान था। मुझे आपका स्पष्टीकरण बेहतर लगा।
मेपल_शॉफ्ट

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

6
@ThomasOwens: ठीक है, मुझे लगता है कि rephrase। मेरे कहने का मतलब यह है कि किसी भी बदलाव बनाम इसके विकास के प्रयास के लाभ के लिए कहानी के बिंदुओं की आवश्यकता होती है। बेशक लाभ प्रयास के रूप में प्राथमिकता देने में उतना ही महत्वपूर्ण है।
tdammers

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

19

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

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

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


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

19

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

बग फिक्सिंग का वेग पर नकारात्मक प्रभाव पड़ता है। अन्यथा छोड़ने की गुणवत्ता एक अप्रभावित या यहां तक ​​कि बढ़े हुए वेग के साथ पुरस्कृत हो रही है!

शायद एक उपयोगी लिंक:

http://www.infoq.com/news/2011/01/story-points-to-bugs


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

4
वेग (कहानी प्रति अंक में मापा जाता है) मापता है कि स्प्रिंट में टीम कितना सामान लगा सकती है। मुझे यकीन है कि प्रत्येक उत्पाद स्वामी का ध्यान रहता है, और टीम द्वारा उत्पादित व्यवसाय मूल्य में कितनी अधिक दिलचस्पी है। बग फिक्स स्टोरी पॉइंट देने से बिजनेस वैल्यू नहीं बढ़ पाती है।
Buhb

4
@bhb कहानी अंक व्यावसायिक मूल्य के बारे में कुछ नहीं कहते हैं। 5 अंक की कहानी में 100 व्यावसायिक मूल्य हो सकते हैं। 100 अंक की कहानी में 1 व्यावसायिक मूल्य हो सकता है। यह व्यावसायिक मूल्य नहीं के प्रयास को व्यक्त करता है।
Joppe

3
@ तुंगानो: बिल्कुल। यही कारण है कि बग फिक्स को पॉइंट असाइन करना बगगी सॉफ्टवेयर बनाने के लिए मजबूत प्रोत्साहन नहीं देता है।
Buhb

4
बग फिक्स सहित फुलाया हुआ वेग एक और समस्या का कारण बनता है: यह भविष्य में प्रोजेक्ट करने के लिए वेग का उपयोग करने की आपकी क्षमता को नष्ट कर देता है। वेग इस बात का एक मापक होना चाहिए कि टीम कितनी जल्दी काम करने के लिए तैयार हो सकती है, न कि यह वास्तव में कितना काम था।
क्रिस पिटमैन

8

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

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

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


5

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

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

बेशक, बग या कहानी, व्यापारिक पक्ष से यह कोई फर्क नहीं पड़ता कि टीम किसके साथ काम कर रही है। दोनों उत्पाद के मालिक के लिए बराबर मूल्य का उत्पादन कर सकते हैं।

हमारी टीम में हमने बग का आकलन करने के लिए कुछ तकनीकों के साथ प्रयोग किया है:

  1. पूरी तरह से अज्ञात बग का अनुमान लगाना
  2. केवल उन बगों का आकलन करना जो पहले से ही विश्लेषण किए गए थे
  3. बग फिक्सिंग के लिए समय आवंटित करना और बग्स का आकलन नहीं करना, बल्कि उन्हें केवल व्यावसायिक मूल्य के आधार पर रैंक करना

1. के साथ हम बुरी तरह से विफल रहे हैं। अधिकांश बगों के लिए हमने पाया है कि बग विश्लेषण पर 90% समय व्यतीत होता है। उसके बाद बग फिक्स का अनुमान कहानी की तरह लगाया जा सकता है। एक स्प्रिंट में कीड़े की योजना बनाकर हमने यह गलती की कि अज्ञात गुंजाइश ने कहानी के रिज़ॉल्यूशन को तब तक प्रभावित किया जब तक कि लगभग हर स्प्रिंट ने इस तरह से विफल कर दिया।

90/10 अनुपात (बग फिक्सिंग के लिए विश्लेषण) आकलन तकनीक विकल्प 2 के आधार पर 2. इसका मतलब था कि हमें विश्लेषण की योजना बनानी थी जो कुछ ऐसा नहीं था जो स्प्रिंट योजना के लिए कवर किया गया था (हमने विकल्प 1 से सीखा था, लेकिन कोई वास्तविक समाधान नहीं था कैसे विश्लेषण कीड़े के साथ जाने के लिए)। इसका परिणाम यह हुआ कि बग विश्लेषण नहीं किया गया क्योंकि एक स्प्रिंट इसके बजाय नियोजित वस्तुओं पर केंद्रित था। टीम के पास बैकलॉग से बग पर ध्यान देने का समय नहीं था। इसलिए अंतत: वे दोनों नहीं हुए।

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

अनिश्चितता को बाहर निकालकर इसने टीम को फिर से मुक्त किया। अज्ञात कीड़े द्वारा स्प्रिंट से समझौता नहीं किया गया था। एक अलग बैकलॉग में कीड़े को अलग करके दोनों ने टीम के नियमित स्प्रिंट फ़ोकस को बढ़ाया और हमें ऐसे कीड़े खत्म कर दिए जिनमें महत्वपूर्ण व्यावसायिक मूल्य भी शामिल थे।

तो यह निर्भर करता है कि कहानी के अंक आपके लिए उपयुक्त हैं या नहीं। मैं कहानी के बिंदुओं का उपयोग करके कीड़े का अनुमान लगाने की कोशिश करूंगा। यदि वह विफल रहता है तो मेरा विकल्प आज़माएं 3. इसने हमारी (30 से अधिक स्प्रिंट पुरानी) टीम को पुराने बग पर फिर से ध्यान केंद्रित किया है जिसमें महान व्यावसायिक मूल्य शामिल हैं। इसने हमें कुछ देने की कोशिश करने से भी मुक्त कर दिया है जिसका टीम केवल अनुमान नहीं लगा सकती। यह अज्ञात को गले लगा रहा था जो हमें वास्तविकता के करीब ले गया और बग फिक्स के माध्यम से व्यापार मूल्य के एक बड़े चंक (कहानी के अनुपात के आधार पर) को वितरित करते हुए हमारे स्प्रिंट को फिर से सफल बनाया । हमने हाल ही में जिस अनुपात का उपयोग किया वह 50/50 था।


4

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

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

एक और तरीका है, क्यों भी कीड़े को ट्रैक? ताकि दिन के अंत में आपको पता चले कि प्रत्येक सदस्य ने कितना "काम" किया है? बंद करो! खराब मैनेजर! :) टीम को मापें, खिलाड़ी को नहीं। यदि कोई व्यक्ति अपना वजन नहीं बढ़ा रहा है, तो टीम को स्वयं को प्रबंधित करने के लिए प्रोत्साहित करें। बहुत अधिक प्रभावी। कहानी बिंदु वस्तुओं को करने से किसी व्यक्ति को बेहतर महसूस नहीं करना चाहिए, लेकिन एक पूरे के रूप में टीम को बेहतर महसूस करना चाहिए जब वे स्प्रिंट के अंत में अपनी प्रतिबद्धता बनाते हैं। खेल में, क्या टीम या व्यक्ति के लिए लक्ष्य अच्छा है? यदि व्यक्ति अपने लिए खेलता है तो टीम लंबे समय में हार जाती है।

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


3

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

दोष को ठीक करना एक पठनीय आकलन योग्य कार्य नहीं है क्योंकि इसमें कई अज्ञात घटक होते हैं। क्या दोष पैदा कर रहा है? एक बार कारण समझ में आने के बाद, इसे कैसे तय किया जा सकता है? इस परिवर्तन का बाकी व्यवस्था पर क्या प्रभाव पड़ता है? इस दोष को ठीक करने के लिए आपने कितने नए दोषों का इंजेक्शन लगाया?

ध्यान रखें कि दोष का कारण सॉफ्टवेयर जीवनचक्र में किसी भी बिंदु से आ सकता है - गलतफहमी या गलत आवश्यकताएं, खराब डिजाइन या गलत धारणाएं, खराब कोडिंग, खराब परीक्षण, वर्तमान रिलीज से सीखी गई जानकारी के आधार पर समस्या के बारे में नया ज्ञान ...

बग फिक्सिंग कार्यों के लिए अलग-अलग तरीकों से एक बजट तैयार किया जा सकता है। यहाँ कुछ विचार हैं जिनका मैंने प्रभावी ढंग से उपयोग किया है:

  • बग फिक्सिंग के लिए एक तरफ सेट करने के लिए कितना समय है यह समझने में आपकी मदद करने के लिए ऐतिहासिक डेटा (पिछले पुनरावृत्ति से कहो) का उपयोग करें।
  • बगफिक्सिंग के "ब्लॉक" (5 अंक या 20 घंटे कहें) को अपने बैकलॉग में रखें और ग्राहकों को कहानियों के बदले में इसे चुनने दें।
  • यह आवश्यक है कि आपकी टीम का प्रत्येक सदस्य निर्दिष्ट समय पर प्रत्येक पुनरावृत्ति दोषों को निर्धारित करे।

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

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

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


2

कहानियों और बगों और कामों और प्रत्येक बिंदु पर ध्यान केंद्रित करने के बजाय, मुझे ग्राहक के लिए सुविधाएं देने पर ध्यान केंद्रित करना बेहतर लगता है।

ग्राहकों को उम्मीद है कि सॉफ्टवेयर काम करेगा और केवल विकास, संवर्द्धन और नई सुविधाओं को वास्तविक मूल्य देगा क्योंकि ये व्यवसाय को आगे बढ़ाते हैं।

बग फिक्स, जितना महत्वपूर्ण हो सकता है, व्यवसाय को नए क्षेत्रों और नए ग्राहकों (आगे और अंततः शायद हां लेकिन तुरंत नहीं जो प्रबंधन को माप रहा है) में ड्राइव न करें।

इसलिए अंक को उच्च गति के दृष्टिकोण से देखा जाता है और प्रति सप्ताह कितने अंक ऐतिहासिक रूप से इसी तरह की कहानियों के लिए किए गए हैं।

यह इस सप्ताह की कहानियों को पूरा करने के लिए तत्काल आवश्यकता को धक्का देने के बजाय ट्रैक रिकॉर्ड इतिहास द्वारा एक प्रबंधन को जन्म दे सकता है और अक्सर यह पाता है कि वे नहीं हैं। हालाँकि, अप-फ्रंट कंट्रोल की हानि और विश्वास में वृद्धि हुई है कि इसके लिए कुछ प्रबंधकों को डरावने तरीके से दरवाजे के लिए चलना होगा।

मैं Pivotal ट्रैकर का उपयोग करता हूं (मैंने अभी JIRA, Trak, Trello और अन्य भी) और Pivotal Tracker भी काम या बग के लिए अंक नहीं करता है। यह ऊपर दिए गए उन्हीं अच्छे कारणों के लिए किया गया है जो JIRA में भी सही हैं क्योंकि आप खुद देख रहे हैं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.