स्क्रैम - बैकलॉग को तिरछा किए बिना अगले स्प्रिंट को आंशिक रूप से पूर्ण उपयोगकर्ता कहानी पर कैसे ले जाना है


50

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

क) उपयोगकर्ता कहानी को पूरा करने के लिए बनी हुई कार्य को दर्शाने के लिए कहानी की संख्या को नीचे समायोजित करना। दुर्भाग्य से यह उत्पाद बैकलॉग की रिपोर्ट करने में गड़बड़ करेगा।

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

ग) या तो एक या बी के साथ परेशान न हों और स्प्रिंट प्लानिंग के दौरान अनुमान लगाते रहें कि "उपयोगकर्ता कहानी अच्छी तरह से एक्स स्टोरी पॉइंट्स हो सकती है, लेकिन मुझे पता है कि यह 95% समाप्त हो गया है इसलिए मुझे यकीन है कि हम इसे फिट कर सकते हैं।"


3
के संभावित डुप्लिकेट: programmers.stackexchange.com/questions/107774/... और इसी तरह के programmers.stackexchange.com/questions/128142/...
डैनी Varod

जवाबों:


12

मेरी वर्तमान टीम में हम c) करते हैं।

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

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


यदि आपकी टीम और स्थिति पर्याप्त स्थिर है, तो मैं इस विकल्प को समझदार बना सकता हूं। मेरे पास व्यक्तिगत रूप से इस मुद्दे थे क्योंकि कभी-कभी मुझे एक बिंदु बनाने के लिए स्प्रिंट की तुलना स्प्रिंट मेट्रिक्स से करने की आवश्यकता होती है जो प्रक्रिया या पर्यावरण परिवर्तन से थ्रूपुट पर प्रतिकूल प्रभाव डाल रहा है। क्या यह आपके लिए आता है?
बिल

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

"मैं वास्तविक कारणों को जादुई रूप से प्रकट नहीं करता" => और न ही स्पष्ट कारणों को जादुई रूप से गायब कर देता हूं, मुझे जोड़ना चाहिए।
गुरिल्ला ०१

11

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

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

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


2
"कहानी के लिए नई राशि" भाग को छोड़कर मैं इस सब से सहमत हूं। जब तक कहानी का दायरा नहीं बदला है, कहानी को सौंपे गए मूल बिंदु नहीं बदलने चाहिए। जैसा कि मैंने इसे देखा, उस भाग के बिना, जो आपने लिखा था वह बिल्कुल सी। विकल्प है
एरिक किंग

@EricKing जो मैं पहले पैराग्राफ में प्रस्तुत करता हूं वह विकल्प ए है, साथ ही व्यावसायिक प्राथमिकताओं में परिवर्तन के लिए लेखांकन जो कहानी को एक प्रेत या दो के लिए उतारा जा सकता है। मैं विकल्प सी की वकालत नहीं करता हूं क्योंकि आपको तैयार काम के आधार पर "अनुमान" नहीं करना चाहिए, लेकिन अपनी टीम की अनुमान प्रक्रिया से गुजरना चाहिए।
थॉमस ओवेन्स

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

10

इसके बारे में बहुत अधिक सोचने से यह अधिक जटिल लगता है ... यह वास्तव में बहुत सरल है:

विकल्प सी

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

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


3

यदि आपका रिपोर्टिंग टूल विकल्प A को सही ढंग से नहीं संभाल सकता है, तो मैं विकल्प B के साथ जाऊंगा जब तक आपको अपने मैट्रिक्स का उपयोग करने की कोई उम्मीद नहीं है।

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

संपादित करें: यह मानता है (जैसा कि मुझे विश्वास है कि ओपी यह मान रहा था) कि लगभग पूरा काम प्राथमिकता से नहीं खटखटाया गया है और पिछले प्रयास में भुगतान प्राप्त करने के लिए काम जारी रखने के लिए यह सूची में पर्याप्त उच्च रखता है। मुझे पता है कि कुछ दुकानें ऐसा नहीं करती हैं, लेकिन मैंने जिन जगहों पर काम किया है, उनमें से लगभग पूरी तरह से बचा हुआ एक कार्य पूरा करने के लिए पर्याप्त मूल्यवान है, जब तक कि कुछ नाटकीय रूप से बदल नहीं गया है। बदलते संदर्भ का दंड अक्सर आदेश को बदलने के लायक नहीं है।


विकल्प बी खतरनाक है क्योंकि यह डेऑन की परिभाषा को कम करने की अत्यधिक संभावना है। "क्या, आप कह रहे हैं कि कहानी का हिस्सा पूरा हो गया है? लेकिन इसका प्रदर्शन नहीं किया गया है, कोड की समीक्षा या परीक्षण किया गया है - और इसे स्प्रिंट के दौरान इतनी छोटी कहानी के रूप में परिभाषित नहीं किया गया है!"
रॉबिन ग्रीन

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

3

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

मुझे नहीं लगता कि सी के माध्यम से ए विकल्प अच्छे हैं, मुख्य रूप से क्योंकि (मुझे लगता है) एक टीम के वेग के बारे में सबसे महत्वपूर्ण होना चाहिए यह औसत वेग है और यह नहीं कि किसी दिए गए स्प्रिंट का वेग ऊपर गया या नीचे गया।

जब कोई उपयोगकर्ता कहानी परिभाषित की जाती है, तो उसके पास स्वीकृति मानदंड होना चाहिए। यदि स्वीकृति मानदंड में कुछ भी नहीं किया जाता है, तो टीम बस किसी भी अंक अर्जित नहीं करती है। यदि कहानी को किया जाता है (यानी पीओ द्वारा कोडित, परीक्षण और स्वीकार किया जाता है) तो टीम को सभी बिंदु मिलते हैं।

यह तब अच्छी तरह से काम करता है जब टीम एक दिए गए स्प्रिंट के वेग के बजाय अपने औसत वेग पर केंद्रित होती है।

अपनी पुस्तक में एम। कोहन की तरह, मेरे पास ऑल-ऑर-नथिंग परिदृश्य के लिए एक प्राथमिकता है। आखिरकार, यह अनुमान लगाने की कोशिश कर रहा है कि आपने 8 अंक की कहानी में से 5 अंक पूरे किए हैं, या शायद सिर्फ 6 या 7 बस एक और अनुमान लगाने वाला खेल खत्म होने जा रहा है ... और यह मत भूलिए कि आपको पहले से ही प्रारंभिक मिल गया है रास्ता बंद अनुमान। यह संभव है कि केवल सरलतम विधि के साथ जाना बेहतर हो और जब वास्तव में पूरा हो जाने के बाद सभी बिंदुओं को प्राप्त करें।

एम। कोहन को उनकी किताब से उद्धृत करना (मेरा जोर):

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

Est एजाइल एस्टिमेशन एंड प्लानिंग , री-एस्टिमेटिंग आंशिक रूप से पूर्ण कहानियां, पृष्ठ ६६

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

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

संयुक्त अनुमानों को मूल अनुमान के बराबर की आवश्यकता नहीं होगी ...

, डिट्टो, पृष्ठ ६६

टीम के लिए बेहतर सिफारिश है कि इस तरह की समस्या से बचने के लिए कहानियों को पर्याप्त रूप से छोटे आकार में तोड़ दिया जाए:

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

, डिट्टो, पृष्ठ ६।

उम्मीद है की यह मदद करेगा।


2

मुझे आश्चर्य है कि इसमें इसका कोई सीधा जवाब नहीं है। मैं "विकल्प डी, डमी" के कोरस की उम्मीद कर रहा था!

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

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

इसके बाद हमने सोचा कि स्प्रिंट प्लानिंग को सही तरीके से करने में सक्षम होना आवश्यक है - जो कि नियम C से बाहर है।

हमने इसलिए यह निष्कर्ष निकाला है कि विकल्प A हमारे लिए सही है। हम उन सभी कहानियों के लिए कहानी के बिंदुओं का फिर से अनुमान लगाने जा रहे हैं जिन्हें हम आंशिक रूप से एक स्प्रिंट में पूरा करते हैं ताकि हम बाद के स्प्रिंट में उनके लिए ठीक से योजना बना सकें। समय के साथ उत्पाद के बैकलॉग ने हमारे द्वारा लागू कहानी बिंदुओं की मात्रा को थोड़ा रिपोर्ट किया होगा, लेकिन यह अन्य विकल्पों में से किसी भी समस्या से कम होने वाला है और संभवतः हमारे रिकॉर्ड कीपिंग और रिपोर्टिंग को बदलकर हल किया जा सकता है।


1

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

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

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


0

सबसे पहला सवाल यह है कि स्टोरी प्वाइंट का क्या मतलब है? यदि आप एक कहानी बिंदु को "कितना काम इंजीनियरिंग हो जाता है" के रूप में परिभाषित करते हैं, तो कोई भी उत्तर देगा। हालाँकि यदि आप एक कहानी बिंदु को "व्यवसाय के लिए कितना मूल्य दिया जाता है" के रूप में परिभाषित करते हैं, तो यह क्रेडिट नहीं देना महत्वपूर्ण हो जाता है जब तक कि कोई कहानी 100% पूर्ण, स्वीकृत और वितरित नहीं हो जाती है। एक कहानी के पूरा होने के आधार पर कहानी को संशोधित करने के बाद केवल वास्तविक समस्या को छिपाया जा सकता है: क) कहानी की स्पष्ट समझ नहीं थी, ख) कहानी बहुत हद तक परिभाषित थी, ग) कहानी में औसत दर्जे की स्वीकृति मानदंड का अभाव था, घ ) कहानी को पूरा करने के लिए कार्यों या निर्भरताओं की गहरी पर्याप्त समझ नहीं है, ई) कहानी का परीक्षण करने के प्रयास को समझा, च) कई कहानी बिंदुओं को खींच लिया, या जी) ... अपना कारण यहां डालें ...

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.