टीम कहानी बिंदुओं का आकलन कर रही है, व्यवसाय वास्तविक समय चाहता है

Question

मुझे यकीन है कि यह एक असामान्य विषय नहीं है। हमारे पास दो स्क्रैम टीमें हैं जो कहानी के बिंदुओं का उपयोग करके उपयोगकर्ता कहानियों का अनुमान लगाने का एक अच्छा काम कर रही हैं (वर्तमान टीम के तारामंडल केवल 8 महीने पुराने हैं, हालांकि टीम के सदस्यों के पास कई वर्षों का अनुभव है)। लेकिन कंपनी के व्यावसायिक भाग के लिए उपयोगकर्ता कहानियों से संबंधित होना कठिन है; वे वास्तविक समय इकाइयां चाहते हैं (या "कहानी के बिंदुओं को घंटों में बदलने के लिए एक सूत्र") ताकि वे इस बात की योजना बना सकें कि चीजें कब तैयार होंगी ( "हमें यह जानने की आवश्यकता है कि हम ग्राहकों को कब बता सकते हैं कि फीचर एक्स उत्पादन में होगा ” )।

मैंने और मेरे स्कैम मास्टर पूर्ववर्तियों ने, निश्चित रूप से समझाया कि "कहानी के बिंदुओं और वास्तविक समय के बीच कोई निश्चित संबंध नहीं है" और "कहानी अंक का उपयोग यह निर्धारित करने के लिए किया जाता है कि टीम स्प्रिंट में कितनी फिट हो सकती है", और मैं हूँ सुनिश्चित करें कि आप अनुमान लगा सकते हैं कि वे उस उत्तर से कितने संतुष्ट थे। वे अभी भी जानना चाहते हैं, कैलेंडर समय में, जब हम बैकलॉग पर उस 27 वीं उपयोगकर्ता कहानी को प्राप्त करेंगे।

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

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

मेरे पास दोनों (ए) और (बी) में सुधार करने की योजना है लेकिन मुझे लगता है कि यह पर्याप्त नहीं है, कि व्यापार को उम्मीद है कि इन पहलों की तुलना में "अधिक संक्षिप्तता" होगी।

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

(ऐतिहासिक रूप से, योजना बनाने के दौरान हमने उपयोगकर्ता कहानियों को काम की वस्तुओं में तोड़ दिया, जो तब व्यक्तिगत काम के समय में व्यक्तिगत रूप से अनुमानित थे , लेकिन मैं यहां जो बात कर रहा हूं वह उपयोगकर्ता की पिछली पीठ पर मौजूद कहानियां हैं, जिनमें उस स्तर का विवरण या विराम नहीं होगा। -down।)

अद्यतन: मेरे प्रबंधक का एक कूबड़ था कि घंटे-खर्च-प्रति-कहानी-बिंदु के घंटी वक्र वितरण का एक प्रकार था, लेकिन जो डेटा मैंने टकराया और उसने जो रेखांकन किया, उसने उस धारणा का पूरी तरह से खंडन किया। :-)

Comments

मैं वास्तव में इस बारे में उत्सुक हूं, क्योंकि मेरी टीम सपा में कूदने के कगार पर है। 2-SP इतना अस्थिर क्यों है? क्या आपने इसे 2-एसपी को नहीं सौंपा है क्योंकि आप कार्य को एक क्विक होने का अनुमान लगाते हैं? यदि हां, तो अस्थिरता तब भी रहेगी, भले ही आपने समय के साथ गणना की हो। सिवाय आपको एक टिकट पर दो सप्ताह बिताने के रूप में देखा जा सकता है जहाँ आपने सोचा था कि आपको 3 दिन लगेंगे। यह दोनों मापों पर एक ही अस्थिरता है, है ना?

— एलेक

यदि आपके पास पहले से ही 27 अगली कहानियां प्राथमिकता और अनुमानित हैं तो आप बता सकते हैं कि 27 वीं कहानी किस स्प्रिंट में जानी चाहिए? और वह अनुमानित डिलीवरी की तारीख देगा। बेशक आप गलत साबित होंगे लेकिन यह आपका वर्तमान अनुमान है। मुझे किसकी याद आ रही है?

— मोनिका

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

— मोनिका

हो सकता है कि 27 वें आइटम को सर्वोच्च प्राथमिकता पर ले जाने की आवश्यकता हो?

— एंडी

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

— जिम्मीजम्स

Answer 1

आप सही हैं, कहानी के बिंदुओं को घंटों में बदलने का कोई सूत्र नहीं है। आप मीटर से पैरों तक एक बहुत ही दोषरहित रूपांतरण प्राप्त कर सकते हैं, और इसके विपरीत, लेकिन आप यह नहीं कह सकते हैं कि एक 3 बिंदु कहानी को X घंटे लगेंगे, इसलिए 5 बिंदु वाली कहानी Y घंटे (Y के लिए समाधान) लेगी।

HorusKol ने इसके अगले भाग को छुआ। एक टीम के रूप में आपका स्प्रिंट वेग लंबी अवधि के वितरण के साथ मदद कर सकता है। कहें कि आपकी टीम प्रति स्प्रिंट 50 अंक पर है, और प्रत्येक स्प्रिंट 2 सप्ताह है। तो प्रति वर्ष 50 अंक प्रति वर्ष 50 सप्ताह से गुणा किया जाता है (यह मानते हुए कि लोग छुट्टियों के लिए 2 सप्ताह का समय लेते हैं) तो आपकी वर्तमान टीम 12 महीनों में अधिकतम 2,500 अंक कर सकती है।

इसलिए व्यवसाय आपके लिए 170 अंकों की कहानियों और महाकाव्यों के साथ आता है। विभाजित करें कि टीम के 50 अंकों (अब तक के हर स्प्रिंट का औसत) के ऐतिहासिक वेग से और आपको 3.4 स्प्रिंट मिलते हैं। चूँकि हम एक अनुमान लगा रहे हैं, इसीलिए 4 गोलाकार: 8 सप्ताह तक। दो महीने, मूल रूप से। मैं अंतिम 3-4 स्प्रिंट लेना और दूसरा अनुमान लेना भी पसंद करता हूं। मान लीजिए कि पिछले 3 स्प्रिंट में आपकी टीम ने क्रमशः 53, 67 और 55 अंक बनाए हैं। यह 58-इश बिंदुओं पर काम करता है, जो उस दर पर 2.9 स्प्रिंट है - इसलिए मूल रूप से 3 स्प्रिंट। उन 170 बिंदुओं के लिए आपकी समयावधि 6 से 8 सप्ताह की लग रही है।

व्यवसाय को 2 महीने बताएं। उन्हें 6-8 सप्ताह न बताएं, क्योंकि वे सिर्फ "6 सप्ताह" सुनेंगे। उन्हें 8 सप्ताह भी न बताएं, क्योंकि अधिकांश महीनों में लगभग 4.5 सप्ताह होते हैं, और जब लोग "4 सप्ताह" सुनते हैं, तो वे तुरंत "महीने" सोचते हैं। एक बार एक अनुमान के बारे में 4 सप्ताह हिट, यह 1 महीने हो जाता है। फिर सिर्फ महीनों में काम। यदि आप एक वर्ष या उससे अधिक समय तक ईमानदारी से काम करते हैं, तो बस उस काम का अनुमान न लगाएं। यह व्यर्थ है। एक साल में बहुत कुछ बदल सकता है।

मैंने इसे कहानी बिंदुओं को घंटों में बदलने का एक सटीक तरीका पाया है ... अच्छा समय, किसी भी तरह।

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

ओह, और सबसे महत्वपूर्ण हिस्सा मत भूलना:

बढ़ाना। हमेशा।

Comments

यदि आप अपने 90%, 95% और 99% विश्वास अंतरालों को परिभाषित करने के लिए आँकड़ों के कुछ ज्ञान का उपयोग कर सकते हैं तो यह बहुत अच्छा होगा। यह औसत वेग से बेहतर काम करना चाहिए, खासकर जब ऐतिहासिक डेटा अधिक नहीं है और विचरण बड़ा है।

— होसम ऐली

Answer 2

संभवतः आपके पास कहानी बिंदुओं से समय अनुमानों तक कुछ अंतर्निहित रूपांतरण हैं - आप कैसे तय करते हैं कि आपने अपने स्प्रिंट के लिए पर्याप्त काम उठाया है? आपने शायद ऐसा कुछ कहा है "टीम एक सप्ताह में 20 (या 40 या जो भी) बता सकती है"। कुछ स्प्रिंट्स के बाद, आपको इसे पूरा करने में सक्षम होना चाहिए - इसलिए अब यह 15 या 25 (या 35 या 50 या ...) अंक को इंगित करता है - यह आपकी टीम का वेग है ।

1-एसपी उपयोगकर्ता कहानियों के लिए, निश्चित रूप से बहुत कम समय के अंतराल (सामयिक झटका-अप के साथ) के लिए एक भारी पूर्वाग्रह है, लेकिन विशेष रूप से 2-एसपी कहानियों के लिए, वे सभी जगह हैं: 20 का एक कारक है "सबसे तेज़" और "सबसे धीमी" पूर्णताओं के बीच। 3, 5 और 8-एसपी कहानियों के लिए, प्रसार भी 2 के एक कारक से अधिक है।

विशिष्ट कहानियों को पूरा करने के लिए समय पर कुछ भिन्नता अंक मूल्यों के भीतर ठीक है - वेग हाल के इतिहास पर औसत होने से उस अनिश्चितता के बाद दिखता है।

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

चूंकि सभी कार्यों को एक ही बिंदु मान सौंपा गया है, उन्हें समान प्रयास की आवश्यकता है, यह समझ में नहीं आता है कि पूरा करने के लिए कई बार ऐसी सीमा होती है।

तो, 2-पॉइंटर को देखें जो आपके पूर्वव्यापी में सबसे लंबा था। कुछ ऐसा क्यों किया जो शायद 10 दिनों के नारे में एक सुबह में बदल जाना चाहिए था? क्या उस पहली सुबह को कुछ कहा जा सकता है, "यह बनने और महाकाव्य और छोटे कार्यों में टूट जाने की आवश्यकता है"? जैसे ही ऐसा होता है, निश्चित रूप से, आवश्यक अतिरिक्त काम को बैकलॉग में डाल दिया जाना चाहिए और शेष स्प्रिंट के साथ हस्तक्षेप नहीं करना चाहिए।

इसके अलावा, यह देखने की कोशिश करें कि टीम ने उस आइटम को कैसे कम आंका है - क्या आप भविष्य की वस्तुओं पर बेहतर समीक्षा कर सकते हैं?

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

Comments

हाँ कुछ गलत है उन 2-एसपी कार्यों के साथ। मैं यह कहने जा रहा था कि डेवलपर्स ने उन अनुमानों को रखा है जब वे कुछ कठिन पूर्वानुमान कार्य देखते हैं। लेकिन अनुमान क्यों लगाते हैं कि आप उन कार्यों को देख सकते हैं और इसका कारण

— जान सकते हैं

Answer 3

यह मौसम के पूर्वानुमान की तरह है: आगे दूर, कम विश्वसनीय। यह एक सादृश्य है जिसे हर कोई समझ सकता है। अनुमानों में त्रुटियां बढ़ जाती हैं।

बिक्री को ग्राहकों से स्क्रम शर्तों में बात करना सीखना चाहिए। स्क्रम को अलग-थलग करने का कोई मतलब नहीं है, इसे पूरे कंपनी में लंबवत रूप से लागू किया जाना चाहिए और अधिमानतः ग्राहक क्षेत्र में विस्तारित किया जाना चाहिए।

आप एक विकास टीम के रूप में इस पर दृढ़ रहें। आप उन्हें उम्मीदें और अनुमान दे सकते हैं, लेकिन ऐसा नहीं होने देंगे जो एक ही स्प्रिंट का विस्तार करें।

Comments

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

— चार्ल्स ई। ग्रांट

@Charles: तो? एक स्क्रम सेटिंग में आप जो सबसे अच्छा कर सकते हैं, वह है (सेट) फ़ीचर (एस) को उनकी समय सीमा से पहले स्प्रिंट में डालना। यह कहने के लिए कोई मतलब नहीं है "हाँ, हम घबराते हैं, लेकिन जब तक कोई परवाह नहीं करता है"।

— मार्टिन माट

क्या लक्ष्य ग्राहकों की आवश्यकताओं को पूरा करना है या ईमानदारी से एक विकास पद्धति का पालन करना है? मैंने जिस कंपनी में Scrum के लिए काम किया है वह अंत में एक साधन है, अपने आप में अंत नहीं है।

— चार्ल्स ई। ग्रांट

@Charles क्या आप सुझाव दे रहे हैं कि आप जो कर रहे हैं, उसे लेबल नहीं करने से समय में सुधार होगा? किसी भी तरह से लोगों का एक समूह एक कार्य के लिए प्रतिबद्ध है। अंतर केवल इतना है कि आपको पहचानने और संवाद करने में अधिक समय लगता है, आप अपने ग्राहक की समय सीमा को पूरा नहीं करेंगे , यदि इसका परिणाम होना था।

— मार्टिन माट

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

— डैन रे

Answer 4

मैं कुछ चीजें करता हूं जब मुझे इस तरह के सवाल मिलते हैं।

सबसे पहले, मैं अतीत का वर्णन करके भविष्य के बारे में सवालों के जवाब देता हूं। मैं ऐसा कुछ कहूंगा जैसे हम प्रति सप्ताह इनमें से दो कहानियों के माध्यम से प्राप्त करते हैं। इसलिए, अगर कुछ भी नहीं बदलता है, तो हम लगभग 14 सप्ताह में कहानी 27 के साथ किए जाने की उम्मीद करते हैं।

दूसरे, मैं चाहता हूं कि ग्राहक सामना कर रहे लोगों को ट्रेडिंग शेड्यूल बनाम जोखिम की जिम्मेदारी लें। मैं कुछ याद रखना चाहूंगा , इंजीनियरिंग टीम 50/50 अनुमानों के आधार पर काम करती है। अगर कुछ नहीं बदलता है, तो 14 सप्ताह में सुविधा 27 का 50/50 मौका तैयार है। संभवतः आप ग्राहक के लिए जोखिम के स्तर के साथ कुछ रिपोर्ट नहीं करना चाहते हैं। क्या आप चाहते हैं कि मैं एक अनुमान लगाऊं जो हमारे पास है, कहते हैं, 90% आत्मविश्वास में? फिर आपको अपने ऐतिहासिक साक्ष्य की समीक्षा करने और कुछ कहने की आवश्यकता होगी: एक 90% संभावना है कि कहानी 25 सप्ताह में 27 हो जाएगी ।

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

Comments

"बाहरी वादे करना [...] कंपनी की सारी चपलता को दूर कर देता है" - हाँ, हम कुछ लोगों द्वारा बेची गई चीजों को बेच रहे हैं जो वे जानते थे कि हम ऐसा नहीं कर सकते हैं, और इसे हासिल करने के लिए हाथापाई करनी होगी। बिल्कुल आदर्श नहीं।

— KlaymenDK

उस स्थिति में, कुंजी कारण और प्रभाव को स्पष्ट करना है। लोगों से कहें: हम कार्य X पर काम नहीं कर सकते या बग Y को ठीक नहीं कर सकते क्योंकि हम बिक्री की समय सीमा को पूरा करने के लिए प्रतिबद्ध हैं । अगर बिक्री काफी मूल्यवान है, तो टीम को सही निर्णय देना था। यदि बिक्री अन्य कार्यों की तुलना में कम मूल्यवान है, तो यह स्पष्ट करें कि अधिक मूल्यवान कार्य क्यों नहीं किया जा रहा है।

— John_C

Answer 5

आपके पास पहले से ही एक (बहुत क्रूड) रूपांतरण है:
स्क्रम स्प्रिंट दो सप्ताह के लिए हैं।
आप जानते हैं कि आप समाप्त कर सकते हैं, आइए बताते हैं, उन दो हफ्तों में लगभग 20 स्टोरी पॉइंट्स फीचर्स हैं (या आप यह कैसे निर्धारित करते हैं कि एक स्प्रिंट में क्या और कितनी सुविधाएं मिलती हैं?) और आपके पिछले स्प्रिंट उस अनुमान की पुष्टि करते हैं (आइए बताते हैं? आपने पिछले पाँच स्प्रिंट में 18, 21, 23, 19 और 20 स्टोरी पॉइंट्स की सुविधाएँ समाप्त कीं)।

मान लें कि सुविधा X (और इसकी सभी निर्भरताएं) 47 कहानी बिंदुओं के रूप में अनुमानित की गई हैं।
तो आप अनुमान लगा सकते हैं कि यदि आप इसे लागू करते हैं, तो सर्वोच्च प्राथमिकता पर आपको लगभग 3 स्प्रिंट्स लेने चाहिए, यानी 6 सप्ताह (लेकिन यह सुनिश्चित करें कि आपके अनुमानों को ध्यान में रखा जाए कि कौन क्या कर सकता है - यदि उन बिंदुओं में से 35 डीबी कार्य हैं और आपके पास केवल हैं DB आदमी पर आपको उस खाते में लेने के लिए अपने अनुमानित वेग को संशोधित करने की आवश्यकता है)।

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

" वाई की सुविधा कब होगी ?"
"अगर हम अगले पर ध्यान केंद्रित करते हैं ... 12 सप्ताह"
" 12 सप्ताह?? आपने कहा कि यह 4. लगेगा।"
"हाँ, लेकिन आपने हमें फ़ीचर एक्स को प्राथमिकता देने के लिए कहा था , जो हमने आपको बताया था कि हमारे सभी संसाधनों को बांध देगा और 8 सप्ताह लगेगा।"
"क्या आप फीचर X पर काम नहीं कर सकते और उसी समय Y की सुविधा दे सकते हैं?"
" कराहना "

Comments

"कराहना" के बजाय: "निश्चित रूप से, हम कर सकते हैं। एक्स को 16 सप्ताह लगेंगे और वाई को 8 सप्ताह लगेंगे"।

— gnasher729

Answer 6

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

4 सप्ताह से अधिक सब कुछ परिवर्तन के अधीन है और व्यवसाय रोडमैप बना सकता है जो घंटों में सेट नहीं होता है। प्रति स्प्रिंट की योजना बनाई जानी चाहिए, कुछ एपिक 1 (समूह की कहानियों के जीरा समूह के रूप में महाकाव्य) और महाकाव्य 2 को स्प्रिंट 47 और 48 में किया जाना चाहिए और महाकाव्य 3 को स्प्रिंट 49 में किया जाना चाहिए। महाकाव्यों का अनुमान है कि मैं अपने स्वयं के घंटों में लगभग अनुमान लगाता हूं। देखें कि क्या एक या दो स्प्रिंट में फिट होंगे, समयरेखा वैसे भी खिसकने वाली है। यदि सुविधाएँ काम नहीं कर रही हैं तो व्यवसाय को गुंजाइश में कटौती करनी होगी या सही समाधानों को स्वीकार नहीं करना चाहिए जिन्हें बाद में आवश्यकतानुसार सुधारा जा सकता है (जो कि योजना के अनुसार चुस्त होना चाहिए, वास्तविकता का अनुसरण करना चाहिए)।

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

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

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

Answer 7

नई सुविधाओं के लिए आवश्यक समय का अनुमान लगाना लगभग असंभव है।

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

यही कारण है कि SCRUM केवल समस्या की जटिलता (कहानी अंक) का अनुमान लगाता है, लेकिन समय नहीं। एकमात्र मौका जो आपके पास है वह उच्च जटिलता के साथ छोटे लोगों में सुविधाओं को विभाजित कर रहा है। इस तरह आप जोखिम को कम कर सकते हैं।

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

SCRUM में, उत्पाद स्वामी प्रत्येक स्प्रिंट से पहले बैकलॉग आइटम की प्राथमिकताओं को बदल सकता है। इसलिए SCRUM मास्टर एक से अधिक स्प्रिंट के लिए कोई अनुमान नहीं दे सकता है। वह नहीं जानता कि अगले स्प्रिंट में कौन सा बैकलॉग आइटम महत्वपूर्ण हो सकता है।

SCRUM असंभव चीजें करने की योजना (अनियंत्रित योजना) या तेजी से विकास करने का तरीका नहीं है। अगर विकास समय से चल रहा है तो यह एक प्रारंभिक चेतावनी प्रणाली है। यह नई आवश्यकताओं पर जल्दी से प्रतिक्रिया करने की अनुमति देता है।

प्रारंभिक पोस्ट के लिए:

आप पहले से ही बहुत अच्छे हैं यदि आप अपने अधिकांश कार्यों को 1 एसपी से 5 एसपी की कहानियों में विभाजित करते हैं। यदि कार्य समान हों और आपकी टीम अधिक अनुभवी हो, तो वेग का अनुमान बेहतर हो सकता है। लेकिन अगर नई वस्तुओं में हमेशा नए, अनकॉनव पार्ट्स होते हैं, तो आपको अशुद्धि के साथ रहना होगा।

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

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