वेग समय के साथ पठार नहीं करता, क्यों?

11

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

यहाँ छवि विवरण दर्ज करें

agile scrum

— Pomario
स्रोत

10

यह बुरा क्यों लगता है? अधिकांश परियोजनाएं आसान-से-हल करने वाली समस्याओं की झड़ी के साथ शुरू होती हैं और फिर बाद में पीछे हट जाती हैं क्योंकि कुछ प्रारंभिक धारणाएं गलत साबित होती हैं और बाद की समस्याओं को हल करने के लिए उन्हें ठीक करना पड़ता है।

— ब्लफ़ल

1

आपकी टीम प्रति स्प्रिंट 1000 अंक करती है?

— ब्रायन ओकले

@BryanOakley 100 अंक / स्प्रिंट की तरह दिखता है। मैं "संचित मूल्य" होने के लिए शीर्ष पंक्ति लेता हूं।

— कालेब

"अंक" जानबूझकर अनियंत्रित हैं - भले ही यह प्रति अंक 1000 अंक हो, इसका मतलब यह हो सकता है कि एक बिंदु शायद दस मैन-मिनट या ऐसा ही कुछ है।

— तदमर्स

1

@KirkBroadhurst ध्यान से देखिए। कुंजी में 'वेलोसिटी' के रूप में चिह्नित लाइन ठोस काले रंग की है और ग्राफ में नीचे की रेखा से मेल खाती है। रेखा ने 'Acc। कुंजी में मान 'ग्रे' है, जैसे ग्राफ में शीर्ष रेखा। आप निरीक्षण द्वारा यह भी बता सकते हैं कि शीर्ष रेखा के नीचे डेटा बिंदुओं के कुल चलने की संभावना है: रेखा हफ्तों में सपाट होती है जब नीचे की रेखा शून्य (स्प्रिंट 6, 9, 15 ...) के पास होती है, जब लगातार ढलान होती है नीचे की रेखा समतल है (3-6, 10-13 तक स्प्रिंट), और कभी भी घटती नहीं है।

— कालेब

20

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

टीम अपने हाल के वेग के आधार पर अपने कहानी बिंदु अनुमानों को समायोजित करने की कोशिश कर रही है, बजाय इसके कि कहानी बिंदुओं को स्थिर रखे और कितनी कहानियाँ लेती हैं, उन्हें समायोजित करें।
आप कहानियों को छोटा नहीं कर रहे हैं।
आपकी कई कहानियाँ उच्च ग्रैन्युलैरिटी में हैं। उदाहरण के लिए, आपके पास बहुत से 20 पॉइंटर्स हैं जिन्हें आप या तो 13 या 40 में बदलने के लिए अनिच्छुक हैं।
आपके पास बहुत सारी "हैंगओवर" कहानियां हैं जो एक स्प्रिंट में समाप्त नहीं होती हैं।

— कार्ल बेवफेल्ड
स्रोत

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

— अर्लज़

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

— कार्ल ब्वेलफेल्ट

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

— अर्लज़

यह बुरा है अगर आपका कोड स्प्रिंट के अंत में shippable स्थिति में नहीं है। स्क्रेम प्यूरिस्ट्स कहानी को स्प्रिंट में खराब करने की योजना बनाने पर विचार करते हैं, भले ही आपका कोड स्प्रिंट के अंत में shippable हो। मुझे व्यक्तिगत रूप से लगता है कि अपनी टीम को फिट करने के लिए प्रक्रिया को अनुकूलित करना बुरा नहीं है।

— कार्ल बेज़ेलफेल्ट

4

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

वेलोसिटी (जो कि एक बहुत गलत अवधारणा है) को यह अनुमान लगाने के लिए एक फॉरवर्ड-लुकिंग टूल के रूप में उपयोग किया जाना चाहिए कि टीम अगले स्प्रिंट में कितनी सुविधाएँ दे सकती है, अर्थात क्षमता नियोजन के लिए वेग का उपयोग किया जाना चाहिए।

http://jimhighsmith.com/velocity-is-killing-agility/

यहाँ लेख से एक प्रमुख उद्धरण है: "समस्या वेग को दिए गए वजन है और इसे एक उत्पादकता उपाय में बदल दिया जाता है।"

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

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

— डेविड एम
स्रोत

2

अतिरिक्त संभावित कारण: बाद के स्प्रिंट के दौरान, आप पहले के स्प्रिंट से तकनीकी ऋण का भुगतान कर रहे हैं।

उदाहरण के लिए, आपके पास स्प्रिंट 3 के बाद एक प्रबंधन डेमो है और खुश-दिन के परिदृश्य को दिखाने की आवश्यकता है। इसे बनाने के लिए, आप बिना यूनिट टेस्टिंग के बिना एरर हैंडलिंग, बिना ट्रांसलेशन सपोर्ट के कोडिंग करते हैं। यह एक वैध निर्णय है, आपको केवल परिणामों के बारे में पता होना चाहिए।

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

— एंड्रियास हुपर्ट
स्रोत

2

आपके प्रश्न के लिए, यह बताना कठिन है कि इसमें उतार-चढ़ाव क्यों है क्योंकि यह कहानी कार्ड, टीम के लोगों या उत्पाद स्वामी की क्षमता के कारण हो सकता है। इसलिए, मेरे अनुभव में, वेग में उतार-चढ़ाव होगा क्योंकि, उदाहरण के लिए:

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

वैसे भी, मेरी राय में, मुझे नहीं लगता कि वेग का उतार-चढ़ाव तब तक महत्वपूर्ण है जब तक हमें पता है कि प्रत्येक स्प्रिंट पर क्या स्थिति है। वेग केवल यह बताने के लिए है कि आपकी टीम कितनी स्थिर हो सकती है। यदि यह स्थिर नहीं है, तो हमें "क्या हुआ" के बारे में प्रत्येक स्प्रिंट का विस्तार से पता लगाना होगा। यह समस्या को स्पष्ट / स्पष्ट करने का एक तरीका है इसलिए हम इसे ठीक करने में सक्षम हैं। इसलिए, वेग हमें यह बताता है कि उस स्प्रिंट में क्या चल रहा था, हम वापस सोचने के लिए और इसे स्थिर बनाने के लिए सुधार कर सकते हैं। वेग परियोजना का एक प्रक्षेपण है। और वेग के उतार-चढ़ाव का मतलब यह नहीं है कि टीम उत्पाद वितरित नहीं कर सकती है, यह आपको भविष्य में प्रक्षेपण के बारे में सोचने में मदद करता है और सब कुछ सुचारू बनाने के लिए हल करने के लिए क्या समस्याएं हैं।

— स्वच्छ
स्रोत

1

आपके वेग में शोर (उतार-चढ़ाव) होता है। संभावित कारण:

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

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

हालांकि, यदि आप शोर (5 लगातार स्प्रिंटों पर औसत रोलिंग) को फ़िल्टर करते हैं, तो आपका वेग 20 स्प्रिंट के बाद भी नीचे जा रहा है। इससे रिलीज प्लानिंग करना मुश्किल हो जाता है और यह जांच के लायक है:

क्या "की गई परिभाषा" बहुत कमजोर है और टीम पिछले स्प्रिंट से बायीं ओर काम कर रही है?
क्या संगठन को घोटाले से बचाने और टीम पर गैर-बैकलॉग काम करने के लिए बेहतर हो रहा है?
पीछे लॉग के निचले हिस्से में बड़ी कहानियों (महाकाव्यों) को शीर्ष पर अधिक विस्तृत कहानियों की तुलना में अधिक आशावादी माना गया था?

— क्रिश वान बाल
स्रोत