अपनी समय सीमा को पूरा करें: डेवलपर्स द्वारा प्रयास का अनुमान लगाने के लिए उपयोग की जाने वाली विधियाँ

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

यदि आप खराब अनुमान प्रदान करते हैं तो क्या होगा?

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

समय का अनुमान कैसे लगाएं

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

कहानी के बिंदु क्या हैं?

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

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

कहानी बिंदुओं का उपयोग कैसे न करें

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

स्क्रम पोकर क्या है?

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

समापन बिंदुओं की अज्ञात संख्या

असीम रूप से लंबा कार्य

थोड़े आराम की जरूरत है

कम सामान्य अनुमान विधियों का उपयोग:

• टी-शर्ट का आकार - एस, एम, एल, एक्स्ट्रा लार्ज
• कुत्तों की नस्लें - चिहुआहुआ, पग, दचशुंड, बुलडॉग, और इसी तरह (व्यक्तिगत रूप से, मुझे लगता है कि यह प्रयास अनुमान = डी के लिए माप की सबसे अजीब इकाई है)

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

प्रयास अनुमान का उदाहरण

मान लीजिए कि आपकी टीम ने अनुमानों के लिए कहानी अंक निर्दिष्ट करने के लिए निम्नलिखित पैमाने की स्थापना की है: स्क्रम पोकर प्रत्येक कार्य के लिए खेला जाता है, और आप निम्नानुसार एक अनुमान प्रदान करते हैं:

• आपने पहले कभी समान कार्यक्षमता लागू नहीं की है: +3
• कार्यक्षमता औसत आकार की है: +2
• कार्यान्वयन अत्यधिक जटिल होगा: +3
• कार्यक्षमता के लिए परीक्षण लिखना अत्यधिक जटिल होगा: +3

प्रत्येक घटक को जोड़ने पर, आपको कुल 11 कहानी बिंदु मिलते हैं, लेकिन ऐसा कोई कार्ड नहीं है, इसलिए आप 13 का सुझाव देते हैं। एक सहकर्मी कार्य के लिए निम्नलिखित अनुमान लगाता है:

• उन्होंने पहले समान कार्य के साथ काम किया है: +1
• कार्यक्षमता औसत आकार की है: +2
• कार्यान्वयन औसत जटिलता का होगा: +2
• कार्यक्षमता के लिए लेखन परीक्षण औसत जटिलता का होगा: +2

उसका मध्यवर्ती परिणाम 7 कहानी बिंदु है, लेकिन वह संख्या फाइबोनैचि श्रृंखला में मौजूद नहीं है, इसलिए वह कार्ड को सबसे अनुमानित संख्या - 8 के साथ जमा करता है। टीम के अन्य सदस्य भी अपने व्यक्तिपरक विचारों के आधार पर अपना अनुमान लगाते हैं। फिर हर कोई अपने कार्ड दिखाता है और आप पाते हैं कि आपके लगभग सभी सहकर्मियों ने 13 का अनुमान दिया है, केवल एक डेवलपर को छोड़कर जिसने 8 का सुझाव दिया था। इस मामले में, उसे अपने कम अनुमान के कारण बताने के लिए बोलने की अनुमति है। मान लीजिए कि वह यह औचित्य प्रदान करता है: उसने पहले एक ही कार्य पर काम किया था, और यह उतना कठिन नहीं है जितना यह लग सकता है। अंत में, वह बाकी टीम को 13 से 8 कहानी बिंदुओं पर अपना विचार बदलने के लिए मना लेता है, यह कहते हुए कि वह इस कार्य को पूरा करने में मदद करेगा। या शायद वह इसे खुद करेगा। किसी भी सूरत में, यह नहीं है इससे कोई फर्क नहीं पड़ता कि दूसरे उसके तर्कों को स्वीकार करते हैं या नहीं, क्योंकि एक तरह से या किसी अन्य को कार्य के लिए एक अनुमान सौंपा जाएगा, और टीम अगले एक पर विचार करने के लिए आगे बढ़ेगी। प्रारंभ में, अनुमान गलत होंगे, जैसा कि आपके द्वारा अगली अवधि (स्प्रिंट) में किए जाने वाले कार्य की मात्रा का अनुमान होगा। आखिरकार, ये अनुमान अनुमानों का उपयोग करके बनाए गए हैं। कुछ समय बाद, शायद तीन महीने बाद, टीम कार्यों के लिए आवश्यक समय का अधिक सटीक अनुमान लगाना शुरू कर देगी, और टीम स्प्रिंट में प्रदर्शन करने में सक्षम कार्य की औसत मात्रा स्पष्ट हो जाएगी। लेकिन यह कार्य के दायरे के लिए एक सामान्य योजना बनाने की एक प्रक्रिया है। यह मुख्य रूप से समय पर केंद्रित है, लेकिन इस मामले में कई अलग-अलग प्रासंगिक कारक हो सकते हैं। उदाहरण के लिए, मान लीजिए कि एक डेवलपर दो सप्ताह के लिए छुट्टी पर चला गया। आपको नियोजित कार्य (नियोजित कार्यक्षमता) की एक निश्चित मात्रा में कटौती करने की आवश्यकता होगी। या मान लीजिए कि एक नया डेवलपर टीम में शामिल हो गया है, लेकिन अभी तक पूरी तरह से गति तक नहीं है, इसलिए आपको उसे परियोजना से परिचित होने के लिए समय देने की आवश्यकता हैऑनबोर्डिंग प्रक्रिया। परियोजना की जटिलता के आधार पर, यह दो सप्ताह हो सकता है, एक सप्ताह दे या ले सकता है। यह सभी आज के लिए है! मुझे आशा है कि मैंने प्रयास अनुमान के बारे में आपके ज्ञान में थोड़ा सुधार किया है, जो सॉफ़्टवेयर विकास का एक आवश्यक गैर-तकनीकी पहलू है। यदि आप इस विषय में गहराई से जाना चाहते हैं, और स्क्रम के विवरण में, मैं दृढ़ता से अनुशंसा करता हूं कि आप जेफ सदरलैंड द्वारा "एससीआरयूएम" पुस्तक पढ़ लें। मैं परिणामों के बारे में कोई वादा नहीं कर सकता, क्योंकि इसे पढ़ने के बाद आपको स्क्रम मास्टर = डी बनने की कष्टप्रद इच्छा होगी