अंदाज लावत आहे सॉफ्टवेअर विकास काम हे उत्पादन नियोजनाच्या सर्वात कठीण भागांपैकी एक आहे. एखाद्या प्रकल्पाची सुरुवात अगदी सोप्या आवश्यकतांसह होऊ शकते, परंतु अंमलबजावणी तांत्रिक अवलंबित्व, एकत्रीकरण समस्या, सुरक्षा आवश्यकता, चाचणी आव्हाने किंवा वापरकर्त्याच्या अपेक्षा बदलू शकते.
म्हणूनच सॉफ्टवेअर अंदाज अचूक पूर्ण होण्याच्या तारखेचा अंदाज मानला जाऊ नये. त्याऐवजी, ही एक नियोजन क्रियाकलाप आहे जी संघांना संभाव्य प्रयत्नांना समजून घेण्यात आणि व्याप्ती, संसाधने आणि प्राधान्यांबद्दल माहितीपूर्ण निर्णय घेण्यास मदत करते. एक उपयुक्त अंदाज विकासक, उत्पादन व्यवस्थापक आणि भागधारकांना वास्तविकपणे काय साध्य केले जाऊ शकते याची सामायिक समज देते. दुसरीकडे, एक खराब अंदाज अवास्तव मुदत, घाईघाईने विकास आणि गुणवत्तेत तडजोड करू शकतो.
सॉफ्टवेअर अंदाज: सॉफ्टवेअर अंदाज अनेकदा अयशस्वी का होतात
अंदाज अयशस्वी होण्याचे सर्वात मोठे कारण म्हणजे संघांना आवश्यकता योग्यरित्या समजण्यापूर्वी कामाचा अंदाज घेण्यास सांगितले जाते. एखादे वैशिष्ट्य अजूनही बदलत असल्यास किंवा त्यामध्ये अनुत्तरित प्रश्न असतील, तर त्याला किती वेळ लागेल याबद्दल साहजिकच अधिक अनिश्चितता असते. मोठी आणि खराब परिभाषित कार्ये आणखी एक समस्या निर्माण करतात. विकासकाला एकाच वेळी संपूर्ण अनुप्रयोगाचा अंदाज घेण्यास सांगण्यासाठी शेकडो वैयक्तिक क्रियाकलापांबद्दल गृहीतके आवश्यक आहेत. लहान अनिश्चितता जमा होऊ शकतात आणि अंतिम निकालावर लक्षणीय परिणाम करू शकतात. तांत्रिक गुंतागुंत हा चुकीच्या अंदाजांचा आणखी एक सामान्य स्रोत आहे.
एखादे वैशिष्ट्य उत्पादनाच्या दृष्टीकोनातून सरळ दिसू शकते परंतु API, डेटाबेस, प्रमाणीकरण, पायाभूत सुविधा आणि तृतीय-पक्ष सेवांवर कार्य करणे आवश्यक आहे. संघ चाचणी आणि देखभाल देखील कमी लेखू शकतात. प्रारंभिक कोड लिहिणे हा विकासाचा एक भाग आहे. सॉफ्टवेअरला चाचणी, डीबगिंग, सुरक्षा तपासणी, दस्तऐवजीकरण, उपयोजन आणि काहीवेळा अभिप्रायावर आधारित बदलांच्या अनेक फेऱ्यांची आवश्यकता असते.
बाह्य अवलंबित्व अतिरिक्त अनिश्चितता निर्माण करतात. एखाद्या प्रकल्पाला अनुपलब्ध API, दुसऱ्या कार्यसंघाचे कार्य, पायाभूत सुविधांच्या मर्यादा किंवा तृतीय-पक्ष सेवेतील बदलांमुळे विलंब होऊ शकतो, जरी विकास संघाने स्वतःची कार्ये पूर्ण केली असली तरीही.
लहान तुकड्यांमध्ये प्रकल्प खंडित करा
अंदाज सुधारण्यासाठी सर्वात व्यावहारिक मार्गांपैकी एक म्हणजे मोठ्या आवश्यकता लहान, समजण्यायोग्य तुकड्यांमध्ये विभागणे. संपूर्ण वैशिष्ट्याचा एक कार्य म्हणून अंदाज लावण्याऐवजी, कार्यसंघ ते वितरित करण्यासाठी आवश्यक असलेल्या वैयक्तिक क्रियाकलाप ओळखू शकतात. उदाहरणार्थ, नवीन खाते-व्यवस्थापन वैशिष्ट्यामध्ये इंटरफेस विकास, बॅकएंड लॉजिक, डेटाबेस बदल, प्रमाणीकरण, प्रमाणीकरण, चाचणी आणि उपयोजन यांचा समावेश असू शकतो.
लहान कार्ये समजून घेणे सोपे आहे कारण विकासक विस्तृत वर्णनाऐवजी ठोस क्रियाकलापांवर आधारित कामाचा अंदाज लावू शकतात. हा दृष्टीकोन लपविलेले कार्य देखील अधिक दृश्यमान करतो. जेव्हा संघ प्रत्येक घटकावर स्वतंत्रपणे चर्चा करतात, तेव्हा विकास सुरू होण्यापूर्वी ते अवलंबित्व आणि तांत्रिक जोखीम ओळखण्याची अधिक शक्यता असते. काम खंडित केल्याने अनिश्चितता दूर होत नाही, परंतु ते संघांना त्यावर चर्चा करण्यासाठी एक चांगला आधार देते.
योग्य अंदाज तंत्र निवडणे
वेगवेगळ्या प्रकल्पांना वेगवेगळ्या अंदाज पद्धतींची आवश्यकता असते. असे कोणतेही एक तंत्र नाही जे प्रत्येक सॉफ्टवेअर टीमसाठी तितकेच चांगले कार्य करते.
तज्ञांचा अंदाज विकासकांच्या किंवा तांत्रिक तज्ञांच्या अनुभवावर अवलंबून असतो जे एखाद्या कार्यासाठी किती प्रयत्न करावे लागतील याचे मूल्यांकन करतात. जेव्हा अनुभवी लोक समान प्रणालींशी परिचित असतात तेव्हा ते चांगले कार्य करू शकते, परंतु वैयक्तिक गृहितक परिणामांवर परिणाम करू शकतात.
समान अंदाज नवीन कार्याची तुलना पूर्वी पूर्ण केलेल्या कामाशी करते. जर एखाद्या संघाने आधीच एक समान वैशिष्ट्य तयार केले असेल, तर ऐतिहासिक माहिती उपयुक्त संदर्भ बिंदू प्रदान करू शकते.
चपळ कार्यसंघ सहसा प्रत्येक कार्यासाठी अचूक तास नियुक्त करण्याऐवजी सापेक्ष अंदाज वापरतात. कथेचे मुद्दे, उदाहरणार्थ, एखाद्या कामाची सापेक्ष जटिलता, प्रयत्न आणि अनिश्चितता दर्शवू शकतात. एक संघ एक कथा दुस-यापेक्षा दुप्पट कठीण आहे असा दावा न करता त्याला दुप्पट तास लागतील असा दावा करू शकतो.
पोकरचे नियोजन करणे हे आणखी एक सामान्य चपळ तंत्र आहे. फरकांची चर्चा करण्यापूर्वी टीम सदस्य स्वतंत्रपणे अंदाज नियुक्त करतात. हे अशा गृहितकांचा पर्दाफाश करू शकते जे अन्यथा लपलेले राहू शकतात आणि अंदाज एका व्यक्तीच्या मतावर वर्चस्व होण्यापासून रोखू शकतात.
ते लपवण्याऐवजी अनिश्चिततेचा अंदाज लावा
एक वास्तववादी सॉफ्टवेअर अंदाज अनिश्चितता संप्रेषण पाहिजे. प्रकल्पाच्या सुरुवातीच्या काळात, संघांना सहसा तांत्रिक अंमलबजावणी, वापरकर्ता आवश्यकता आणि संभाव्य समस्यांबद्दल कमी माहिती असते. विकास जसजसा वाढत जातो, तसतसे ते अधिक माहिती गोळा करतात आणि अधिक अचूक अंदाज बांधू शकतात. गॅरंटीड डेडलाइन म्हणून लवकर अंदाज सादर करण्याऐवजी, संघ एक श्रेणी प्रदान करू शकतात किंवा त्यामागील गृहितके स्पष्ट करू शकतात.
उदाहरणार्थ, एखाद्या वैशिष्ट्यासाठी सामान्य परिस्थितीत काही प्रमाणात प्रयत्न करणे अपेक्षित आहे परंतु बाह्य एकत्रीकरण अपेक्षेपेक्षा अधिक क्लिष्ट असल्याचे सिद्ध झाल्यास जास्त वेळ लागेल. ऐतिहासिक प्रकल्प डेटा ही प्रक्रिया अधिक मजबूत करू शकतो. संघ मागील कामाच्या वास्तविक परिणामांसह अंदाजांची तुलना करू शकतात आणि कमी लेखण्याचे आवर्ती नमुने ओळखू शकतात. हे फीडबॅक लूप तयार करते: अंदाज लावा, तयार करा, वास्तविक परिणाम मोजा आणि भविष्यातील अंदाज सुधारण्यासाठी त्या माहितीचा वापर करा.
दाबापासून अंदाज वेगळे ठेवा
जेव्हा ते कार्यप्रदर्शन लक्ष्यात बदलले जाते तेव्हा अंदाज कमी उपयुक्त ठरतो. जर विकासकांचा असा विश्वास असेल की मोठा अंदाज प्रदान करणे खराब कामगिरी म्हणून समजले जाईल, तर ते अपेक्षा पूर्ण करण्यासाठी संख्या कमी करू शकतात. त्यामुळे संबंधित कामाचे भ्रामक चित्र निर्माण होते. एक चांगली प्रक्रिया वाटाघाटी पासून अंदाज वेगळे करते.
विकसक त्यांना जे समजतात त्यावर आधारित तांत्रिक प्रयत्नांचा अंदाज लावतात, तर उत्पादन आणि व्यवसाय कार्यसंघ उपलब्ध वेळेत आणि संसाधनांमध्ये कोणते कार्यक्षेत्र बसवायचे हे ठरवतात. एखादा प्रकल्प लवकर पूर्ण करणे आवश्यक असल्यास, त्याच प्रमाणात काम जलद पूर्ण व्हावे अशी मागणी करण्याऐवजी व्याप्ती कमी करणे, योग्य संसाधने जोडणे किंवा प्राधान्यक्रम बदलणे हा उपाय असू शकतो.
प्रकल्प बदलत असताना अंदाज अद्यतनित करा
सॉफ्टवेअर डेव्हलपमेंट क्वचितच स्थिर असते. आवश्यकता बदलतात, नवीन माहिती दिसून येते आणि अंमलबजावणी दरम्यान तांत्रिक गृहितकांची चाचणी केली जाते. त्यामुळे अंदाजांना कायमस्वरूपी वचनबद्धतेऐवजी विकसित होणारी माहिती मानली पाहिजे. जेव्हा आवश्यकता लक्षणीयरीत्या बदलतात, नवीन तांत्रिक जोखीम दिसून येतात किंवा वास्तविक विकास डेटा दर्शवितो की मूळ गृहीतके चुकीची होती तेव्हा संघ अंदाज पुन्हा पाहू शकतात.
नियमित पुनरावलोकन परिस्थिती बदलल्यानंतर संपूर्ण प्रकल्पावर नियंत्रण ठेवण्यापासून प्रारंभिक अंदाज टाळण्यास मदत करते. हे विशेषतः चपळ संघांसाठी महत्वाचे आहे, जेथे कामाचे नियोजन केले जाते आणि वाढीवपणे वितरित केले जाते. पूर्ण केलेल्या पुनरावृत्तींमधून प्रगती संघाच्या वास्तविक वितरण क्षमतेबद्दल अधिकाधिक उपयुक्त माहिती प्रदान करू शकते.
निष्कर्ष
सॉफ्टवेअर अंदाज अचूक अचूकतेने भविष्याचा अंदाज लावणे नाही. संघांना कामाचा आकार आणि जटिलता समजून घेणे, अनिश्चितता ओळखणे आणि चांगले नियोजन निर्णय घेणे हा त्याचा खरा उद्देश आहे. जेव्हा संघ मोठ्या गरजा लहान कार्यांमध्ये मोडतात, योग्य अंदाज तंत्र वापरतात, ऐतिहासिक डेटामधून शिकतात आणि गृहीतके स्पष्टपणे संप्रेषण करतात तेव्हा अंदाज अधिक उपयुक्त होतात.
केवळ कोडिंग वेळेवर लक्ष केंद्रित करण्याऐवजी त्यांना चाचणी, अवलंबित्व, तांत्रिक जटिलता आणि अनपेक्षित कामासाठी देखील खाते देणे आवश्यक आहे. सर्वात महत्त्वाचे म्हणजे, अंदाज लवचिक असावा. कार्यसंघ उत्पादनाबद्दल अधिक जाणून घेत असताना, त्यांनी त्यांच्या अपेक्षा सुधारण्यास तयार असले पाहिजे. अंदाजाला निश्चित वचनाऐवजी चालू नियोजन प्रक्रिया म्हणून हाताळून, सॉफ्टवेअर कार्यसंघ दबाव कमी करताना, संवाद सुधारताना आणि चांगली उत्पादने तयार करताना अधिक वास्तववादी वेळापत्रक तयार करू शकतात.
Comments are closed.