स्प्रिंट आइटम को पूरा होने में अधिक समय लगता है। क्या करे?

Question

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

ऐसी स्थिति में हमें चाहिए

• उत्पाद सूची में स्प्रिंट से आइटम को हटा दें ताकि हम स्प्रिंट समयरेखा को पूरा कर सकें?
• आसान स्प्रिंट आइटम पर जाएं और समयावधि के अंत तक समस्याग्रस्त स्प्रिंट को छोड़ दें
• स्प्रिंट समीक्षा में औचित्य क्यों है कि आइटम केंट वर्तमान स्प्रिंट में हितधारकों को पूरा नहीं किया जा सकता है?

हम भविष्य में ऐसी स्थिति से कैसे बच सकते हैं? क्या यह अग्रिम योजना की कमी के कारण है या हमने स्प्रिंट आइटम को छोटी वस्तु में तोड़ने का प्रयास नहीं किया है?

Comments

क्या करे? हमें इसके बारे में सोचना चाहिए।

— rwong

हमें इसके बारे में सोचना चाहिए, और इसके बारे में बात करनी चाहिए ।

— ब्रायन ओकली

हमें इसके बारे में सोचना चाहिए, इसके बारे में बात करनी चाहिए और यह तय करना चाहिए कि भविष्य के अनुमानों के लिए हमें क्या बदलना चाहिए ।

— माइकल डुरंट

आइटम को परिभाषित करें .. क्या यह उपयोगकर्ता की कहानी की तरह एक कार्य या उत्पाद बैकलॉग आइटम है।

— असीम गफ्फार

Answer 1

"आइटम" के साथ, मुझे लगता है कि आप "कार्य" का मतलब है।

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

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

Comments

मैं नहीं कहूंगा "तब बहुत बुरा"। यह बुरा नहीं है, यह सिर्फ डेटा है जिसे टीम अगले नियोजन सत्र में उपयोग कर सकती है।

— ब्रायन ओकले

Answer 2

हमें क्या करना चाहिए अगर किसी वस्तु में अधिक समय लगता है तो उम्मीद की जाती है?

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

एक अन्य विकल्प, यदि कहानी काफी बड़ी है, तो इसे लंबवत रूप से स्लाइस करना है । उदाहरण के लिए, कहानी "उत्पाद सूची खोज", संभवतः "श्रेणी द्वारा खोज" और "पूर्ण पाठ खोज" में विभाजित की जा सकती है, लेकिन "खोज रूप" और "खोज परिणाम" में नहीं।

हम भविष्य में ऐसी स्थिति से कैसे बच सकते हैं?

इसका कोई आसान सीधा जवाब नहीं है। घोटाले में आप प्रत्येक पुनरावृत्ति को स्प्रिंट करते हैं, जहाँ आप आमतौर पर टीम के साथ इस प्रकार की बातों पर चर्चा करते हैं। कई अलग-अलग संभावनाएं हैं:

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

आदि आदि।

Answer 3

आप कहते हैं कि आप इसे पूरा नहीं करेंगे, लेकिन यह बुरा नहीं है, यह सिर्फ डेटा है।

"स्प्रिंट टाइमलाइन को पूरा करें" एक लक्ष्य नहीं है। आपका लक्ष्य उपयोगकर्ता कहानियों को पूरा करना है। समयरेखा सिर्फ एक उपकरण है जो आपको मापने और सीखने में मदद करता है कि आप स्प्रिंट में कितना काम कर सकते हैं।

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

अपने पूर्वव्यापी में सुनिश्चित करें कि आप चर्चा करते हैं कि क्या गलत हुआ ताकि आप भविष्य में अपने अनुमानों में सुधार कर सकें।

Comments

ओपी यह नहीं पूछ रहा है कि विकास या डिलीवरी के मामले में क्या करना है। वह जो पूछ रहा है वह कार्यप्रणाली में इस स्थिति को कैसे प्रतिबिंबित करता है, इसलिए "यह सिर्फ डेटा है" का जवाब देना सवाल का जवाब नहीं है।

— स्किलिविज़

@sklivvz: मुझे लगता है, लेकिन मेरा कहना यह है कि आपको इसे कार्यप्रणाली में प्रतिबिंबित करने के लिए कुछ विशेष नहीं करना चाहिए - यह पहले से ही कहानी के गुण से परिलक्षित होता है जो पूरा नहीं हो रहा है। यह सब (IMHO) किया जाना चाहिए। Scrum विशेष परिस्थितियों के लिए विशेष नियम होने के बारे में नहीं है। जैसे ही यह आता है, डेटा को ट्रैक करें और भविष्य में बेहतर योजना बनाने में मदद करने के लिए डेटा का उपयोग करें।

— ब्रायन ओकले

Answer 4

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

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

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

Answer 5

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

इस तरह हम डेवलपर पर सारा दोष बहुत धीमे होने के लिए नहीं डालते हैं, लेकिन हम यह भी स्वीकार करते हैं कि कार्य को गलत तरीके से डिजाइन किया गया था।

एक और बात यह हो सकती है कि अपने विकास दल के किसी अन्य सदस्य को अपने दिवंगत डेवलपर को छेद में खोदने से बचने के लिए कार्य सौंपा जाए। और अगर कार्य वास्तव में महत्वपूर्ण है तो कुछ XP समाधान हो सकते हैं।