अधूरी कहानी के अनुमान के साथ क्या करना है?

Question

मैं एक विकास टीम का हिस्सा हूं जो अपेक्षाकृत नया है Scrum, मान लीजिए कि स्प्रिंट के अंत में कुछ बड़ी कहानियां पीओ द्वारा in progressथीं या नहीं थीं accepted।

सबसे पहले, उन उपयोगकर्ता कहानियों के साथ क्या होता है? क्या आप उन्हें अगले स्प्रिंट में ले जाते हैं?

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

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

Comments

मैं एक XP प्रक्रिया के साथ काम करता हूं, और सोचा है कि इस तरह की स्थिति से निपटने का सबसे अच्छा तरीका क्या है

— chrisbunney

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

— थॉमस ओवेन्स

इसे डबल करें और 32 जोड़ें, जैसे C => F

— पॉल

Answer 1

सबसे पहले, उन उपयोगकर्ता कहानियों के साथ क्या होता है? क्या आप उन्हें अगले स्प्रिंट में ले जाते हैं?

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

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

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

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

Comments

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

— ediblecode

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

— थॉमस ओवेन्स

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

— थॉमस ओवेन्स

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

— डेविड थॉर्नले

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

— थॉमस ओवेन्स

Answer 2

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

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

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

Comments

नाइटपिक: अधूरी कहानी के साथ क्या करना है यह निर्णय प्राथमिकता का सवाल है। इस प्रकार मेरा मानना ​​है कि उत्पाद के मालिक को यह तय करना चाहिए, न कि स्क्रैम मास्टर।

— sleske

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

— निर्जन ग्रह

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

— रॉबिन ग्रीन

@ रॉबिनग्रीन मैं आपके महाकाव्य से सहमत हूं और मैं उनका प्रशंसक नहीं हूं। प्रमुख चीजों में से एक (बहुत सारे लोग जिन्हें मैंने अनदेखा कर दिया है) रेट्रोस्पेक्टिव का मूल्य है। हमने हाल ही में JIRA के एजाइल बोर्ड का उपयोग करना शुरू किया और मैं अक्सर टीम के प्रदर्शन के बर्न डाउन चार्ट को दिखाता हूं। अधूरी कहानियों पर चर्चा की जाती है कि क्या और कब होता है और तुरंत बैकलॉग में डाल दिया जाता है। पूर्वव्यापी में, हम देखते हैं कि कहानी अधूरी क्यों थी। संसाधनों की कमी? ज्ञान की कमी? या शायद दोनों का एक ढीला संयोजन।

— उजाड़ ग्रह