सॉफ्टवेअर डेव्हलपमेंट ही एक जटिल व्यवसाय प्रक्रिया आहे. याचा अर्थ आयटी व्यावसायिकांना ऑप्टिमायझेशन, नियोजन आणि खर्चाची भाषा बोलणे आवश्यक आहे. व्यवस्थापन संकल्पनांचे आकलन नियोक्ते आणि विकासक दोघांनाही एक मोठा फायदा देते आणि पुढील स्तरावर सहकार्य करण्यास मदत करते. सॉफ्टवेअर डेव्हलपमेंट पद्धतींबद्दल आपल्याला माहित असणे आवश्यक असलेली प्रत्येक गोष्ट: ट्रेंड, तत्त्वे आणि नवशिक्यांसाठी तोटे - 1

लक्ष द्या, नवशिक्या! मॉडेल, पद्धती आणि सामान्य गोंधळ

प्रारंभ करण्यासाठी, आम्हाला एक महत्त्वपूर्ण स्पष्टीकरण करणे आवश्यक आहे: सॉफ्टवेअर डेव्हलपमेंट मॉडेल आणि सॉफ्टवेअर डेव्हलपमेंट पद्धती वेगळ्या आणि वेगळ्या आहेत. मॉडेल्स प्रणाली कशी वागेल याचा अंदाज लावतात. सिस्टीमने जसे कार्य करावे तसे कार्य करण्यासाठी पद्धती आवश्यक आहेत. गोंधळात टाकणारी सॉफ्टवेअर डेव्हलपमेंट मॉडेल्स आणि पद्धती ही प्रत्येक IT नवशिक्यासाठी मानक कार्यप्रणाली आहे, त्यामुळे ही मोठी चूक मानली जात नाही. मॉडेलचे उदाहरण म्हणजे क्लासिक वॉटरफॉल मॉडेल , त्याची रेषीय प्रगती, प्रत्येक टप्प्यासाठी उद्दिष्टांची स्पष्ट व्याख्या आणि मुदतींवर कठोर नियंत्रण. दुसरे मॉडेल सर्पिल मॉडेल आहे, प्रकल्पातील जोखीम लवकर शोधणे आणि कमी करणे यावर लक्ष केंद्रित केले आहे. सर्पिल विकास लहान सुरू होतो, प्रथम स्थानिक समस्या सोडवतो आणि नंतर अधिक जटिल समस्यांकडे प्रगती करतो. शेवटी, दुसरे मॉडेल पुनरावृत्ती आणि वाढीव विकास (IID) आहे , ज्यामध्ये प्रकल्प जीवन चक्र पुनरावृत्तीच्या मालिकेत विभागले गेले आहे, ज्यापैकी प्रत्येक "मिनी-प्रोजेक्ट" सारखा आहे. सर्वसाधारणपणे, मॉडेल हे सॉफ्टवेअर डेव्हलपमेंट प्रक्रियेचे वर्णन असते . परंतु कार्यपद्धती म्हणजे नियुक्त केलेल्या कार्यांवर नियंत्रण, मूल्यमापन आणि देखरेख करण्याच्या प्रणाली आहेत. पद्धती ही आधुनिक युगाची काठी आणि गाजर आहेत, विकास प्रक्रियेतील प्रत्येक पायरीवर नियंत्रण ठेवण्यासाठी आवश्यक आहे. ते प्रकल्पाची दिशा, त्याचे बजेट आणि अंतिम उत्पादनाच्या अंमलबजावणीची अंतिम मुदत यावर आधारित निवडले जातात. इतकेच काय, प्रोजेक्ट लीडर आणि त्याच्या टीमच्या स्वभावावर आधारित पद्धती निवडल्या जाऊ शकतात. अगदी कंपनी किंवा ग्राहकाच्या तत्त्वज्ञानावर आधारित. चला सर्वात लोकप्रिय पद्धतींवर एक नजर टाकूया.

1. स्क्रम

स्क्रम ही एक चपळ प्रकल्प व्यवस्थापन पद्धत आहे. हे "स्प्रिंट्स" किंवा लहान पुनरावृत्तीवर आधारित आहे, कठोरपणे मर्यादित वेळेत (सामान्यतः 2-4 आठवडे). यामुळे मीटिंगचा कालावधी कमी होतो, परंतु त्यांची वारंवारता वाढते. प्रत्येक स्प्रिंटमध्ये पुनरावृत्तीच्या शेवटी पूर्ण करायच्या कार्यांची यादी असते आणि त्या प्रत्येकाचे स्वतःचे "वजन" असते. मीटिंग दरम्यान, कार्यसंघ सदस्यांनी काय केले आहे, त्यांनी काय करण्याची योजना आखली आहे आणि कोणत्या समस्या आहेत यावर चर्चा केली जाते. नियोजनासाठी Scrum बॅकलॉग वापरते. या दृष्टिकोनामध्ये, संघांमध्ये सामान्यतः एक स्क्रम मास्टर असतो. ही व्यक्ती संघाला कोणत्याही व्यत्ययाशिवाय काम करण्यास मदत करते आणि संघासाठी आरामदायक वातावरण तयार करते. प्रकल्पामध्ये उत्पादन मालकाच्या भूमिकेत कोणीतरी असेल. ही व्यक्ती विकासाची प्रमुख आहे, उत्पादनाचे निरीक्षण करते आणि ग्राहकाची विनंती आणि कार्यसंघ काय तयार करते यामधील मुख्य दुवा म्हणून कार्य करते.

साधक:

  • शक्य तितक्या कमी बजेटसह प्रकल्प द्रुतपणे सुरू करण्याची क्षमता;
  • प्रगतीचे दैनिक निरीक्षण, वारंवार प्रकल्प डेमो;
  • प्रकल्पादरम्यान समायोजन करण्याची क्षमता.

बाधक:

  • निश्चित बजेट नसल्यामुळे करार पूर्ण करण्यात अडचणी;
  • अननुभवी संघासाठी किंवा जेव्हा अंतिम मुदत किंवा बजेट कमी केले जाते तेव्हा काम करत नाही;
  • स्प्रिंट दरम्यान सतत बदल करण्याची क्षमता गोंधळ निर्माण करू शकते.

ते कोणासाठी आहे?

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

2. कानबान

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

साधक:

  • नियोजनात लवचिकता. कार्यसंघ केवळ सध्याच्या कामावर लक्ष केंद्रित करतो, कार्याचा प्राधान्यक्रम देखील परिभाषित केला जातो;
  • दृश्यमानता जेव्हा सर्व सहभागींना डेटामध्ये प्रवेश असतो, तेव्हा जागतिक समस्या शोधणे सोपे होते;
  • विकास प्रक्रियेत उच्च सहभाग. व्हिज्युअलायझिंग प्रक्रिया आत्म-संस्था आणि आत्म-नियंत्रण वाढवते.

बाधक:

  • पाचपेक्षा जास्त लोकांच्या संघांसह कार्य करत नाही;
  • दीर्घकालीन नियोजनासाठी हेतू नाही;
  • अप्रवृत्त संघासाठी योग्य नाही. कानबनकडे प्रत्येक कामाच्या वस्तूसाठी अंतिम मुदत नसते. तसेच कार्यपद्धती विलंबासाठी दंडाची तरतूद करत नाही.

ते कोणासाठी आहे?

कानबान अशा कंपन्यांमध्ये उत्कृष्ट कार्य करते जेथे कार्यसंघ वाढण्यास आणि परिणाम प्राप्त करण्यास प्रवृत्त होतो. हे आधीच स्पष्ट असले पाहिजे - हे एका लहान संघासाठी आहे. कदाचित अगदी अलिप्तता किंवा संघाचा भाग.

3. तर्कसंगत युनिफाइड प्रोसेस (RUP)

RUP पद्धत पुनरावृत्ती विकास मॉडेल वापरते. प्रत्येक पुनरावृत्तीच्या शेवटी (ज्याला 2 ते 6 आठवडे लागतात), कार्यसंघाने नियोजित उद्दिष्टे साध्य केली पाहिजेत आणि प्रकल्पाची आवृत्ती तात्पुरती असली तरी कार्य करणे आवश्यक आहे. प्रकल्पाची चार टप्प्यात विभागणी करण्याची मागणी आरयूपीने केली आहे . प्रत्येक टप्प्यात, उत्पादनाच्या पुढील पिढीवर कार्य केले जाते: प्रारंभ, विस्तार, बांधकाम आणि संक्रमण. एका टप्प्याच्या शेवटी, एक प्रकल्प मैलाचा दगड गाठला जातो. ज्या क्षणी संघ त्याच्या परिणामांचे मूल्यमापन करतो तो प्रकल्प मैलाचा दगड मानला जाऊ शकतो. याचा अर्थ असा की पद्धतीचा अर्थ असा आहे की मुख्य वैशिष्ट्ये पहिल्या टप्प्यात सोडली जातात आणि त्यानंतरच्या टप्प्यात जोडणी केली जातात.

साधक:

  • बदलत्या कार्यांना सामोरे जाणे शक्य करते, दोन्ही ग्राहकांकडून आणि कामाच्या दरम्यान उद्भवणारे बदल;
  • उत्पादनाची सतत सुधारणा सुनिश्चित करते. पुनरावृत्ती दरम्यान, आपण प्रकल्पाचे काळजीपूर्वक मूल्यांकन करू शकता;
  • कामाच्या सुरुवातीच्या टप्प्यात जोखीम ओळखणे आणि दूर करणे तसेच विकासाची गुणवत्ता प्रभावीपणे नियंत्रित करणे शक्य करते.

बाधक:

  • ही पद्धत एक लहान संघ किंवा कंपनीमध्ये अंमलात आणणे अवघड आणि अवघड आहे;
  • कार्ये सेट करण्याच्या तज्ञांच्या क्षमतेवर अवलंबून असते;
  • आवश्यकतांचे अत्यधिक दस्तऐवजीकरण आवश्यक आहे.

ते कोणासाठी आहे?

स्पष्टपणे स्थापित केलेल्या आवश्यकता आणि जोखीम असलेले मोठे प्रकल्प ज्यांना चांगल्या प्रकारे समजले आहे, जेव्हा उत्पादन शक्य तितक्या लवकर सोडले जाणे आवश्यक आहे. कार्यक्षमतेच्या खर्चावर देखील, आपल्या कोनाड्यावर द्रुतपणे कब्जा करण्यासाठी आणि नंतरच अंतिम स्पर्श जोडण्यासाठी.

अनेक पद्धती आहेत, परंतु एक कल

निर्विवादपणे लोकप्रिय असलेल्या आणि चपळ तत्त्वांवर आधारित स्क्रम आणि कानबान व्यतिरिक्त , तसेच कठोर, पुनरावृत्ती RUP पद्धती, कंपन्या अनेक पद्धतींचा वापर करतात. एक कंपनी अत्यंत प्रोग्रामिंगच्या जवळ असू शकते आणि सर्वात जलद आणि सोपे निर्णय घेऊ शकते. दुसरा चाचणी-चालित विकासाच्या जवळ असू शकतो. दुसरा अजूनही जलद अनुप्रयोग विकास (RAD) पसंत करू शकतो. असे म्हटले आहे की, एकाच वेळी अनेक पद्धती वापरण्याकडे एक मजबूत, निर्विवाद कल आहे. किंवा अगदी मॉडेल्स आणि पद्धती एकत्र करून एका अद्वितीय व्यवस्थापन प्रणालीमध्ये. आजच्या कंपन्या नोकरशाहीतील अडथळे दूर करण्यासाठी आणि विभाग आणि संस्थात्मक एकक यांच्यातील जबाबदारी न हलवता संस्थेमध्ये एकत्रित टीमवर्कचे वातावरण निर्माण करण्याचा प्रयत्न करतात. स्क्रम अलायन्सच्या मते, 70% आयटी कंपन्या स्क्रम वापरतात. त्यापैकी Google, Amazon, Salesforce, Microsoft आणि Adobe सारख्या दिग्गज आहेत. स्टार्टअप आणि तरुण प्रकल्प कानबानकडे अधिक झुकतात, परंतु टोयोटा आणि उदाहरणार्थ, वॉरगेमिंगमधील गेमर्स देखील त्याचा वापर करतात. स्क्रम हे नियोजन साधन आहे, तर कानबान हे प्रगतीचे निरीक्षण करण्यासाठी आहे. RUP साठी, ते बहुतेकदा 50-200 कर्मचारी आणि $1-10 दशलक्ष कमाई असलेल्या पाश्चात्य कंपन्या वापरतात. तथापि, IBM ने चपळ तत्त्वांच्या जवळ जाण्यासाठी RUP मध्ये सुधारणा केली, OpenUP पद्धत (RUP, पण चपळ) सोडली. ही चपळ पद्धत आता आयटी जगताला चालना देत आहे . हे केवळ उत्तीर्ण होणारे फॅड नाही - हे अजूनही नाविन्यपूर्ण आहे आणि खरं तर ते अनेक मोठ्या कंपन्यांमध्ये वापरले जाते. सिलिकॉन व्हॅलीमध्ये चपळ वापरला जातो. फेसबुक आणि उबर याचा वापर करतात.

तळ ओळ

प्रत्येक प्रकल्पाची स्वतःची सॉफ्टवेअर डेव्हलपमेंट पद्धत असते, जी कार्यसंघ, निधी, अंतिम मुदत आणि ग्राहकांच्या आवश्यकतांवर अवलंबून असते. कोणतेही सार्वत्रिक व्यवस्थापन तंत्र नाही: अत्यंत लोकप्रिय चपळ पद्धत देखील विकास प्रक्रियेसाठी सर्वोत्तम दृष्टीकोन सुनिश्चित करू शकत नाही. परिणामी, पद्धती काळजीपूर्वक निवडल्या जातात, कधीकधी तत्त्वानुसार देखील. इतकं की आपण एखाद्या कंपनीबद्दल किंवा तिच्या ग्राहकांबद्दल तिची कार्यपद्धती पाहून निष्कर्ष काढू शकतो. पद्धती मिश्रित आहेत, मॉडेलसह पूरक आहेत आणि रुपांतरित आहेत. इतकं की ते नवीन पद्धतींना जन्म देतात. असे म्हटले आहे की, व्यवस्थापन क्षेत्र शेवटी स्क्रॅम आणि कानबानच्या हातात राहते, ज्यामध्ये वॉटरफॉल मॉडेल किंवा पुनरावृत्ती RUP पद्धतीचे अनपेक्षित घटक असतात.
अधिक वाचन:
वेबसाइट्स: पुस्तके:
  • अँड्र्यू स्टेलमन, जेनिफर ग्रीन: "चपळ शिकणे";
  • प्रति क्रोल, ब्रूस मॅकइसॅक: "चपळता आणि शिस्त सहज बनवली: ओपनअप आणि आरयूपीकडून सराव";
  • माईक कोहन: "चपळ सह यशस्वी होणे: स्क्रॅम वापरून सॉफ्टवेअर विकास";
  • रॉबर्ट सी. मार्टिन: "चपळ सॉफ्टवेअर विकास: तत्त्वे, नमुने, पद्धती";
  • मार्कस हॅमरबर्ग, जोकिम सुंडेन: "कानबान इन अॅक्शन";
  • I. Jacobson, G. Booch, J. Rumbaugh: "Unified Software Development Process".