सामग्री
- चपळ आयटी का?
- चपळ कार्यपद्धती धबधब्याच्या मॉडेलच्या समस्यांकडे कशी लक्ष देते?
- चपळाईने आयटी उद्योगावर काय परिणाम केला आहे?
- कोणतीही दोष नाही, तणाव नाही - आपले जीवन नष्ट न करता जीवन-बदलणारे सॉफ्टवेअर तयार करण्यासाठी चरण चरण बाय चरण
- चतुर्थी पद्धतींमध्ये बीटी शिफ्ट झाल्याची कारणे
- गरजा खराब व्यवस्थापन
- खराब सॉफ्टवेअर डिझाइन
- विकास मर्यादा
- वरील समस्या सोडविण्यासाठी बीटीने काय केले?
- निष्कर्ष
स्रोत: डार्कोवुझिक / ड्रीमस्टाइम.कॉम
टेकवे:
बर्‍याच लोकांसाठी सॉफ्टवेअर डेव्हलपमेंटचे धबधबे मॉडेल दशकांकरिता प्रमाणित आहे, परंतु आता त्याऐवजी बर्‍याच लवचिक चपळ पद्धतीने हे बदलले आहे.
सॉफ्टवेअर डेव्हलपमेंटची चपळ पद्धत आयटी उद्योगावर सकारात्मक परिणाम करू शकते. चपळ पद्धती अवलंबण्याचे परिणाम बर्‍याच प्रकारे मोजले जाऊ शकतात. सॉफ्टवेअर बदलांच्या विनंत्यांचे द्रुत रूपांतर, कमी बग्स, संघाची कामगिरीचे परिमाणात्मक मापन आणि अडथळे हे सर्व चपळाईच्या यशस्वी अंमलबजावणीचे प्रतिबिंब आहेत. अ‍ॅगिलचा प्रभाव यशस्वीरित्या मोजण्यासाठी एखाद्या संस्थेला अगोदर आणि चपळपणाच्या विकासाशी संबंधित विविध मेट्रिक्सची तुलना करणे आवश्यक आहे. चपळतेचा वास्तविक परिणाम केवळ महसूल वाढीमुळे किंवा निश्चित केलेल्या बगांच्या वाढी संख्येने मोजला जाऊ शकत नाही. वास्तविक परिणाम समजण्यासाठी बर्‍याच अंतर्गत बाबींचा विचार करणे आवश्यक आहे. (चपळ विकासाबद्दल अधिक माहितीसाठी, चपळ सॉफ्टवेअर डेव्हलपमेंट 101 पहा.)
चपळ आयटी का?
आयटी उद्योग मुख्यतः सॉफ्टवेअर डेव्हलपमेंटच्या धबधब्याच्या मॉडेलच्या अडचणीमुळे चपळ पद्धतीकडे वळला आहे. सामान्यत: असे दिसून आले आहे की आयटी कंपन्या ग्राहकांच्या बदलत्या मागणीला किंवा बाजारातील परिस्थितीला प्रतिसाद देऊ शकत नाहीत किंवा सॉफ्टवेअर डेव्हलपमेंटच्या धबधब्याच्या मॉडेलसह खर्च कमी करू शकत नाहीत. जरी आपण या जबरदस्त झुकास चपळ पद्धतीच्या दिशेने संतुलित केले आणि काही उत्तेजना केवळ हायपे म्हणून विचारात घेतल्यास, धबधब्याच्या मॉडेलविरूद्ध बरेच अनुभवजन्य अभिप्राय आहेत.
सरळ शब्दांत सांगायचे तर, धबधबा मॉडेल एक सॉफ्टवेअर डेव्हलपमेंट मॉडेल आहे जिथे काम एका अनुक्रमे रीतीने केले जाते - एका टप्प्यानंतर. या मॉडेलचे पाच चरण आहेत: आवश्यकता, रचना, अंमलबजावणी, सत्यापन आणि देखभाल. सहसा, एक टप्पा पूर्ण झाल्यानंतर, पूर्वीच्या टप्प्यात बदल करणे, अशक्य नसल्यास, अवघड आहे. तर, अशी धारणा अशी आहे की आवश्यकता खूपच निश्चित केल्या आहेत. अ‍ॅजिल मॉडेलमधील मुख्य फरक या विचारात आहे की आवश्यकतांमध्ये कोणताही बदल होणार नाही. चपळ गृहीत धरते की व्यवसायाच्या परिस्थिती बदलतील आणि त्याप्रमाणेच आवश्यकता देखील पूर्ण होतील. तर, सॉफ्टवेअर लहान तुकड्यांमधून एसएसवर वितरित केले जाते, तर धबधब्याच्या मॉडेलमध्ये, प्रथम वितरण किंवा रीलिझ बर्‍याच दिवसांनंतर केले जाते. (विकासाच्या अधिक माहितीसाठी, अपाचे स्पार्क रॅपिड अनुप्रयोग विकासात कशी मदत करते ते पहा.)
धबधब्याच्या मॉडेलविरूद्ध सर्वात उल्लेखनीय टीका ही अशी आहे की गरजांमध्ये कोणताही बदल होणार नाही. अगदी समजुती सदोष आणि अवास्तव आहे. उदाहरणार्थ, 2001 मध्ये, यू.के. मधील 1,027 आयटी प्रकल्पांवरील अभ्यासानुसार असे दिसून आले होते की आयटी प्रकल्प अयशस्वी होण्याचे एकमेव मोठे कारण ही गृहित धरली गेली.
दुसर्‍या उदाहरणात, "Agगिल teण्ड इटेरेटिव्ह डेव्हलपमेंट: अ मॅनेजर गाईड" या पुस्तकाचे लेखक क्रेग लॅरमन यांनी अमेरिकेतील धबधब्याचे मॉडेल वापरुन संरक्षण खात्याने (डीओडी) राबवलेल्या असंख्य प्रकल्पांमध्ये कसे अपयशी ठरले याकडे लक्ष वेधले. त्यांचे उद्दीष्ट साध्य करा. १ 1980 and० आणि १ 1990 s० च्या दशकात, डीओडीला एसटीडी २१ published the मध्ये प्रसिद्ध केलेल्या मानकांनुसार वॉटरफॉल मॉडेलचा वापर त्यांच्या सॉफ्टवेअर डेव्हलपमेंट प्रोजेक्टसाठी करणे आवश्यक होते. धक्कादायक आकडेवारीवरून असे दिसून आले आहे की यातील% 75% प्रकल्प कधीच वापरले गेले नाहीत. या अहवालानंतर सुप्रसिद्ध सॉफ्टवेअर अभियांत्रिकी तज्ज्ञ डॉ. फ्रेडरिक ब्रूक्स यांच्या अंतर्गत एक टास्क फोर्स सुरू करण्यात आले. टास्क फोर्सने “डीओडी एसटीडी २१67 like प्रमाणेच आधुनिक सर्वोत्कृष्ट सराव प्रतिबिंबित करण्यासाठी मूलगामी दुरुस्तीची आवश्यकता आहे” अशी टिप्पणी केली. विकासात्मक विकास तांत्रिकदृष्ट्या उत्तम आहे, यामुळे वेळ आणि पैशाची बचत होते. ”
धबधब्याच्या मॉडेलच्या पुढील चार गृहितक वास्तविक-परिदृश्यांमध्ये अपयशी ठरले:
- दिलेल्या आवश्यकता उचित प्रमाणात परिभाषित केल्या आहेत आणि म्हणूनच, लक्षणीय बदलणार नाहीत.
- जरी विकासाच्या टप्प्यात आवश्यकता बदलल्या तरीही त्या विकास चक्रात सामावून घेण्याइतपत लहान असतील.
- सिस्टम डिलिव्हरीनंतर सिस्टम इंटिग्रेशन योजनानुसार जाईल.
- सॉफ्टवेअर इनोव्हेशन आणि नूतनीकरण करण्यासाठी आवश्यक असलेला प्रयत्न नियोजित आणि अंदाज करण्यायोग्य वेळापत्रकानुसार जाईल.
चपळ कार्यपद्धती धबधब्याच्या मॉडेलच्या समस्यांकडे कशी लक्ष देते?
चपळ कार्यपद्धती धबधब्याच्या मॉडेलपासून मूलभूतपणे भिन्न आहे आणि ती तिच्या गृहितकांपासून स्पष्ट आहे:
- कोणालाही नाही, अगदी ग्राहकदेखील नाही, तर गरजा पूर्ण जाणून घेऊ किंवा समजू शकत नाहीत. आवश्यकता बदलणार नाहीत याची शाश्वती नाही.
- आवश्यक बदल कदाचित लहान आणि व्यवस्थापित नसावेत. खरं तर, ते विविध आकारात येतील आणि येतच राहतील. तर, बदलांचा मागोवा ठेवण्यासाठी सॉफ्टवेअर लहान वेतनवाढीत वितरित केले जाईल.
चपळाईने आयटी उद्योगावर काय परिणाम केला आहे?
चपळाई बर्‍याच ठिकाणी अवलंबली जात आहे, तर बर्‍याच कंपन्या अ‍ॅजीलचा अवलंब करण्याचा विचार करीत आहेत. चपळाईने आयटी उद्योगात निश्चितपणे मूलभूत बदल केले असले तरी वस्तुस्थिती आणि आकडेवारी मिळवणे अजूनही थोडे अवघड आहे. परंतु खाली दिलेली ब्रिटीश टेलिकॉम (बीटी) च्या केस स्टडीद्वारे अ‍ॅगिलचा परिणाम समजू शकतो.
कोणतीही दोष नाही, तणाव नाही - आपले जीवन नष्ट न करता जीवन-बदलणारे सॉफ्टवेअर तयार करण्यासाठी चरण चरण बाय चरण
जेव्हा कोणालाही सॉफ्टवेअर गुणवत्तेची काळजी नसते तेव्हा आपण आपली प्रोग्रामिंग कौशल्ये सुधारू शकत नाही.
चतुर्थी पद्धतींमध्ये बीटी शिफ्ट झाल्याची कारणे
बीटीने 2004 मध्ये त्याच्या सॉफ्टवेअर डेव्हलपमेंट प्रॅक्टिसमध्ये बर्‍याच समस्या अनुभवण्यास सुरुवात केली. बीटीने बरेच साधे व गुंतागुंतीचे सॉफ्टवेअर प्रकल्प विकसित केले. बर्‍याच सॉफ्टवेअर प्रोजेक्ट्स मान्य केलेल्या मुदतीत गुणवत्ता आउटपुट विकसित करण्यात अक्षम होते. बीटीला आढळले की धडधड्यांच्या मॉडेलवर या समस्येचे मूळ आहे. तर, धबधब्याच्या मॉडेलला मजबुतीकरण मदत करणार नाही. समस्यांची मुख्य कारणे खाली दिली आहेत:
गरजा खराब व्यवस्थापन
- बर्‍याच गरजा खूप मर्यादित काळात पूर्ण केल्या गेल्या.
- बर्‍याच आवश्यकता व्यवसायाच्या गरजेशी संबंधित नसतात.
- जवळजवळ सर्वच नसल्यास सर्व आवश्यकतांना उच्च-प्राथमिकता दर्जा प्रदान केला गेला नाही.
- भविष्यातील परिस्थितीवर डोळा न ठेवता सध्याच्या व्यवसायाच्या गरजा दर्शविलेल्या आवश्यकता. यामुळे भविष्यातील सॉफ्टवेअर बदलांची शक्यता बाकी आहे.
खराब सॉफ्टवेअर डिझाइन
- मोठ्या संख्येने आवश्यकता दिल्यास, डिझाइनर्सनी आवश्यकतांचा अर्थ काय आहे हे शोधून काढण्यासाठी बराच वेळ घालवला. वास्तविक डिझाइनसाठी थोडा वेळ शिल्लक होता.
- विश्लेषकांना आवश्यक असे लेखन, कार्यवाही ज्ञान घेऊन इतर कार्य सोपविण्यात आले.
- वरील दोन घटकांमुळे खराब डिझाइन झाले. डिझाइनर्सना अद्याप मूळ टाइमलाइननुसार वितरित करावे लागले.
विकास मर्यादा
सदोष सॉफ्टवेअर डिझाइनमुळे कोडिंग घाईघाईने व निकृष्ट दर्जाची होती. विकसकांना हे समजेल की खराब सॉफ्टवेअर डिझाइनचा परिणाम खराब कोड होईल परंतु तरीही मान्य केलेल्या टाइमलाइनद्वारे वितरित करावे लागले. एकत्रिकरणा दरम्यान बर्‍याच बग नोंदवले जातील कारण युनिट चाचण्या आणि रिग्रेशन टेस्ट चालवल्या नव्हत्या.
सॉफ्टवेअर तैनात केल्यावर, ग्राहक लक्षात घेते की गरजा आधीपासूनच बदलल्या आहेत आणि व्यवसायाची परिस्थिती देखील आहे. सॉफ्टवेअरमध्येही बरीच समस्या आहेत. प्रभावीपणे, सॉफ्टवेअर विकसित करण्याच्या संपूर्ण प्रयत्नांना आता अपव्यय मानले जाते.
वरील समस्या सोडविण्यासाठी बीटीने काय केले?
बीटीच्या लक्षात आले की धबधब्याच्या मॉडेलला मजबुतीकरण देणे ही समस्यांचे उत्तर नाही. त्यासाठी नवीन दृष्टिकोन आवश्यक होता. म्हणूनच, चपळ दृष्टीकोन लागू करण्याचा निर्णय घेतला. नवीन पध्दतीअंतर्गत, पुढील गोष्टी ठरविल्या गेल्या:
- १२ महिन्यांच्या विकास चक्र ऐवजी बीटी आता-० दिवसांच्या चक्रात सॉफ्टवेअरचे कार्यक्षम तुकडे वितरित करेल. एक किंवा दोन व्यवसायिक समस्यांवर लक्ष केंद्रित करणे आणि 90 दिवसांच्या आत सॉफ्टवेअर समाधान वितरीत करण्याचे लक्ष्य ठेवले होते. या सायकलची सुरुवात वेगवेगळ्या भागधारकांमधील तीव्र चर्चेने चिन्हांकित केली जेणेकरुन आवश्यकता स्पष्टपणे ओळखल्या गेल्या, त्यांचे विश्लेषण केले गेले आणि प्राधान्य दिले गेले.
- स्पष्ट, मूर्त व्यवसाय मूल्ये वितरित करण्याचे लक्ष्य होते. अंतर्गत ग्राहकांवर स्पष्ट आवश्यकता पुरवण्यासाठी दबाव होता. तर, अस्पष्ट ध्येयांऐवजी, वापरकर्ता कथा स्पष्ट स्वीकृती निकषांसह देण्यात आल्या.
- वितरित केले जाणारे सॉफ्टवेअरचे संपूर्ण चाचणी व दस्तऐवजीकरण केले जाईल. आधी येणार्‍या अडचणी ओळखण्यासाठी सॉफ्टवेअर वारंवार एकत्रिकरण चाचण्या करत असते.
चपळ पध्दतीने, बीटी बदलण्याची आवश्यकता किंवा व्यवसाय परिस्थितीशी सहजतेने जुळवून घेऊ शकेल. कोडची गुणवत्ता सुधारली आणि शेवटच्या-मिनिटातील मूलभूत बग संबोधित केले.
निष्कर्ष
चपळ, त्याच्या सर्व फायद्यांसाठी आणि सभोवतालच्या संप्रेषणासाठी अजूनही अशा टप्प्यावर आहे जिथे त्याची संभाव्यता पूर्णपणे जाणलेली नाही. याचे कारण असे की बर्‍याच संस्था त्याच्या मूळ तत्त्वांमध्ये बदल करण्याच्या दृष्टिकोनास दृष्टिकोन सानुकूलित करतात. परिणामी धबधब्याचे मॉडेल काही प्रकरणांमध्ये पुनरागमन करीत आहे. सानुकूलितता चालूच राहिल्यास, अ‍ॅजिल्सची मूलभूत तत्त्वे टिकवून ठेवणे आवश्यक आहे. बर्‍याच संस्था पूर्णपणे चपळ असल्याचा दावा करतात, परंतु खरोखरच चपळ कंपनी होण्यासाठी त्यांच्याकडे अद्याप जाण्यासाठी काही मार्ग आहे.