विषय
- क्यों चपल?
- चंचल कार्यप्रणाली जलप्रपात मॉडल की समस्याओं का समाधान कैसे करती है?
- चंचल ने आईटी उद्योग को कैसे प्रभावित किया है?
- नो बग्स, नो स्ट्रेस - योर स्टेप बाय स्टेप गाइड बाय स्टेप गाइड टू लाइफ-चेंजिंग सॉफ्टवेर विदाउट योर लाइफ
- कारण बीटी को चुस्त प्रथाओं में स्थानांतरित कर दिया गया
- आवश्यकताओं का गरीब प्रबंधन
- खराब सॉफ्टवेयर डिजाइन
- विकास की बाधाएँ
- उपरोक्त समस्याओं को दूर करने के लिए बीटी ने क्या किया?
- निष्कर्ष
स्रोत: Darkovujic / Dreamstime.com
ले जाओ:
कई लोगों के लिए, सॉफ्टवेयर डेवलपमेंट का वाटरफॉल मॉडल दशकों से मानक है, लेकिन इसे अब बहुत अधिक लचीले एजाइल पद्धति से प्रतिस्थापित किया जा रहा है।
सॉफ्टवेयर विकास के लिए चुस्त कार्यप्रणाली आईटी उद्योग को सकारात्मक रूप से प्रभावित कर सकती है। चंचल कार्यप्रणाली अपनाने के परिणामों को कई तरीकों से मापा जा सकता है। सॉफ्टवेयर परिवर्तन अनुरोधों की त्वरित वापसी, कम कीड़े, टीम के प्रदर्शन की मात्रात्मक माप और अड़चनें, फुर्तीली के सफल कार्यान्वयन के सभी प्रतिबिंब हैं। एजाइल के प्रभाव को सफलतापूर्वक मापने के लिए, एक संगठन को पूर्व-चुस्त और बाद के चुस्त विकास से संबंधित विभिन्न मैट्रिक्स की तुलना करने की आवश्यकता है। Agile के वास्तविक प्रभाव को केवल राजस्व में वृद्धि या बग की निश्चित संख्या से नहीं मापा जा सकता है। वास्तविक प्रभाव को समझने के लिए कई आंतरिक मापदंडों पर विचार करने की आवश्यकता है। (चंचल विकास पर अधिक जानकारी के लिए, चंचल सॉफ्टवेयर विकास 101 देखें।)
क्यों चपल?
आईटी उद्योग मुख्य रूप से सॉफ्टवेयर विकास के झरना मॉडल की बाधाओं के कारण चंचल प्रथाओं की ओर झुकाव रहा है। आम तौर पर, यह देखा गया है कि आईटी कंपनियां ग्राहक की मांग या बाजार की स्थितियों को बदलने या सॉफ़्टवेयर विकास के झरना मॉडल के साथ लागत को कम करने में असमर्थ हैं। यहां तक कि अगर हम फुर्तीली कार्यप्रणाली के प्रति इस भारी झुकाव का प्रतिकार करते हैं और कुछ उत्साह को सिर्फ प्रचार मानते हैं, तो झरना मॉडल के खिलाफ बहुत अधिक अनुभवजन्य प्रतिक्रिया है।
सीधे शब्दों में कहें, झरना मॉडल एक सॉफ्टवेयर विकास मॉडल है जहां काम क्रमबद्ध तरीके से किया जाता है - एक के बाद एक चरण। इस मॉडल के पाँच चरण हैं: आवश्यकताएँ, डिज़ाइन, कार्यान्वयन, सत्यापन और रखरखाव। आमतौर पर, एक चरण पूरा होने के बाद, यह मुश्किल है, अगर असंभव नहीं है, तो पहले चरण में परिवर्तन करना। तो, धारणा यह है कि आवश्यकताओं को बहुत अधिक तय किया जाता है। एजाइल मॉडल के साथ मुख्य अंतर इस धारणा में है कि आवश्यकताओं में कोई बदलाव नहीं होगा। चंचलता मानती है कि व्यावसायिक परिस्थितियां बदल जाएंगी और इसलिए आवश्यकताओं की पूर्ति होगी। इसलिए, सॉफ्टवेयर को ss के मुकाबले छोटे चंक्स में वितरित किया जाता है, जबकि झरने के मॉडल में, पहली डिलीवरी या रिलीज लंबे समय के बाद की जाती है। (विकास के बारे में अधिक जानकारी के लिए देखें कैसे अपाचे स्पार्क रैपिड एप्लिकेशन डेवलपमेंट में मदद करता है।)
झरना मॉडल के खिलाफ सबसे उल्लेखनीय आलोचना इसकी धारणा रही है कि आवश्यकताओं में कोई बदलाव नहीं होगा। बहुत धारणा त्रुटिपूर्ण और अवास्तविक है। उदाहरण के लिए, 2001 में, यू.के. में 1,027 आईटी परियोजनाओं पर एक अध्ययन से पता चला कि यह धारणा आईटी परियोजनाओं की विफलता का एकमात्र सबसे बड़ा कारण थी।
एक अन्य उदाहरण में, "एजाइल एंड इटरेटिव डेवलपमेंट: ए मैनेजरज गाइड" पुस्तक के लेखक क्रेग लर्मन ने बताया है कि कैसे अमेरिका में जलप्रपात मॉडल का उपयोग करके रक्षा विभाग (DoD) द्वारा निष्पादित कई परियोजनाएं विफल रहीं। अपने उद्देश्यों को प्राप्त करें। 1980 और 1990 के दशक में, DoD को अपने सॉफ्टवेयर विकास परियोजनाओं के लिए DoD STD 2167 में प्रकाशित मानकों के अनुसार झरना मॉडल का उपयोग करना आवश्यक था। चौंकाने वाले आंकड़ों से पता चला कि इन सॉफ्टवेयर परियोजनाओं में से 75% का कभी उपयोग नहीं किया गया था। इस रिपोर्ट के बाद, एक प्रसिद्ध सॉफ्टवेयर इंजीनियरिंग विशेषज्ञ डॉ। फ्रेडरिक ब्रूक्स के तहत एक टास्क फोर्स का शुभारंभ किया गया। टास्क फोर्स ने एक रिपोर्ट के साथ कहा कि "DoD STD 2167 में टिप्पणी की गई है, इसी तरह आधुनिक सर्वोत्तम अभ्यास को प्रतिबिंबित करने के लिए एक कट्टरपंथी की आवश्यकता है। विकासवादी विकास तकनीकी रूप से सर्वोत्तम है, इससे समय और धन की बचत होती है। ”
झरना मॉडल की निम्नलिखित चार धारणाएँ वास्तविक दुनिया के परिदृश्यों में विफल रही थीं:
- दी गई आवश्यकताओं को यथोचित रूप से परिभाषित किया गया है और इसलिए, यह महत्वपूर्ण रूप से नहीं बदलेगी।
- यहां तक कि अगर विकास के चरण के दौरान आवश्यकताओं में परिवर्तन होता है, तो वे विकास चक्र के भीतर समायोजित होने के लिए काफी छोटा होगा।
- सिस्टम एकीकरण, जो सॉफ्टवेयर डिलीवरी के बाद होता है, योजना के अनुसार होगा।
- सॉफ्टवेयर नवाचार और नवाचार करने के लिए आवश्यक प्रयास एक नियोजित और पूर्वानुमेय अनुसूची के अनुसार जाएंगे।
चंचल कार्यप्रणाली जलप्रपात मॉडल की समस्याओं का समाधान कैसे करती है?
चंचल कार्यप्रणाली मूल रूप से झरने के मॉडल से अलग है और इसकी मान्यताओं से स्पष्ट है:
- कोई भी, ग्राहक भी नहीं, आवश्यकताओं को पूरी तरह से जान या समझ सकता है। इस बात की कोई गारंटी नहीं है कि आवश्यकताएं नहीं बदलेंगी।
- आवश्यकता परिवर्तन छोटे और प्रबंधनीय नहीं हो सकते हैं। वास्तव में, वे विभिन्न आकारों में आएंगे और आते रहेंगे। इसलिए, परिवर्तनों को ट्रैक करने के लिए सॉफ़्टवेयर को छोटे वेतन वृद्धि में वितरित किया जाएगा।
चंचल ने आईटी उद्योग को कैसे प्रभावित किया है?
एजाइल को कई जगहों पर अपनाया जा रहा है, जबकि बहुत सारी कंपनियां एजाइल को अपनाने की योजना बना रही हैं। हालांकि एजाइल ने निश्चित रूप से आईटी उद्योग में मूलभूत परिवर्तन किए हैं, तथ्य और आंकड़े अभी भी प्राप्त करना थोड़ा मुश्किल है। लेकिन Agile के प्रभाव को नीचे दिए गए ब्रिटिश टेलीकॉम (BT) के केस स्टडी से समझा जा सकता है।
नो बग्स, नो स्ट्रेस - योर स्टेप बाय स्टेप गाइड बाय स्टेप गाइड टू लाइफ-चेंजिंग सॉफ्टवेर विदाउट योर लाइफ
जब कोई भी सॉफ़्टवेयर गुणवत्ता की परवाह नहीं करता है तो आप अपने प्रोग्रामिंग कौशल में सुधार कर सकते हैं।
कारण बीटी को चुस्त प्रथाओं में स्थानांतरित कर दिया गया
बीटी ने 2004 में अपने सॉफ्टवेयर विकास प्रथाओं के साथ कई समस्याओं का अनुभव करना शुरू किया। बीटी ने सरल और जटिल दोनों सॉफ्टवेयर प्रोजेक्ट विकसित किए। कई सॉफ्टवेयर परियोजनाएं सहमत समय सीमा के भीतर गुणवत्ता आउटपुट विकसित करने में असमर्थ थीं। बीटी ने पाया कि समस्याओं की जड़ें झरने के मॉडल से हैं। इसलिए, झरना मॉडल को मजबूत करना मदद करने वाला नहीं था। समस्याओं के मुख्य कारण नीचे दिए गए हैं:
आवश्यकताओं का गरीब प्रबंधन
- बहुत सी आवश्यकताओं को बहुत सीमित समय के भीतर पूरा करने के लिए दिया गया था।
- कई आवश्यकताएँ व्यावसायिक आवश्यकताओं के लिए अप्रासंगिक थीं।
- लगभग सभी, यदि सभी आवश्यकताओं को उच्च-प्राथमिकता का दर्जा नहीं दिया गया था।
- भविष्य के परिदृश्यों पर कोई नज़र नहीं रखने के साथ वर्तमान व्यावसायिक आवश्यकताओं का प्रतिनिधित्व करती है। यह भविष्य के सॉफ़्टवेयर परिवर्तनों की संभावना को छोड़ देता है।
खराब सॉफ्टवेयर डिजाइन
- आवश्यकताओं की बड़ी संख्या को देखते हुए, डिजाइनरों ने बहुत अधिक समय खर्च किया और यह पता लगाने की कोशिश की कि आवश्यकताओं का क्या मतलब है। वास्तविक डिज़ाइन के लिए बहुत कम समय बचा था।
- आवश्यकता विश्लेषकों ने उन्हें अलिखित, मौन ज्ञान के साथ लेते हुए अन्य असाइनमेंट में स्थानांतरित किया।
- उपरोक्त दो कारक खराब डिजाइन के कारण बने। डिजाइनरों को अभी भी मूल समय के अनुसार वितरित करना था।
विकास की बाधाएँ
त्रुटिपूर्ण सॉफ़्टवेयर डिज़ाइन के कारण कोडिंग जल्दबाजी और खराब गुणवत्ता का था। डेवलपर्स को एहसास होगा कि एक खराब सॉफ्टवेयर डिजाइन के परिणामस्वरूप खराब कोड होगा, लेकिन फिर भी सहमत समयरेखा द्वारा वितरित करना होगा। एकीकरण के दौरान बहुत सारे बगों की सूचना दी जाएगी क्योंकि यूनिट परीक्षण और प्रतिगमन परीक्षण नहीं चलाए गए थे।
जब तक सॉफ़्टवेयर को तैनात किया जाता है, तब तक ग्राहक ध्यान देता है कि आवश्यकताओं में पहले से बदलाव आया है और इसलिए व्यवसाय परिदृश्य भी है। सॉफ्टवेयर में भी बहुत सारी समस्याएं हैं। प्रभावी रूप से, सॉफ्टवेयर विकास का संपूर्ण प्रयास अब अपव्यय माना जाता है।
उपरोक्त समस्याओं को दूर करने के लिए बीटी ने क्या किया?
बीटी ने महसूस किया कि झरना मॉडल को मजबूत करना समस्याओं का जवाब नहीं था। इसे एक नए दृष्टिकोण की आवश्यकता थी। इसलिए, इसने एजाइल दृष्टिकोण को लागू करने का निर्णय लिया। नए दृष्टिकोण के तहत, निम्नलिखित बातें तय की गईं:
- 12 महीने के विकास चक्र के बजाय, बीटी अब एक 90-दिवसीय चक्र में काम करने योग्य सॉफ्टवेयर वितरित करेगा। यह विचार एक या दो व्यावसायिक समस्याओं पर ध्यान केंद्रित करने और 90 दिनों के भीतर एक सॉफ्टवेयर समाधान देने का लक्ष्य था। इस चक्र की शुरुआत विभिन्न हितधारकों के बीच गहन चर्चा द्वारा चिह्नित की गई थी ताकि आवश्यकताओं को स्पष्ट रूप से पहचाना, विश्लेषण और प्राथमिकता दी गई।
- लक्ष्य स्पष्ट, मूर्त व्यावसायिक मूल्यों को वितरित करना था। आंतरिक ग्राहक स्पष्ट आवश्यकताओं को प्रदान करने के लिए दबाव में था। इसलिए, अस्पष्ट लक्ष्यों के बजाय, उपयोगकर्ता कहानियों को स्पष्ट स्वीकृति मानदंडों के साथ दिया गया था।
- वितरित किए जाने वाले सॉफ़्टवेयर का पूरी तरह से परीक्षण और दस्तावेज़ किया जाएगा। सॉफ्टवेयर पहले से ही समस्याओं को पहचानने के लिए लगातार एकीकरण परीक्षणों से गुजरेगा।
चंचल दृष्टिकोण के साथ, बीटी बदलती आवश्यकताओं या व्यावसायिक स्थितियों को अधिक आसानी से अपना सकता है। कोड की गुणवत्ता में सुधार हुआ और अंतिम मिनट के बुनियादी कीड़े को संबोधित किया गया।
निष्कर्ष
फुर्तीली, अपने सभी लाभों और इसके चारों ओर प्रचार के लिए, अभी भी एक ऐसे चरण में है जहां इसकी क्षमता पूरी तरह से महसूस नहीं की गई है। ऐसा इसलिए है क्योंकि बहुत सारे संगठन अपने मूल सिद्धांतों को संशोधित करने के लिए दृष्टिकोण को अनुकूलित कर रहे हैं। नतीजतन, झरना मॉडल कुछ मामलों में वापसी कर रहा है। जबकि अनुकूलन जारी रहेगा, एगलेस मूल सिद्धांतों को बनाए रखना महत्वपूर्ण है। बहुत सारे संगठन पूरी तरह से फुर्तीले होने का दावा करते हैं, लेकिन वास्तव में चुस्त कंपनी बनने के लिए उनके पास अभी भी कोई रास्ता नहीं है।