तुमची डेडलाइन पूर्ण करा: डेव्हलपर प्रयत्नांचा अंदाज घेण्यासाठी ज्या पद्धती वापरतात

हॅलो, प्रत्येकजण! सॉफ्टवेअर डेव्हलपमेंटमध्ये प्रारंभ करण्यासाठी तुम्हाला अनेक सिद्धांत माहित असणे आवश्यक आहे. काही तज्ञांना (उदाहरणार्थ, बॅकएंड डेव्हलपर जे Java आणि इतर भाषा वापरतात) ते अधिक जाणून घेतात, तर इतरांना (उदाहरणार्थ, फ्रंटएंड डेव्हलपर जे JavaScript आणि React Native वापरतात) थोडे कमी माहित असू शकतात. असे म्हटले आहे की, दोन्ही गटांकडे केवळ तांत्रिकच नव्हे तर "संघटनात्मक" ज्ञान देखील असणे आवश्यक आहे. हे "संघटनात्मक" ज्ञान फ्रंटएंड आणि बॅकएंड डेव्हलपरसाठी ओव्हरलॅपचे एक क्षेत्र आहे. आज मला या गैर-तांत्रिक, संस्थात्मक ज्ञानाच्या एका पैलूबद्दल बोलायचे आहे. आज आपण प्रयत्नांच्या अंदाजाबद्दल बोलू . कारण मला फक्त चपळ पद्धती वापरण्याचा अनुभव आहे(जे सर्वात लोकप्रिय मानले जाते), विशेषत: स्क्रॅम फ्रेमवर्क, मी स्क्रमच्या संदर्भात प्रयत्नांच्या अंदाजाचा विचार करेन . अगदी सुरुवातीलाच, मी असे म्हणायला हवे की प्रयत्नांचा अंदाज घेणे कठीण आहे. माझ्यासाठी, डेव्हलपर म्हणून माझ्या नोकरीच्या सर्वात आव्हानात्मक/अप्रिय पैलूंपैकी एक आहे. विचारात घेण्यासाठी अनेक भिन्न घटक आहेत जे एखाद्या कार्यासाठी आवश्यक असलेल्या प्रयत्नांच्या आपल्या अंदाजावर परिणाम करू शकतात. याव्यतिरिक्त, भविष्यातील विकास योजना तुमच्या अंदाजांवर आधारित असतील.

आपण खराब अंदाज प्रदान केल्यास काय?

जर एखाद्या विकासकाने कार्यासाठी खर्च केलेल्या तासांपेक्षा कितीतरी जास्त तासांचा अंदाज लावला तर, अंदाज चुकीचा असल्याने त्यांच्या कौशल्यावर शंका येऊ शकते. दुसऱ्या शब्दांत, तो एक जंगली अंदाज होता. त्याच वेळी, विकासकाने अंदाज केलेल्या वेळेत काम पूर्ण न केल्यास, ती उत्पादन किंवा नवीन वैशिष्ट्य जारी करण्याच्या ग्राहकाच्या योजना धोक्यात आणते. हा व्यवसाय आहे आणि व्यवसाय म्हणजे पैसा. अशा स्लिपमुळे काही ग्राहक खूश होतील. खरं तर, म्हणूनच मला अंदाज आवडत नाही — कारण काही वेळा एखादे काम पूर्ण करण्यासाठी लागणारा वेळ अचूकपणे ठरवणे खूप अवघड असते.

वेळेचा अंदाज कसा लावायचा

नियमानुसार, अंदाज तास किंवा कथा बिंदूंमध्ये केले जातात. कथा बिंदू वापरून अंदाज प्रक्रिया करणे हे माझे वैयक्तिक प्राधान्य आहे . ठोस भौतिक वस्तूंबद्दल चुकीचे समजणे कठीण आहे, परंतु कथेचे मुद्दे थोडे अधिक अमूर्त आहेत. सॉफ्टवेअर डेव्हलपमेंट टीम सामान्यत: वेळेच्या प्रमाणात अंदाज देतात: तास, दिवस, आठवडे, महिने. हे वेळेचे अंदाज प्रामुख्याने वैयक्तिक अनुभव, अंदाज आणि/किंवा अंतर्ज्ञान यावर आधारित आहेत. या प्रकरणात, विकासक फक्त कार्य पाहतात आणि त्यांना किती वेळ लागेल याबद्दल त्यांची धारणा व्यक्त करतात. परिणामी, हे अंदाज फारच क्वचितच अचूक असतात, कारण कामाच्या कालावधीवर परिणाम करणारे बरेच घटक आहेत. म्हणूनच चपळ पद्धती वापरणारे अनेक संघ कथा बिंदू देखील वापरतात. चला आत जाऊया!

कथेचे मुद्दे काय आहेत?

स्टोरी पॉईंट हे कार्यक्षमतेच्या विशिष्ट भागाची पूर्ण अंमलबजावणी करण्यासाठी आवश्यक असलेल्या एकूण प्रयत्नांचा अंदाज व्यक्त करण्यासाठी मोजण्याचे एकक आहे. म्हणजेच, आम्ही नातेवाईकाबद्दल बोलत आहोतगुंतागुंत कार्याची जटिलता, कामाचे प्रमाण आणि जोखीम किंवा अनिश्चितता यावर आधारित कार्यसंघ कथा बिंदूंमध्ये अंदाज नियुक्त करतात. ही मूल्ये सहसा कार्य अधिक कार्यक्षमतेने लहान तुकड्यांमध्ये विभागण्यासाठी नियुक्त केली जातात, ज्यामुळे संदिग्धता दूर होते. कालांतराने, हे संघांना दिलेल्या कालावधीत ते काय साध्य करू शकतात हे समजण्यास मदत करते आणि त्यानंतरच्या कामाचे अधिक अचूकपणे नियोजन करण्यास मदत करते. हे तुमच्यासाठी पूर्णपणे विरोधाभासी वाटू शकते, परंतु हे अमूर्तता खरोखरच सुलभ आहे: ते कार्याच्या जटिलतेबद्दल कठोर निर्णय घेण्यास संघाला प्रवृत्त करते. नियोजन करताना स्टोरी पॉइंट्स वापरण्याची काही कारणे पाहू या:

• तुम्ही वेळेचा चुकीचा अंदाज टाळू शकता.
• वेळेच्या युनिट्समध्ये केलेल्या अंदाजांच्या विपरीत, स्टोरी पॉइंट्स तुम्हाला ओव्हरहेड खर्चाचा हिशेब देऊ देतात: टीम सदस्य आणि ग्राहक यांच्यातील संवाद, विविध टीम चर्चा आणि नियोजन क्रियाकलाप तसेच अनपेक्षित परिस्थिती.
• प्रत्येक संघ वेगवेगळ्या स्केल वापरून त्यांच्या कामाचा अंदाज लावेल, याचा अर्थ त्यांची क्षमता (गुणांमध्ये मोजली जाणारी) वेगळी असेल.
• प्रत्येक कथा बिंदू नियुक्त करण्यासाठी स्केल परिभाषित करून, तुम्ही जास्त विवाद न करता पटकन गुण वाटप करू शकता.

स्टोरी पॉइंट्स कसे वापरायचे नाहीत

दुर्दैवाने, कथेतील मुद्द्यांचा अनेकदा गैरवापर होतो. कथा बिंदू दिशाभूल करणारे असू शकतात जेव्हा ते लोकांचे मूल्यांकन करण्यासाठी, तपशीलवार मुदती आणि संसाधने परिभाषित करण्यासाठी वापरले जातात आणि जेव्हा ते कार्यप्रदर्शन मोजण्यासाठी चुकले जातात. त्याऐवजी, प्रत्येक कार्याची व्याप्ती/जटिलता समजून घेण्यासाठी आणि प्राधान्यक्रम सेट करण्यासाठी संघांनी त्यांचा वापर केला पाहिजे. कदाचित ज्या भागांना अधिक कठीण मानले जाते ते प्रथम हाताळले जावे, जेणेकरून ते स्प्रिंटच्या समाप्तीपूर्वी केले जाऊ शकतात , शक्यतो सोपी कार्ये नंतर हलवता येतील. स्क्रॅम पद्धतीच्या संदर्भात स्प्रिंट म्हणजे काय ते मी तुम्हाला आठवण करून देतो : जेव्हा विकास सुरू होतो तेव्हा या कालावधीची लांबी निर्धारित केली जाते आणि संघ आणि ग्राहक यांच्यात सहमती दर्शविली जाते. हा कालावधी दोन आठवडे किंवा एक महिना किंवा इतर कोणताही कालावधी असू शकतो. नियमानुसार, स्प्रिंटच्या शेवटी, पूर्ण झालेले काम ग्राहकाला वितरीत केल्यावर पूर्ण होऊ शकणार्‍या कामाचे नियोजन करण्यासाठी प्रत्येक स्प्रिंटच्या सुरुवातीला प्रयत्नांचे अंदाज बांधले जातात. डेमो तुम्हाला उत्पादन विकसित करताना तुमची प्रगती पाहण्यास, ग्राहकाकडून अभिप्राय प्राप्त करण्यास आणि ग्राहकाच्या दृष्टीनुसार प्रकल्पाचा मार्ग समायोजित करण्यात मदत करतो. पण आपण थोडे विषयांतर करतो. चला अंदाजांकडे परत जाऊया. फक्त एका विकसकाने सर्व कामांसाठी अंदाज देणे खूप व्यक्तिनिष्ठ असेल. त्यामुळे ही प्रक्रिया सहसा सांघिक प्रयत्न असते. अशी काही तंत्रे आहेत जी संघ अंदाज तयार करण्यासाठी वापरू शकतात. आज आपण सर्वात लोकप्रिय तंत्र पाहू: स्क्रम पोकर . या तंत्रासाठी एक व्यवस्थापक आवश्यक आहे जो स्क्रम पोकरसाठी नियंत्रक म्हणून काम करेल . हे स्क्रम मास्टर किंवा शक्यतो पीएम असू शकते .

स्क्रम पोकर म्हणजे काय?

स्क्रम पोकर , किंवा प्लॅनिंग पोकर, एक अंदाज तंत्र आहे जे करारावर पोहोचण्यावर आधारित आहे. हे प्रामुख्याने पुढील कामाची गुंतागुंत किंवा सॉफ्टवेअर डेव्हलपमेंट कार्यांच्या सापेक्ष आकाराचा अंदाज लावण्यासाठी केला जातो. मी लगेच म्हणेन की स्क्रम पोकरएक सामान्य सॉफ्टवेअर डेव्हलपमेंट सराव आहे, आणि तुम्हाला हे सर्व काय आहे हे माहित असणे आवश्यक आहे. यामध्ये सहसा एखाद्या विशिष्ट कार्यासाठी संघाच्या सहयोगी अंदाजाची निर्मिती सुलभ करण्यासाठी अॅप किंवा वेबसाइट समाविष्ट असते. हे कसे घडते? संघ अनुशेषातून काहीतरी घेते (एक नवीन कार्य, काही कार्यक्षमता) आणि थोडक्यात संभाव्य तोटे आणि त्याच्याशी संबंधित इतर बारकावे चर्चा करते. मग प्रत्येक सहभागी त्यांच्या जटिलतेचा अंदाज दर्शविणारे एक नंबर असलेले कार्ड निवडतो. अरे, आणखी एक गोष्ट, हे अंदाज लावताना, आम्ही सामान्य संख्यांऐवजी फिबोनाची क्रमवारीतील संख्या वापरतो. स्क्रम पोकरमध्ये फिबोनाची संख्या लोकप्रिय आहेत, कारण त्यांच्यामध्ये वाढत्या प्रमाणात मोठे अंतर आहे (पिरॅमिडच्या पातळीसारखे). काही कार्ये अत्यंत क्लिष्ट असतील आणि आम्‍हाला कथेच्‍या कमी गुणांसह दूर जाता येणार नाही. अशी काही असामान्य कार्डे आहेत ज्यांचे खालील अर्थ आहेत:

अंतिम बिंदूंची अज्ञात संख्या

अनंत लांब कार्य

विश्रांतीची गरज आहे

कमी सामान्य अंदाज पद्धती वापरतात:

• टी-शर्ट आकार - S, M, L, XL
• कुत्र्यांच्या जाती — चिहुआहुआ, पग, डॅचशंड, बुलडॉग आणि असेच (वैयक्तिकरित्या, मला वाटते की हे प्रयत्नांच्या अंदाजासाठी मोजण्याचे सर्वात विचित्र एकक आहे =D)

टीम मग एकाच कामासाठी वेगवेगळ्या डेव्हलपरने दिलेल्या अंदाजांची तुलना करते. जर ते सहमत असतील तर छान! तसे नसल्यास, वेगवेगळ्या अंदाजांची कारणे (वाद) चर्चा करणे आवश्यक आहे. त्यानंतर, प्रत्येकजण कमी-अधिक प्रमाणात स्वीकारतो असा एकच अंदाज तयार करण्यासाठी संघ एकत्र काम करतो. मग गंभीर सॉफ्टवेअर प्रोजेक्ट्सची योजना करण्यासाठी पोकरचा वापर का केला जातो? हे विचित्र आहे हे मान्य करावे लागेल. वस्तुस्थिती अशी आहे की या प्रकारचे गेमिफिकेशन टीम सदस्यांना स्वतंत्रपणे विचार करण्यास प्रोत्साहित करते, त्यांना त्यांचे अंदाज त्यांच्या टीममेट्सप्रमाणेच प्रकट करण्यास आमंत्रित करते. हे, यामधून, अशी परिस्थिती निर्माण करणे टाळते जिथे काही कार्यसंघ सदस्य इतरांच्या मतांवर अवलंबून असतात. जर ते अशा प्रकारे केले गेले नसते, तर कमी अनुभवी विकासक अधिक अनुभवी टीम सदस्यांद्वारे प्रदान केलेल्या अंदाजांकडे लक्ष देतील आणि त्यावर लक्ष केंद्रित करतील, आणि त्यामुळे त्यांचे स्वतःचे अंदाज कमी उपयुक्त ठरतील. परंतु एकाच वेळी अंदाज दर्शविणे हे अनिवार्यपणे अशक्य करते. Atlassian ऑफरनियोजन प्रक्रियेत वापरण्यासाठी एक स्क्रम पोकर अॅप .

प्रयत्नांच्या अंदाजाचे उदाहरण

समजा तुमच्या टीमने अंदाजांना स्टोरी पॉइंट नियुक्त करण्यासाठी खालील स्केल स्थापित केले आहे: प्रत्येक कार्यासाठी स्क्रम पोकर खेळला जातो आणि तुम्ही खालीलप्रमाणे अंदाज प्रदान करता:

• तुम्ही यापूर्वी कधीही अशी कार्यक्षमता लागू केलेली नाही: +3
• कार्यक्षमता सरासरी-आकाराची आहे: +2
• अंमलबजावणी अत्यंत क्लिष्ट असेल: +3
• कार्यक्षमतेसाठी लेखन चाचण्या अत्यंत क्लिष्ट असतील: +3

प्रत्येक घटक जोडल्यास, तुम्हाला एकूण 11 स्टोरी पॉइंट्स मिळतील, परंतु असे कोणतेही कार्ड नाही, म्हणून तुम्ही 13 सुचवा. एक सहकर्मी कार्यासाठी खालील अंदाज पुढे करतो:

• त्याने याआधीही असेच काम केले आहे: +1
• कार्यक्षमता सरासरी-आकाराची आहे: +2
• अंमलबजावणी सरासरी जटिलतेची असेल: +2
• कार्यक्षमतेसाठी लेखन चाचण्या सरासरी जटिलतेच्या असतील: +2

त्याचा इंटरमीडिएट निकाल 7 स्टोरी पॉइंट्स आहे, परंतु तो नंबर फिबोनाची सिरीजमध्ये अस्तित्वात नाही, म्हणून तो सर्वात अंदाजे क्रमांकासह कार्ड सबमिट करतो — 8. इतर टीम सदस्य देखील त्यांच्या व्यक्तिनिष्ठ दृश्यांवर आधारित त्यांचे अंदाज लावतात. मग प्रत्येकजण त्यांची कार्डे दाखवतो आणि तुम्हाला आढळले की तुमच्या जवळपास सर्व सहकर्मचार्‍यांनी 13 चा अंदाज वर्तवला आहे, एका विकासकाने 8 सुचवले होते. या प्रकरणात, त्याला त्याच्या कमी अंदाजाची कारणे सांगण्याची परवानगी आहे. समजा त्याने हे औचित्य ऑफर केले: त्याने पूर्वी त्याच कार्यावर काम केले होते आणि ते दिसते तितके कठीण नाही. शेवटी, तो बाकीच्या टीमला 13 ते 8 स्टोरी पॉईंट्समधून त्यांचे विचार बदलण्यास पटवून देतो, असे म्हणत की जो कोणी हे काम पूर्ण करेल त्याला तो मदत करेल. किंवा कदाचित तो ते स्वतः करेल. कोणत्याही परिस्थितीत, ते नाही इतरांनी त्याचे युक्तिवाद स्वीकारले की नाही हे महत्त्वाचे नाही, कारण एका मार्गाने किंवा दुसर्‍या पद्धतीने एक अंदाज कार्यासाठी नियुक्त केला जाईल आणि टीम पुढील विचारात पुढे जाईल. सुरुवातीला, अंदाज चुकीचा असेल, जसे की तुम्ही पुढील कालावधीत (स्प्रिंट) किती काम करण्याची योजना आखली आहे. शेवटी, अंदाज वापरून हे अंदाज लावले. काही काळानंतर, कदाचित तीन महिन्यांनंतर, कार्यसंघ अधिक अचूकपणे कार्यांसाठी लागणाऱ्या वेळेचा अंदाज लावू लागेल आणि स्प्रिंटमध्ये संघ किती काम करण्यास सक्षम आहे हे स्पष्ट होईल. पण कामाच्या व्याप्तीसाठी सर्वसाधारण योजना बनवण्याची ही प्रक्रिया आहे. हे प्रामुख्याने वेळेवर लक्ष केंद्रित करते, परंतु या प्रकरणात अनेक भिन्न संबंधित घटक असू शकतात. उदाहरणार्थ, समजा एखादा विकासक दोन आठवड्यांसाठी सुट्टीवर गेला. तुम्हाला नियोजित कामाची निश्चित रक्कम (नियोजित कार्यक्षमता) कमी करावी लागेल. किंवा समजा एक नवीन विकसक संघात सामील झाला आहे, परंतु तो अद्याप पूर्ण गतीने नाही, म्हणून तुम्हाला तिला प्रकल्पाद्वारे परिचित होण्यासाठी वेळ द्यावा लागेल.ऑनबोर्डिंग प्रक्रिया. हे दोन आठवडे असू शकते, प्रकल्पाच्या जटिलतेनुसार एक आठवडा द्या किंवा घ्या. आजसाठी एवढेच! मला आशा आहे की, सॉफ्टवेअर डेव्हलपमेंटचा एक आवश्यक गैर-तांत्रिक पैलू, प्रयत्नांच्या अंदाजाविषयीचे तुमचे ज्ञान मी थोडे सुधारले आहे. जर तुम्हाला या विषयात खोलवर जायचे असेल आणि स्क्रॅमच्या तपशीलात जायचे असेल, तर मी तुम्हाला जेफ सदरलँडचे "SCRUM" हे पुस्तक वाचण्याची जोरदार शिफारस करतो. मी परिणामांबद्दल कोणतेही वचन देऊ शकत नाही, कारण ते वाचल्यानंतर तुम्हाला स्क्रम मास्टर बनण्याची त्रासदायक इच्छा होईल =D