नीचे दिए गए चित्र का स्रोत हैएजिल मैनिफेस्टो वेबसाइटऔर चार एजिल मूल्यों के बयान दिखाता है।
जैसा कि आप मूल्यों के प्रस्तावना में देख सकते हैं, लेखकों ने कहा कि वे सॉफ्टवेयर विकास के लिए बेहतर तरीकों की खोज कर रहे थे और दूसरों की मदद कर रहे थे। सभी मूल्य महत्वपूर्ण हैं, लेकिन बाएं तरफ के मूल्यों को दाएं तरफ के मूल्यों की तुलना में अधिक प्राथमिकता दी गई है।
प्रक्रियाओं और उपकरणों की तुलना में व्यक्तियों और अंतरक्रियाओं पर जोर
जैसा पहले उल्लेख किया गया है, जब एजिल मैनिफेस्टो जारी किया गया था, तो इसने भारी विधियों की चुनौती दी। कैपेबिलिटी मैच्योरिटी मॉडल (CMM) और ITIL उस समय प्रक्रिया-केंद्रित दृष्टिकोण की लोकप्रिय दिशा थी।
इसलिए यह आश्चर्यजनक था कि इन विचारकों ने लोगों से शुरुआत करने का चयन किया। उन्हें लगता था कि टीम में सही लोगों को ढूंढना (व्यक्तियों) टीम के भीतर और उनके साथ प्रभावी ढंग से सहयोग करना (अंतरक्रियाएं) किसी विशिष्ट प्रक्रिया का पालन करने या विशिष्ट उपकरणों का उपयोग करने की तुलना में बहुत अधिक महत्वपूर्ण है। इसीलिए उन्होंने बाएं तरफ जोर दिया: व्यक्तियों और अंतरक्रियाओं पर।
व्यापक दस्तावेज़ीकरण की तुलना में कार्यात्मक सॉफ्टवेयर
पारंपरिक या वॉटरफॉल सॉफ्टवेयर विकास में, टीमें आवश्यकताओं को इकट्ठा करने और डिज़ाइन और विनिर्माण विवरण बनाने में महत्वपूर्ण समय बिताती थीं, और जीवनचक्र के अंत में ही कुछ भौतिक चीज़ बनाती थीं। मैनिफेस्टो के लेखकों का मानना था कि एक कार्यात्मक समाधान होना, उस समाधान के काम करने के तरीके के बारे में विस्तृत दस्तावेज़ों के एक बड़े संग्रह के बराबर होने से अधिक मूल्यवान है।
कॉन्ट्रैक्ट निगोशिएशन की तुलना में ग्राहक सहयोग
तीसरा मूल्य ग्राहक सहयोग के लिए कॉन्ट्रैक्ट निगोशिएशन है—जहां कॉन्ट्रैक्ट निगोशिएशन का अर्थ है क्षेत्र में शामिल चीजों के बारे में लड़ाई करना। उदाहरण के लिए, आप ऐसे वाक्य सुन सकते हैं जैसे “वह आपके आवश्यकता दस्तावेज़ में नहीं था।” इन विचारकों का मानना था कि ग्राहक के साथ सहयोग करके उनकी वास्तविक आवश्यकता के अनुरूप समाधान प्रदान करना बहुत अधिक महत्वपूर्ण है।
एक योजना का पालन करने की तुलना में बदलाव के प्रति प्रतिक्रिया करना
चौथा और अंतिम एजिल मूल्य योजना का पालन करने की तुलना में बदलाव के प्रति प्रतिक्रिया करना है। लेखकों को यह सहमति है कि योजना बनाना महत्वपूर्ण है—वास्तव में, एजिल टीमें बहुत योजना बनाती हैं। लेकिन इन विचारकों का मानना था कि अनिवार्य बदलावों के प्रति प्रतिक्रिया करने की क्षमता, जब जानकारी अभी भी सीमित है, तब बनाई गई योजना का पालन करने की तुलना में अधिक महत्वपूर्ण है।
मैनिफेस्टो में इन सभी मूल्यों का महत्व है, लेकिन बाएं तरफ के मूल्यों को दाएं तरफ के मूल्यों की तुलना में अधिक प्राथमिकता दी गई है।
12 एजिल सिद्धांत
इन 4 एजिल मूल्यों के अलावा, एजिल मैनिफेस्टो के लेखकों ने एक सेट के साथ सहमति जताई12 एजिल सिद्धांतजो एजिल तरीकों के काम करने के आधार के रूप में बनते हैं। जबकि इन 4 एजिल मूल्यों की तुलना में कम लोकप्रिय हैं, मुझे लगता है कि 12 एजिल सिद्धांत अधिक व्यावहारिक हैं और एजिल अभ्यासों के लिए स्पष्ट दिशा-निर्देश प्रदान करते हैं।
आसानी के लिए, मैंने 12 सिद्धांतों को नंबर दिया है, हालांकि वे आधिकारिक वेबसाइट.
- पहला सिद्धांत हैउच्चतम प्राथमिकताग्राहक को संतुष्ट करना है, जो उपयोगी सॉफ्टवेयर के जल्दी और निरंतर डिलीवरी के माध्यम से होता है। शब्द “उपयोगी सॉफ्टवेयर” कुछ लोगों को भ्रमित करता है। याद रखें, 2001 में, जब इन विचारकों ने एजिल मूल्यों और सिद्धांतों का परिचय दिया, तो उनका ध्यान केवल सॉफ्टवेयर विकास पर था। तब से, एजिल को लगभग हर उद्योग में अपनाया गया है—स्थापत्य, कार निर्माण, यहां तक कि जेट लड़ाकू विमान निर्माण में। यदि आपके लिए यह अधिक समझ में आता है, तो “उपयोगी समाधान” के स्थान पर “उपयोगी सॉफ्टवेयर” का उपयोग करें।
- दूसरा सिद्धांत यह है किपरिवर्तित आवश्यकताओं का स्वागत करें, विकास के अंतिम चरण में भी। आज के लोगों का ध्यान बदलाव को नियंत्रित करने या “स्कोप क्रीप” के प्रबंधन पर होता है, लेकिन वास्तविकता यह है कि बदलाव अवश्य होगा। एजाइल प्रक्रियाएं निर्णयों को स्थगित करती हैं, विकास चक्र को छोटा करती हैं, और अनुरोधों के समय पर विश्लेषण का समर्थन करती हैं। इससे एजाइल टीमों को त्वरित और कम लागत पर अनुकूलन करने की अनुमति मिलती है। इससे प्रतिस्पर्धी लाभ मिलता है और यह एजाइल कार्य के मुख्य स्तंभों में से एक है।
- तीसरा सिद्धांत यह है किकाम करने वाले सॉफ्टवेयर को अक्सर डिलीवर करें, कुछ हफ्तों से लेकर कुछ महीनों तक, बेहतर होगा यदि समय सीमा छोटी हो। अक्सर डिलीवरी के मुख्य लाभों में से एक यह है कि आपको फीडबैक मिलता है ताकि आप यह सुनिश्चित कर सकें कि आप सही दिशा में हैं और वास्तव में ग्राहक की आवश्यकता के अनुसार बना रहे हैं।
- चौथा एजाइल सिद्धांत यह है किव्यापार लोगों और डेवलपर्स का दैनिक रूप से सहयोग करना प्रोजेक्ट के दौरान। आज, व्यापार स्टेकहोल्डर अक्सर आवश्यकता दस्तावेज़ बनाते हैं और उन्हें डेवलपर्स के पास “दीवार के पार फेंक देते हैं।” कई महीनों या यहां तक कि कई वर्षों बाद, डेवलपर्स अंतिम परीक्षण के लिए उत्तरदायी व्यक्ति को समाधान प्रदान करते हैं—लेकिन फिर पता चलता है कि समाधान गलत तरीके से समझा गया था, गलत तरीके से बनाया गया था, या अब आवश्यक नहीं है। इस सिद्धांत का जोर इस बात पर है कि समाधान बनाने वालों और उसका उपयोग करने वालों के बीच सहयोग हो, ताकि ऐसे परिणामों से बचा जा सके।
- पांचवा एजाइल सिद्धांत यह है किप्रेरित व्यक्तियों के चारों ओर प्रोजेक्ट बनाएं, उन्हें आवश्यक वातावरण और समर्थन प्रदान करना, और उन पर भरोसा करना कि वे काम पूरा करेंगे। यह मूल रूप से तीन भागों वाली रणनीति है: लोगों को सशक्त बनाना, उन्हें स्वतंत्रता देना, और उन पर भरोसा करना।
- छठा एजाइल सिद्धांत बढ़ावा देता हैस्थायी विकास। स्पॉन्सर्स, डेवलपर्स और उपयोगकर्ता अनिश्चित काल तक एक स्थिर गति बनाए रख सकते हैं। जब मैं पहली बार टेक प्रोजेक्ट्स पर काम करने लगा, तो वे अक्सर 6 महीने, 12 महीने या उससे भी अधिक समय तक चलते थे। पहले एक या दो महीनों में कम काम पूरा करना आम था। अनुमानित रूप से, इससे अंत में विशाल क्रच अवधि आई, जिसमें विशाल कार्यभार पूरा करना आवश्यक था। टीम सदस्यों से निश्चित डेडलाइन और निश्चित स्कोप को पूरा करने के लिए रात या छुट्टियों में काम करने की अपेक्षा की जाती थी। इसे “डेथ मार्च” प्रोजेक्ट कहा जाता है। एजाइल कहता है कि आप कभी भी रात या छुट्टियों में काम नहीं करेंगे—लेकिन यह सभी के लिए स्थायी गति पर काम करने पर जोर देता है।
- सिद्धांत सात है किकाम करने वाला सॉफ्टवेयर प्रगति का मुख्य मापदंड है। पारंपरिक रूप से, प्रगति को ट्रैक करने के लिए प्रतिशत पूर्णता का उपयोग किया जाता है। प्रतिशत पूर्णता बहुत अविश्वसनीय है क्योंकि इसे आंकना मुश्किल है, खासकर जब यह 80% या 90% तक पहुंच जाता है। 90% पूर्णता का अक्सर अर्थ होता है कि केवल 10% का काम या समय बचा है। एजाइल टीमें प्रतिशत पूर्णता से बचने के लिए काम को फीचर या कार्यक्षमताओं में बांटती हैं, उन्हें छोटे-छोटे हिस्सों में बांटती हैं, और यह ट्रैक करती हैं कि इन हिस्सों को पूरा किया गया है या नहीं। इस दृष्टिकोण से भ्रामक प्रगति मापदंडों से बचा जाता है।
- आठवां सिद्धांत यह है कि डेवलपमेंट टीम को जानकारी देने और टीम के भीतर जानकारी साझा करने का सबसे प्रभावी और कुशल तरीका हैमुखामुखी बातचीत। आज, सबसे लोकप्रिय संचार उपकरण ईमेल हो सकता है। यह भेजने वाले के लिए कुशल है—बेशक, वे एक ही समय में सैकड़ों या हजारों लोगों को संदेश भेज सकते हैं। लेकिन यह वास्तविक संचार नहीं है। शोध दिखाता है कि किसी अन्य के लेख को पढ़ने में गलतफहमी के लिए बहुत जगह होती है। एजाइल प्रवर्तकों ने सीखा है कि वास्तविक साझा समझ के लिए लोगों को एक साथ लाना आवश्यक है। यदि मुखामुखी संचार संभव नहीं है, तो उपलब्ध सबसे उच्च बैंडविड्थ वाले संचार का उपयोग करें—जैसे वीडियो या फोन कॉल। यह शेयरपॉइंट पर दस्तावेज़ अपलोड करने से बहुत बेहतर है! यहां का मुख्य बिंदु यह है कि उपलब्ध सबसे उच्च बैंडविड्थ वाले संचार चैनल का उपयोग करें। मुखामुखी संवाद के प्रति प्राथमिकता देने का एक प्रभाव यह है कि एक ही एजाइल टीम के सदस्यों को एक साथ रखना तार्किक होता है। आज, बहुत संगठन इस ऐसे आवश्यक बिंदु को नजरअंदाज करते हैं।
- नौवां सिद्धांत निरंतर ध्यान केंद्रित करना हैतकनीकी उत्कृष्टता और अच्छा डिज़ाइन एजिलिटी को बढ़ावा देने के लिए। ध्यान छोटे रास्ते या तकनीकी देनदारी से बचने पर है। ऐसा न करें जो त्वरित तरीके से चीजों को तेज करे लेकिन लंबे समय में अधिक लागत लाए। यदि आप तकनीकी देनदारी को जमा करते रहेंगे, तो आप एजिलिटी खो देंगे। यह फिक्स्ड टाइमलाइन वाले वॉटरफॉल प्रोजेक्ट्स में आम है। दावा किए गए डेडलाइन को पूरा करने के लिए कोने काटे जाते हैं। समय बचाने के लिए टेस्टिंग साइकिल को कम किया या हटा दिया जा सकता है, जिससे लॉन्च के बाद उत्पादन में अधिक समस्याएं आती हैं। इसके परिणामस्वरूप आग बुझाने की गतिविधि और रखरखाव के लिए कठिन कोड बनता है।
- दसवां सिद्धांत सरलता बनाए रखने और अनावश्यक काम को हटाने के बारे में है।सरलता—काम न करने की मात्रा को अधिकतम करने की कला—आवश्यक है। अर्थात, हमें अपनी प्रक्रियाओं की समीक्षा करनी चाहिए और ऐसे कुछ भी हटाना चाहिए जो ग्राहक के लिए मूल्य नहीं जोड़ता है, इस तरह अपूर्ण काम की मात्रा को अधिकतम करते हुए भी आवश्यक चीजें प्रदान करना संभव हो।
- दसवां सिद्धांत स्व-संगठित टीमों के बारे में भी है। सबसे अच्छी वास्तुकला, आवश्यकताएं और डिज़ाइन आते हैंस्व-संगठित टीमों से। हमें उन्हें अपने काम के निकट वालों को इसे सबसे अच्छे तरीके से पूरा करने का निर्णय लेने देना चाहिए—यही इस सिद्धांत की आत्मा है।
- अंतिम सिद्धांत, संख्या 12, रिट्रोस्पेक्टिव्स के बारे में है। टीमें नियमित रूप से यह विचार करती हैं कि कैसे अधिक प्रभावी बना जा सकता है और फिरसमायोजित करें और अनुकूलित करेंअपने व्यवहार को उचित ढंग से बदलें।
आज एजाइल मूल्यों और सिद्धांत अत्यधिक क्रांतिकारी नहीं लगते, लेकिन जब इन्हें 2001 में घोषित किया गया था, तो वे बहुत क्रांतिकारी थे। इसीलिए इसे “मैनिफेस्टो” कहा गया। इन्होंने एक ऐसे काम करने के तरीके की रूपरेखा बनाई जो पिछले शताब्दी में संगठनों द्वारा काम करने के तरीके से पूरी तरह अलग थी। उससे पहले, सॉफ्टवेयर विकास लगभग औद्योगिक युग के काम के तरीकों की छवि बनाता था। नीचे चर्चा के अनुसार इस ऐतिहासिक संदर्भ को समझना आवश्यक है।
- एजाइल क्या है? स्क्रम क्या है?
- स्क्रम बनाम वॉटरफॉल बनाम एजाइल बनाम लीन बनाम कानबन
- सर्वोत्तम मुफ्त और वाणिज्यिक एजाइल उपकरण – हर स्क्रम टीम के लिए आवश्यक!
- एजाइल भ्रम: दस्तावेज़ीकरण और योजना की आवश्यकता नहीं है?
- एजाइल विकास: स्प्रिंट जीरो या नहीं?
- एजाइल विकास में सबसे आम गलतफहमियाँ
- एजाइल फ्रेमवर्क उपकरण – छोटी टीमों से लेकर एजाइल के स्केलिंग तक
- एजाइल टीमों की तुलना
- एजाइल प्रोजेक्ट मैनेजमेंट क्यों? पारंपरिक पीएम से एजाइल में संक्रमण
- सबसे लोकप्रिय एजाइल विकास दृष्टिकोण
- एजाइल मैनिफेस्टो और 12 सिद्धांत
- फीचर टीमें बनाम घटक टीमें एजाइल में
- क्वालिफाइड स्क्रम मास्टर कैसे बनें?
- एजाइल में क्रॉस-फंक्शनल टीम क्या है?
- एजाइल प्लानिंग पोकर क्या है?
- एजाइल विकास – आवर्ती और आगे बढ़ता हुआ
English
Arabic
Chinese (Simplified)
Dutch
French
German
Italian
Japanese
Korean
Portuguese
Russian
Spanish