स्क्रम में असंबद्ध छोटी बग के पूल को आप कैसे संभालेंगे?

Question

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

एक जोड़े अपूर्ण विचारों हम अब तक लेकर आए हैं:

• एक कहानी है कि कहते हैं है "एप्लिकेशन में तय कीड़े के 90%" जहाँ आप तो लगता है कि कितने कीड़े कि स्प्रिंट में उभरेगा और कितने ठीक किया जा सकता है और फिर इसे प्रत्याशित काम का बोझ
• पर आकार, कहते हैं, 8 कि हमेशा स्प्रिंट के अंत में स्वीकार किया जाता है, जहाँ आप के रूप में आप कर सकते हैं के रूप में कई कीड़े तय की एक कहानी आधारित बिंदु है। यह स्पष्ट रूप से विश्वास का एक बड़ा सौदा है कि सब लोग वास्तव में काम
• रिकार्ड कीड़े की एक 8 की कीमत क्या कर रही है लेकिन अगले स्प्रिंट जब तक उन पर काम नहीं करते की आवश्यकता है। उन्हें अलग-अलग या समूह के रूप में इंगित किया जा सकता है। इसका अधिक "स्क्रमी" होने का लाभ है, लेकिन अनिवार्य रूप से 1 घंटे के फ़िक्स के लिए तीन सप्ताह की देरी का कारण बनता है।

कोई सुझाव?

Answer 1

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

• एक स्प्रिंट के भीतर सभी कहानियों दोष मुक्त आदेश पर विचार किया जाएगा में "किया"
• कोई दोष एक पहले पूरा कहानी के लिए एक स्प्रिंट के दौरान पाए जाते हैं कि लॉग इन कर रहे होना चाहिए:

  यहाँ हम क्या करना है और बैकलॉग में डाल दिया। उनका अनुमान लगाया जाता है कि किसी और चीज की तरह ही उत्पाद मालिक द्वारा प्राथमिकता दी जाती है। यदि कोई उत्पाद स्वामी दोषों पर नई सुविधाओं को प्राथमिकता देता है, तो वे गुणवत्ता और कार्यक्षमता पर कार्यक्षमता चुन रहे हैं।

• हम दोष के कहानी अंक आवंटित नहीं है, लेकिन हम हर दोष का अनुमान है के रूप में यह योजना के एक भाग के रूप में एक स्प्रिंट में स्वीकार कर लिया जाता है है। टीम को टूटी हुई कार्यक्षमता के लिए क्रेडिट नहीं मिलना चाहिए, लेकिन उसी टोकन द्वारा उन्हें ठीक करने के लिए समय लगता है - यह दोनों को पूरा करता है।

यहाँ अपने अन्य समाधान के साथ समस्या यह है:

एक कहानी है कि कहते हैं है "एप्लिकेशन में तय कीड़े के 90%" जहाँ आप तो लगता है कि कितने कीड़े कि स्प्रिंट में उभरने और कितने जाएगा कर सकते हैं और तय किया तो प्रत्याशित काम का बोझ

के आधार पर यह बात फिर से, ऊपर देखें। आप काम की खाली बाल्टी से बचना चाहते हैं जिसे स्प्रिंट के दौरान भर दिया जा सकता है। यह टीम द्वारा परिभाषित प्रतिबद्धता के उद्देश्य को हरा देता है।टीम उस चीज़ को कैसे प्रतिबद्ध कर सकती है जिसे वे नहीं जानते हैं या अनुमानित नहीं हैं?

प्लस, यह आसानी से उत्पाद के मालिक में नियंत्रण से बाहर हो सकता है जो उस बाल्टी को अच्छी तरह से कार्यक्षमता के साथ भरकर "दोष से डिजाइन" कर सकता है जो वास्तव में दोषों के रूप में मजाक कर रहा है।

आकार की एक कहानी है, कहें, 8 जिसे हमेशा स्प्रिंट के अंत में स्वीकार किया जाता है जहां आप जितनी भी बग तय कर सकते हैं। यह स्पष्ट रूप से विश्वास का एक बड़ा सौदा करने की आवश्यकता है कि हर कोई वास्तव में 8 के लायक काम कर रहा है

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

रिकॉर्ड कीड़े लेकिन अगले स्प्रिंट तक उन पर काम न करें। उन्हें अलग-अलग या समूह के रूप में इंगित किया जा सकता है। इसका अधिक "स्क्रमी" होने का लाभ है, लेकिन अनिवार्य रूप से 1 घंटे के फ़िक्स के लिए तीन सप्ताह की देरी का कारण बनता है।

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

Answer 2

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

यदि आप Google को "technical debt" या "broken windows" स्क्रम के साथ Google को देखने के लिए यह देखने के लिए कि इन चीजों को कैसे संभालते हैं, वहां अन्य विचार हो सकते हैं।

Answer 3

मैं दृढ़ता से मानता हूं कि एक प्रक्रिया केवल उतनी ही अच्छी है जितनी स्थिति में सुधार करने की क्षमता है। प्रक्रिया आपके लिए काम करनी चाहिए, न कि दूसरी तरफ।

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

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

Answer 4

मैं पड़ा है निम्न नीतियों अपनी परियोजनाओं में सफल:

• दोष सुधार हमेशा सुविधा विकास की अपेक्षा पसंद किया जाता है। लक्ष्य हर समय शून्य खुले दोषों का है, लगभग काम करने वाली सुविधाओं पर 100% कामकाजी सुविधाओं का मूल्यांकन करना।

• दोष जितनी जल्दी हो सके उतने तय किए जा सकते हैं और उन्हें ठीक किया जाना चाहिए।टिकट को केवल तब दर्ज किया जाना चाहिए जब दोष कुछ गैर-डेवलपर द्वारा पाया जाता है या डेवलपर ढूंढता है, यह तुरंत इसे ठीक नहीं कर सकता है।

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

• स्प्रिंट बैकलॉग बाहरी परिवर्तनों से संरक्षित है, लेकिन टीम स्वयं एक स्प्रिंट के बीच में नई चीजें पेश कर सकती है जो हर समय शून्य दोषों को पूरा करने के लिए आवश्यक होती है।

• यदि कोई दोष फिक्सिंग के लायक नहीं है (कुछ प्राथमिक लागत-लाभ विश्लेषण के आधार पर), तो यह समस्या ट्रैकर को प्रदूषित करने से खुले दोषों को ठीक करने के लिए अनदेखा कर दिया गया। कहानी कार्यान्वयन से अधिक

प्राथमिकता दोष फिक्सिंग समय-समय पर अपने वेग मारा जाएगा, लेकिन यह ठीक है। लंबे समय तक, कहानियों को लागू करने में आपकी दक्षता में वृद्धि होगी क्योंकि कोड बेस में केवल थोड़ा तकनीकी ऋण है।

Answer 5

क्या आपने इन बग्स के कारण अपने पूर्वदर्शी के दौरान पहचाना है? क्या आप इंजीनियरिंग (एक्सपी) प्रथाओं का उपयोग कर रहे हैं यानी, टीडीडी - टेस्ट संचालित विकास कर रहे हैं, ऑटोमैटेड कार्यात्मक परीक्षण प्रतिदिन स्वीकृति मानदंडों के साथ जोड़ी और कहानी कार्ड के साथ पूर्ण प्रतिगमन परीक्षण करेंगे।

जब कोई दोष पाया जाता है, तो रूट की पहचान की जाती है और क्या एक स्वचालित इकाई और कार्यात्मक परीक्षण आपके टेस्ट harnesses में जोड़ा गया है ताकि ऐसा दोष हो सके?

मेरी समझ से, आपकी दोष दर बहुत अधिक है। यदि कोई व्यक्ति कम से कम दैनिक टीडीडी और पूर्ण कार्यात्मक प्रतिगमन परीक्षण करता है, तो यूएटी के दौरान शून्य दोषों तक पहुंचना असामान्य नहीं है।

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

दोष सुधारों की लागत को मापने से, हमने निम्नलिखित संबंधों को देखा है। यदि विकास के दौरान एक दोष लागत 1x है, तो कार्यात्मक परीक्षण के दौरान 2x की लागत तय होती है, उत्पादन में होने पर ठीक करने के लिए यूएटी और 4x के दौरान ठीक करने के लिए 3x। स्वीकृति मानदंडों के साथ कहानी कार्ड लिखकर, कम से कम दैनिक पूर्ण रिग्रेशन परीक्षण के साथ विकासशील विकास, परीक्षण संचालित विकास और स्वचालित कार्यात्मक परीक्षण, आप गुणवत्ता में सुधार करेंगे और लागत को कम कर देंगे। नतीजतन, आपको अपनी टीम की क्षमता से किसी भी समय घटाने की आवश्यकता नहीं होगी जो वेग में सुधार करेगी।

Answer 6

यह स्क्रम परियोजनाओं में ध्वनि इंजीनियरिंग प्रथाओं की मजबूत आवश्यकता का एक अच्छा उदाहरण है।

"[हम कर रहे हैं] छोटे कीड़े कि कोड के बाद प्रकट का एक समूह के साथ मुसीबत में चल रहा है स्वीकार किया गया है"

यह पता चलता है कि आपके "किया की परिभाषा" पर्याप्त मजबूत नहीं है।

यूआई पर इन वर्तनी त्रुटियों दिखाई देते हैं "ये ऐसे वर्तनी त्रुटियों के रूप में बातें शामिल हैं"? जो कोड स्वीकार किया जाता है उसके बाद उन्हें जो भी स्पॉट कर रहा है उसे कोड स्वीकार करने से पहले उन्हें खोजना चाहिए।

दोषों के साथ करने की बात यह है कि 1) उन्हें ठीक करें, 2) सिस्टम को उपकरण दें ताकि अगली बार पहले इसी तरह के दोष पकड़े जाए और 3) अपनी प्रक्रिया में सुधार करें ताकि दोष की ओर जाने वाली त्रुटि की तरह भविष्य में होने की संभावना कम है। ये सभी तकनीकी मुद्दे हैं।

Answer 7

यदि बग आपको स्प्रिंट लक्ष्यों पर काम करना बंद कर देता है तो भी आप पुनरावृत्ति और प्रतिलिपि को रद्द करने का निर्णय ले सकते हैं। लेकिन यह एक शांत कठिन निर्णय है।

Answer 8

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

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

• डेली स्प्रिंट लक्ष्य पर टीम फोकस है, लेकिन एक समय के "बफ़र" (आकस्मिक) बाहरी मुद्दों का ख्याल रखना है। दैनिक स्टैंड-अप पर पीओ दैनिक आने वाले मुद्दों को प्रस्तुत कर सकता है, और टीम के सदस्यों ने स्प्रिंट कार्य पूरा किया है (इसलिए कोई रुकावट नहीं है) आखिर में मुद्दों में से एक को ठीक करने के लिए ले जाएगा।

• वह समय है जो आकस्मिक पर बुक किया गया है, जब अंत में आता है तो उसे बंद करना होगा।

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

यह हमेशा बाहर काम एक उचित सौदा ;-)

हम निम्नलिखित इसका इस्तेमाल होने के लिए: बग और जीने उत्पाद (5-15%), आगामी स्प्रिंट की तैयारी के रखरखाव (क्योंकि यह इस साइट के लिए दायरे के भीतर नहीं है, के रूप में के रूप में परिभाषित 10%) ...

HTH