मेन्यू

एजाइल मेनिफेस्टो: अंडरस्टैंडिंग एज़ाइल वैल्यूज़ एंड प्रिंसिपल्स

  • मुख्य
  • अन्य
  • एजाइल मेनिफेस्टो: अंडरस्टैंडिंग एज़ाइल वैल्यूज़ एंड प्रिंसिपल्स

agile manifesto understanding agile values

समस्याओं को खत्म करने के लिए हमारे साधन का प्रयास करें

चंचल घोषणापत्र परिचय:

हमारा पिछला ट्यूटोरियल चंचल कार्यप्रणाली हम सभी को फुर्तीली मॉडल और कार्यप्रणाली के बारे में विस्तार से बताया।

लेकिन अब तक हम इस बारे में विचार नहीं कर रहे हैं कि पहले स्थान पर चुस्त-दुरुस्त रहने की आवश्यकता क्यों थी और जल-प्रवाह मॉडल की तरह मौजूदा सॉफ्टवेयर विकास के तरीकों की खामियों को कैसे काबू किया गया।

इस ट्यूटोरियल में, हम चुस्त और फुर्तीले घोषणापत्र के विवरण में गहराई से जाएंगे। हम देखेंगे कि घोषणापत्र क्या कहता है और इसमें निहित मूल्य और सिद्धांत क्या हैं।

चुस्त प्रकट

आप क्या सीखेंगे:

परिचय

जैसा कि हमने अपने में देखा पिछले ट्यूटोरियल , पहले के विकास के तरीकों में बहुत अधिक समय लगता था और जब तक सॉफ्टवेयर तैनाती के लिए तैयार हो जाता था, तब तक व्यावसायिक आवश्यकताएं बदल जाती थीं, इस प्रकार वर्तमान जरूरतों के लिए खानपान नहीं होता।

उस समय जिस परिवर्तन की कमी थी, वह बहुत सारी समस्याएं पैदा कर रहा था। जब विभिन्न विकास पद्धतियों के नेता आगे के रास्ते पर निर्णय लेने के लिए मिले, और वे एक बेहतर विधि पर सहमत होने में सक्षम थे और घोषणा पत्र के लिए शब्दांकन को अंतिम रूप देने में भी सक्षम थे।

इसे 4 मानों और 12 सिद्धांतों के रूप में कैप्चर किया गया था ताकि चिकित्सकों को समझने, इसे संदर्भित करने और इसे अभ्यास में लाने में मदद मिल सके। और उस समय में, उनमें से कोई भी इस प्रभाव की कल्पना नहीं कर सकता था कि यह परियोजना प्रबंधन के भविष्य पर होगा।

चंचल मेनिफेस्टो

घोषणापत्र को बहुत सावधानी से न्यूनतम शब्दों में चंचलता को पकड़ने के लिए कहा गया है और यह नीचे के रूप में पढ़ता है -

“हम एक सॉफ्टवेयर विकसित करने के बेहतर तरीकों को उजागर कर रहे हैं और इसे करने में दूसरों की मदद कर रहे हैं। इस काम के माध्यम से हम नीचे दिए गए मूल्य पर आए हैं:

  • व्यक्तियों और प्रक्रियाओं और उपकरणों पर बातचीत।
  • व्यापक प्रलेखन पर काम कर रहे सॉफ्टवेयर।
  • अनुबंध बातचीत पर ग्राहक सहयोग।
  • एक योजना के बाद बदलने के लिए प्रतिक्रिया।

यही है, जबकि दाईं ओर की वस्तुओं में मूल्य है, हम वस्तुओं को बाईं ओर अधिक महत्व देते हैं। ”

जैसा कि हम देख सकते हैं, ये बहुत संक्षिप्त और सरल कथन हैं और यह बहुत स्पष्ट करते हैं कि संस्थापक क्या प्रचार करना चाहते थे। आमतौर पर, पारंपरिक परियोजना योजनाएं कठोर होती हैं और वे प्रक्रियाओं और समयसीमाओं पर जोर देती हैं, लेकिन चुस्त घोषणापत्र बिल्कुल विपरीत चीजों का प्रचार करता है।

यह पसंद करता है:

  • लोग
  • उत्पाद
  • संचार और
  • जवाबदेही

हम इस नए प्रतिमान का पता लगाएंगे, जो संस्थापक चुस्त मूल्यों और सिद्धांतों की गहरी समझ प्राप्त करके विस्तार से प्रचार करना चाहते थे।

4 चंचल मूल्य

12 सिद्धांतों के साथ चार मूल्य फुर्तीली सॉफ्टवेयर डिलीवरी को निर्देशित करते हैं। हम प्रत्येक मूल्यों पर अब विस्तार से चर्चा करेंगे।

चंचल भाव

# 1) व्यक्तियों और प्रक्रियाओं और उपकरणों पर बातचीत

व्यक्तियों और इंटरैक्शन को प्रक्रियाओं और उपकरणों पर पसंद किया जाता है क्योंकि यह प्रक्रिया को अधिक संवेदनशील बनाता है। यदि व्यक्तियों को संरेखित किया जाता है और एक बार वे एक दूसरे को समझते हैं, तो टीम उपकरण या प्रक्रियाओं के साथ किसी भी मुद्दे को हल कर सकती है।

लेकिन अगर टीमें नेत्रहीन रूप से प्रक्रियाओं से चिपके रहने पर जोर देती हैं तो यह व्यक्तियों के बीच गलतफहमी पैदा कर सकता है और अप्रत्याशित बाधाएं पैदा कर सकता है जिससे परियोजना में देरी होती है।

यही कारण है कि हमेशा आगे बढ़ने के मार्ग के मार्गदर्शन के लिए प्रक्रियाओं के आधार पर नेत्रहीन के बजाय टीम के सदस्यों के बीच बातचीत और संचार करना बेहतर होता है। इसे प्राप्त करने के तरीकों में से एक शामिल उत्पाद स्वामी है जो काम करता है और विकास टीम के साथ मिलकर निर्णय ले सकता है।

व्यक्तियों को अपने दम पर योगदान करने की अनुमति देना भी उन्हें स्वतंत्र रूप से प्रदर्शित करने की अनुमति देता है कि वे मेज पर क्या ला सकते हैं। जब इन टीम इंटरैक्शन को एक आम समस्या को हल करने की दिशा में निर्देशित किया जाता है, तो परिणाम काफी शक्तिशाली हो सकते हैं।

# 2) व्यापक प्रलेखन पर कार्य सॉफ्टवेयर

पारंपरिक परियोजना प्रबंधन में व्यापक दस्तावेज शामिल थे जो कई महीनों तक चले। यह परियोजना के वितरण को नकारात्मक रूप से प्रभावित करता था और परिणामस्वरूप देरी अपरिहार्य थी।

इन परियोजनाओं के लिए बनाए गए दस्तावेज़ों का प्रकार बहुत विस्तृत था और इतने सारे दस्तावेज़ बनाए गए थे कि उनमें से कई परियोजना प्रगति के दौरान भी संदर्भित नहीं थे। यह एक अनावश्यक बुराई थी जिसके साथ परियोजना की टीमें रहती थीं।

लेकिन इसने डिलीवरी में आने वाली समस्याओं को भी बढ़ा दिया। ध्यान इस हद तक प्रलेखन पर था क्योंकि टीमें एक तैयार उत्पाद के साथ समाप्त करना चाहती थीं जो विनिर्देशों के अनुसार 100% थी। इसीलिए सभी विशिष्टताओं को विवरण में कैद करने पर ध्यान केंद्रित किया गया था।

लेकिन फिर भी, अंतिम उत्पाद उम्मीदों से काफी अलग हुआ करता था या प्रासंगिकता खो देता था। यही कारण है कि चुस्त कहते हैं कि प्रलेखन के ढेर की तुलना में ग्राहकों की अपेक्षा को कम करने के लिए एक कार्यशील सॉफ्टवेयर एक बेहतर विकल्प है।

इसका मतलब यह नहीं है कि प्रलेखन आवश्यक नहीं है। इसका मतलब सिर्फ यह है कि एक काम करने वाला उत्पाद किसी भी दिन पहले बनाए गए दस्तावेज़ की तुलना में ग्राहक की जरूरतों और अपेक्षाओं के लिए संरेखण का एक बेहतर संकेतक है। इसका अर्थ यह भी है कि टीमें संवेदनशील हैं और स्प्रिंट के समाप्त होने पर क्लाइंट को काम करने वाले सॉफ्टवेयर दिखाते समय आवश्यकतानुसार बदलाव के लिए तैयार हैं।

स्प्रिंट के दौरान उत्पाद का परीक्षण करने में विफलता अगले स्प्रिंट में कई गुना लागत और प्रयास लेती है। एक बार कार्यक्षमता को तैनात करने के बाद, इन परिवर्तनों की लागत एक महत्वपूर्ण डिग्री से आगे बढ़ जाती है।

3. ग्राहक सहयोग अनुबंध पर बातचीत

बातचीत का मतलब है कि विवरण अभी भी पकड़े जा रहे हैं और अंतिम रूप नहीं दिए गए हैं। अभी भी पुनर्जागरण की गुंजाइश है। लेकिन एक बार बातचीत खत्म होने के बाद इस पर कोई चर्चा नहीं हो सकती है। चपल क्या कहता है कि बातचीत के बजाय, सहयोग के लिए जाएं।

सहयोग का अर्थ है कि चर्चा के लिए अभी भी जगह है और संचार जारी है।

एक बार की बात नहीं। यह क्या करता है, यह दो-गुना लाभ देता है - जबकि यह टीम को एक सुधार करने में मदद करता है यदि पहले चरण में आवश्यक हो, तो यह ग्राहक को उनकी दृष्टि को परिष्कृत करने और यदि आवश्यक हो तो उनकी आवश्यकताओं को फिर से परिभाषित करने में मदद करता है परियोजना।

दूसरा पहलू यह है कि जबकि पारंपरिक सॉफ्टवेयर डेवलपमेंट मॉडल डॉक्यूमेंटेशन और बातचीत के चरण के दौरान विकास शुरू होने से पहले ग्राहक को शामिल करते हैं, और वे प्रोजेक्ट डेवलपमेंट के दौरान शामिल नहीं होते हैं।

एक बार आवश्यकताओं के जमे हुए होने के बाद, वे उत्पाद को देखने के लिए केवल एक बार तैयार होते हैं। पूरे जीवनचक्र के दौरान ग्राहकों की भागीदारी के लिए अनुमति देने के साथ ही इस बाधा से चुस्त हो जाता है।

यह चुस्त टीमों को ग्राहक की जरूरतों के लिए बेहतर संरेखित करने में मदद करता है। इसे प्राप्त करने के तरीकों में से एक एक समर्पित और शामिल उत्पाद स्वामी के माध्यम से है जो टीम को स्पष्टीकरण के लिए वास्तविक समय में मदद कर सकता है और ग्राहक प्राथमिकताओं के साथ काम को संरेखित कर सकता है।

मेरे एसक्यूएल साक्षात्कार प्रश्न और उत्तर पीडीएफ

4. एक योजना के बाद परिवर्तन पर प्रतिक्रिया

मानक विचार प्रक्रिया यह है कि परिवर्तन एक महंगा मामला है और हमें हर कीमत पर बदलाव से बचना चाहिए। प्रलेखन और विस्तृत योजनाओं पर समयबद्धता और उत्पाद विनिर्देशों को ध्यान में रखते हुए इस पर अनावश्यक ध्यान केंद्रित किया गया है।

लेकिन जैसा कि अनुभव हमें सिखाता है, परिवर्तन ज्यादातर अपरिहार्य हैं और इसके बजाय इसे चलाने से हमें इसे गले लगाने और इसके लिए योजना बनाने की कोशिश करनी चाहिए।

चंचल हमें यह संक्रमण करने की अनुमति देता है। चुस्त सोचता है कि परिवर्तन एक खर्च नहीं है, यह एक स्वागत योग्य प्रतिक्रिया है जो परियोजना को बेहतर बनाने में मदद करता है। इसे टालना नहीं है बल्कि इसके बजाय, यह मूल्य जोड़ता है।

चुस्त द्वारा प्रस्तावित छोटे स्प्रिंट के साथ, टीमों को एक त्वरित प्रतिक्रिया मिल सकती है और एक छोटी सूचना पर प्राथमिकताएं बदल सकती हैं। नई विशेषताओं को पुनरावृत्ति से पुनरावृत्ति में जोड़ा जा सकता है।

हम ऐसा क्यों करते हैं? क्योंकि झरने के दृष्टिकोण का उपयोग करके विकसित की गई अधिकांश विशेषताएं कभी भी उपयोग नहीं की जाती हैं। ऐसा इसलिए है क्योंकि जलप्रपात मॉडल योजना का अनुसरण करता है जबकि वह चरण है जब हम कम से कम जानते हैं।

चंचल भी योजना बनाता है, लेकिन यह सिर्फ समय के दृष्टिकोण में भी अनुसरण करता है जहां योजना केवल जरूरत पड़ने पर पर्याप्त होती है। और योजनाएं हमेशा प्रगति के रूप में बदलने के लिए खुली हैं।

12 चुस्त सिद्धांत

12 चुस्त सिद्धांत हैं जो घोषणापत्र के निर्माण के बाद जोड़े गए थे ताकि टीमों को चंचलता में संक्रमण में मदद करने और मार्गदर्शन करने के लिए जांचा जा सके कि वे जो अभ्यास कर रहे हैं वे चुस्त संस्कृति के अनुरूप हैं या नहीं।

निम्नलिखित 12 सिद्धांतों का पाठ निम्नलिखित है, जिसे एजाइल एलायंस द्वारा 2001 में प्रकाशित किया गया था:

# 1) हमारी सर्वोच्च प्राथमिकता मूल्यवान सॉफ़्टवेयर के शुरुआती और निरंतर वितरण के माध्यम से ग्राहक को संतुष्ट करना है।

#दो) आपका स्वागत है बदलती आवश्यकताओं, यहां तक ​​कि विकास में देर हो गई। चंचल प्रक्रियाएं ग्राहक के प्रतिस्पर्धात्मक लाभ के लिए बदलाव लाती हैं।

# 3) कम समय के लिए वरीयता के साथ, कुछ हफ़्ते के लिए कुछ हफ़्ते के लिए, अक्सर काम करने वाले सॉफ़्टवेयर वितरित करें।

# 4) व्यावसायिक लोगों और डेवलपर्स को पूरे प्रोजेक्ट में प्रतिदिन एक साथ काम करना होगा।

# 5) प्रेरित व्यक्तियों के आसपास परियोजनाओं का निर्माण। उन्हें पर्यावरण दें और उनकी ज़रूरत का समर्थन करें, और काम पूरा करने के लिए उन पर भरोसा करें।

# 6) विकास टीम के भीतर और भीतर जानकारी पहुंचाने की सबसे कुशल और प्रभावी विधि आमने-सामने की बातचीत है।

पीसी प्रदर्शन का अनुकूलन करने के लिए सबसे अच्छा मुफ्त सॉफ्टवेयर

# 7) कार्य सॉफ्टवेयर प्रगति का प्राथमिक उपाय है।

# 8) चंचल प्रक्रियाएं सतत विकास को बढ़ावा देती हैं। प्रायोजकों, डेवलपर्स, और उपयोगकर्ताओं को अनिश्चित काल तक निरंतर गति बनाए रखने में सक्षम होना चाहिए।

# 9) तकनीकी उत्कृष्टता और अच्छे डिजाइन के लिए निरंतर ध्यान चपलता को बढ़ाता है।

# 10) सादगी - काम की मात्रा को अधिकतम करने की कला बहुत आवश्यक है।

#ग्यारह) सबसे अच्छी वास्तुकला, आवश्यकताएं, और डिजाइन स्वयं-व्यवस्थित टीमों से निकलती हैं।

# 12) नियमित अंतराल पर, टीम इस बात पर चिंतन करती है कि कैसे अधिक प्रभावी बनना है, फिर उसके अनुसार अपने व्यवहार को ट्यून और समायोजित करता है।

ये चुस्त सिद्धांत विकास टीमों के लिए व्यावहारिक मार्गदर्शन प्रदान करते हैं।

12 सिद्धांतों को व्यवस्थित करने का एक अन्य तरीका निम्नलिखित चार अलग-अलग समूहों में उन पर विचार करना है:

  • ग्राहक संतुष्टि
  • गुणवत्ता
  • टीम वर्क
  • परियोजना प्रबंधन

# 1) हमारी सबसे बड़ी प्राथमिकता मूल्यवान सॉफ़्टवेयर के शुरुआती और निरंतर वितरण के माध्यम से ग्राहक को संतुष्ट करना है - ग्राहकों को स्पष्ट रूप से एक काम कर रहे सॉफ्टवेयर को देखने के लिए रोमांचित होने जा रहा है, जिसके बजाय प्रत्येक प्रतीक्षा अवधि के दौरान एक अस्पष्ट प्रतीक्षा अवधि से गुजरने के बजाय केवल उत्पाद को देखने के लिए मिलेगा।

यहां ग्राहक को प्रोजेक्ट प्रायोजक या उस व्यक्ति के रूप में परिभाषित किया जा सकता है जो विकास के लिए भुगतान कर रहा है। उत्पाद का अंतिम उपयोगकर्ता भी एक ग्राहक है लेकिन हम दोनों के बीच अंतर कर सकते हैं क्योंकि अंत उपयोगकर्ता को उपयोगकर्ता के रूप में संदर्भित किया जाता है।

#दो) आपका स्वागत है बदलती आवश्यकताओं, यहां तक ​​कि विकास में देर हो गई। एजाइल प्रक्रियाएं ग्राहक के प्रतिस्पर्धात्मक लाभ के लिए बदलाव को बदल देती हैं - समग्र समयसीमा में बहुत अधिक देरी के बिना परिवर्तन को शामिल किया जा सकता है।

चूंकि चुस्त टीमें सभी चीजों से ऊपर की गुणवत्ता में विश्वास करती हैं, इसलिए वे परिवर्तनों को शामिल करेंगी और ग्राहकों की आवश्यकताओं के अनुसार बदलाव से बचेंगी और ऐसे उत्पाद वितरित करेंगी जो व्यवसाय की जरूरतों को पूरा नहीं करता है।

# 3) कम समय के लिए एक प्राथमिकता के साथ, कुछ हफ़्ते के लिए कुछ हफ़्ते के लिए, अक्सर काम करने वाले सॉफ़्टवेयर वितरित करें - स्प्रिंट में काम करने वाली टीमों द्वारा इस पर ध्यान दिया जाता है। चूंकि स्प्रिंट समय-समय पर पुनरावृत्तियां होती हैं और प्रत्येक स्प्रिंट के अंत में एक कार्यशील सॉफ़्टवेयर वितरित करती हैं, इसलिए ग्राहकों को नियमित रूप से प्रगति का एक विचार मिलता है

# 4) व्यवसाय के लोगों और डेवलपर्स को पूरे प्रोजेक्ट में प्रतिदिन एक साथ काम करना होगा - बेहतर निर्णय तब लिया जाता है जब दोनों सहयोगात्मक रूप से काम कर रहे होते हैं और पाठ्यक्रम में सुधार और चपलता के लिए दोनों के बीच निरंतर प्रतिक्रिया पाश होता है। हितधारकों के बीच संचार हमेशा चपलता में महत्वपूर्ण है।

# 5) प्रेरित व्यक्तियों के आसपास परियोजनाओं का निर्माण। उन्हें पर्यावरण दें और उनकी ज़रूरत का समर्थन करें, और काम पाने के लिए उन पर भरोसा करें - आपको टीमों का समर्थन, विश्वास और प्रेरणा करनी होगी। एक प्रेरित टीम सफल होने की अधिक संभावना है और दुखी टीमों की तुलना में एक बेहतर उत्पाद प्रदान करेगी जो अपना सर्वश्रेष्ठ देने को तैयार नहीं हैं।

ऐसा करने के तरीकों में से एक विकास टीम को आत्म-संगठित होने और अपने स्वयं के निर्णय लेने के लिए सशक्त बनाना है।

# 6) विकास टीम के भीतर और भीतर जानकारी पहुंचाने का सबसे कुशल और प्रभावी तरीका है, आमने-सामने की बातचीत - यदि टीम एक ही स्थान पर है और चर्चा के लिए आमने सामने मिल सकती है तो संचार बेहतर और अधिक प्रभावशाली है। यह विश्वास का निर्माण करने में मदद करता है और विभिन्न हितधारकों के बीच समझ लाता है।

# 7) कार्य सॉफ्टवेयर प्रगति का प्राथमिक उपाय है - एक कार्यशील सॉफ़्टवेयर अन्य सभी KPI को धड़कता है और किए गए कार्य का सबसे अच्छा संकेतक है।

# 8) चंचल प्रक्रियाएं सतत विकास को बढ़ावा देती हैं। प्रायोजकों, डेवलपर्स, और उपयोगकर्ताओं को अनिश्चित काल तक निरंतर गति बनाए रखने में सक्षम होना चाहिए - प्रसव की संगति पर बल दिया जाता है। टीम को परियोजना की अवधि के दौरान अपनी गति बनाए रखने में सक्षम होना चाहिए और पहले कुछ स्प्रिंट के बाद जला नहीं जाना चाहिए।

# 9) तकनीकी उत्कृष्टता और अच्छे डिजाइन के लिए निरंतर ध्यान चपलता को बढ़ाता है - बदलावों को शामिल करने के लिए टीम के पास सभी कौशल और एक अच्छा उत्पाद डिजाइन होना चाहिए और परिवर्तनों को शामिल करने में सक्षम होने के साथ-साथ उच्च गुणवत्ता वाले उत्पाद का उत्पादन करना चाहिए।

# 10) सादगी - काम नहीं किए जाने की मात्रा को अधिकतम करने की कला आवश्यक है और बस की गई परिभाषा को पूरा करने के लिए पर्याप्त है।

#ग्यारह) सबसे अच्छी वास्तुकला, आवश्यकताएं, और डिजाइन स्वयं-व्यवस्थित टीमों से निकलती हैं - स्व-संगठित दल सशक्त होते हैं और अपने काम का स्वामित्व लेते हैं। इससे टीम के सदस्यों के बीच खुले संचार और विचारों का नियमित आदान-प्रदान होता है।

# 12) नियमित अंतराल पर, टीम इस बात पर चिंतन करती है कि कैसे अधिक प्रभावी बनना है, फिर धुनों और उसके व्यवहार को तदनुसार समायोजित करता है - आत्म-सुधार जल्दी परिणाम और कम पुनरावृत्ति की ओर जाता है।

निष्कर्ष

ग्राहक केंद्रितता और संचार पर ध्यान केंद्रित करने से चुस्त सफलता मिली जो आज दिखाई दे रही है।

यह न केवल सॉफ्टवेयर डिलीवरी बल्कि अन्य उद्योगों में निहितार्थ के साथ एक सिद्ध तकनीक है और आज यह अपने आप में एक उद्योग बन गया है।

इस श्रृंखला में हमारा आगामी ट्यूटोरियल अपनी भूमिकाओं के साथ-साथ स्क्रम टीम के बारे में अधिक बताएगा !!

PREV ट्यूटोरियल | अगले ट्यूटोरियल

अनुशंसित पाठ

^