क्या समय का अनुमान स्क्रम में एक वादे के बराबर है?

Question

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

यदि हम समय के अनुमानों को एक वादे के रूप में मानते हैं, तो क्या एक स्क्रम टीम अधिक कुशलता से काम करती है?

एक कहानी में कितना अनुसंधान (तैयारी, समस्या को समझने का प्रयास) सही अनुमान लगाने के लिए पर्याप्त है?

अप्रत्याशित तकनीकी समस्याओं (उन समस्याओं के बारे में जो वास्तव में आपके शुरुआती अनुमानों को गड़बड़ कर सकती हैं) जो आपके काम का अनुमान लगाने के बाद सामने आती हैं?

Comments

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

— क्सक्स

सवाल यह है कि टीम के बाहर के लोगों के बारे में क्या विचार है। मैंने कहा कि 'यह' हमारे दृष्टिकोण के साथ एक समस्या है। मैं खुद को प्रोडक्ट ओनर्स शूज़ में डालने की कोशिश कर रहा था। मैंने अनुमान के बारे में पढ़ा! = वादा किया और सोचा कि अगर यह नहीं है तो आप कैसे मापेंगे? FYI करें हम चर्चा करते हैं। :)

— डेहाइ ३३

Answer 1

अनुमान पत्थर में खोदे गए वादे नहीं हैं । वे सबसे अच्छे अनुमान हैं कि टीम कार्य / कहानी को पूरा करने के लिए आवश्यक प्रयास के बारे में बता सकती है।

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

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

1. सबसे महत्वपूर्ण पर काम करना (पढ़ें: मूल्यवान) पूर्वव्यापी सुविधा (कार्य, आवश्यकता, उपयोगकर्ता कहानी)
2. ने प्रत्येक सुविधा को सफलतापूर्वक पूरा कर लिया है, जो कि वे वर्तमान में काम कर रहे हैं की तुलना में अधिक महत्वपूर्ण है (यह पूर्णता की परिभाषा को संदर्भित करता है : प्रत्येक पूर्ण कहानी का परीक्षण, स्वीकार, बग मुक्त और सुविधा-पूर्ण है)।

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

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

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

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

Answer 2

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

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

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

जब टीम ने पर्याप्त आकलन किया है, तो वे इस पर बेहतर होंगे।

आप भी देखना चाह सकते हैं ...

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

कंबन - कंबन चलने वाले विकास की एक अधिक शैली है - इसमें स्क्रैम और कानबन के संयोजन भी हैं, जिन्हें "स्क्रंबन" कहा जाता है, जो दोनों विचारों से आकर्षित होते हैं।

Comments

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

— रयान क्रॉमवेल

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

— फेंटन

Answer 3

नहीं।

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

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

और इस तरह से आप यह सुनिश्चित कर सकते हैं कि टीम बिना किसी यादृच्छिक वादे के क्या कर सकती है।

Answer 4

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

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

अत्यधिक माइक कोहन की फुर्ती का अनुमान लगाने और योजना बनाने की सलाह देते हैं

Answer 5

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

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

यदि हम समय के अनुमानों को एक वादे के रूप में मानते हैं, तो क्या एक स्क्रम टीम अधिक कुशलता से काम करती है?

नहीं। यह सैंडबैगिंग अनुमानों की ओर जाता है और वेग / बोझ चार्ट को बेकार डेटा में बदल देता है - जो टीम को सुधारने से रोकता है।

एक कहानी में कितना अनुसंधान (तैयारी, समस्या को समझने का प्रयास) सही अनुमान लगाने के लिए पर्याप्त है?

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

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

अप्रत्याशित तकनीकी समस्याओं (उन समस्याओं के बारे में जो वास्तव में आपके शुरुआती अनुमानों को गड़बड़ कर सकती हैं) जो आपके काम का अनुमान लगाने के बाद सामने आती हैं?

छोटे पुनरावृत्तियों। बैकलॉग का आदेश दिया। छोटी कहानियाँ। खतरनाक सामान वह है जो आप नहीं जानते कि आप नहीं जानते हैं। किसी समस्या पर विशेषज्ञता की कमी के परिणामस्वरूप खराब अनुमान लगेंगे, लेकिन आप या तो विशेषज्ञता हासिल कर सकते हैं (अधिक विस्तार) या 'अच्छे पर्याप्त' अनुमानों के साथ जा सकते हैं - यह जोखिम प्रबंधन के बारे में है।

Answer 6

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

यह स्क्रम के बारे में सबसे बड़ी गलतफहमी में से एक है। "मेरी परियोजना में कितना समय लगेगा?" मानता है कि आप किसी समय में परिभाषित कर सकते हैं, वास्तव में परियोजना पूरी होने के लिए क्या करेगी। लेकिन स्क्रम के बारे में संपूर्ण विचार यह है कि यह स्वीकार करता है कि आप किसी परियोजना के बारे में जो सीखते हैं, जैसा कि आप परियोजना पर काम करते हैं, परियोजना की परिभाषा को बदलने जा रहे हैं।

किसी परियोजना को परिभाषित करने का सबसे आम तरीका उन विशेषताओं को सूचीबद्ध करना है जो उसके पास होंगी। आमतौर पर, एक परियोजना पूरी हो जाती है जब सभी सुविधाओं को लागू किया जाता है। लेकिन क्या होगा यदि आप किसी परियोजना पर काम करते हैं, तो आपको पता चलता है कि स्थापना के समय पहचानी जाने वाली सुविधाओं में से 5 की जरूरत नहीं है, लेकिन 7 विशेषताएं हैं जो लोगों ने पहले 6 महीनों में सोचा था कि वास्तव में शामिल होना चाहिए? उस सवाल का क्या करता है कि इसमें कितना समय लगेगा?

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

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

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

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

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