एगाइल एक्सपर्ट्स बनाम एजाइल मेनिफेस्टो

क्या आपको लगता है कि आपके "स्थानीय चुस्त विशेषज्ञ" ने एजाइल मेनिफेस्टो पढ़ा है? क्या तुम? खैर, यह एक समस्या नहीं है ... यदि आप दैनिक आधार पर "एजाइल" शब्द का उपयोग नहीं करते हैं! लेकिन अगर आप ऐसा करते हैं (या आपका स्थानीय विशेषज्ञ करता है) ... अच्छी तरह से - यह कुछ ऐसे लोगों की तरह है जो धर्म के बारे में बहुत बात करते हैं, लेकिन उन्होंने अपने साहित्य वर्गों के बाद से बाइबल (राजनीतिक शुद्धता चेतावनी) या अपनी पसंद की पवित्र पुस्तक नहीं खोली है। 10 साल पहले ... हम उन्हें पसंद नहीं करते। किसी कारण से।

ठीक है, आइए हम अन्य लोगों और उनकी राय पर टिप्पणी न करें। इसके बजाय, "कदम से कदम" चंचल बाइबल के माध्यम से जाना।

एजाइल मेनिफेस्टो के उद्धरण अंदर दिए जाएंगे

इस तरह का टेक्स्ट ब्लॉक

और हमारी टिप्पणी इस तरह नियमित रूप से इंडेंट में दी जाएगी। चलो चलते हैं!

मैनिफेस्टो, एक और केवल!

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

यह विचार कितना बेहतरीन है! यह वास्तव में उस समय क्रांतिकारी था जब इसे बनाया गया था! लेकिन इस विचार का क्रियान्वयन इन कुछ पंक्तियों की तुलना में कठिन है।

मुख्य समस्या: हर कोई, जिसका ग्राहक के साथ सीधा संपर्क है, जानता है कि यह मैनिफेस्टो का बिंदु कम से कम कुछ मुश्किल है।

अफसोस की बात है, ग्राहक हमेशा यह सुनिश्चित नहीं करता है कि वह क्या चाहता है, या वह उसी समय बहुत सी चीजें चाहता है, और उन्हें ठीक से प्राथमिकता नहीं दे सकता है! इसके अलावा, यह हो सकता है कि उन चीजों में से कुछ जो ग्राहक ने सोचा था, वह चाहता था, बाद में नहीं चाहता था ...

अगर हम इसे एक तरफ रख देते हैं - तो उत्पाद की सफलता के लिए मैनिफेस्टो की बात साबित होती है! लेकिन इन अपवादों की उपेक्षा नहीं की जानी चाहिए, क्योंकि वे घातक हो सकते हैं!

अगला बिंदु कुछ समान है, इस विषय को वहीं जारी रखें।

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

यह भी खूब रही। लेकिन विकास टीम पर लगातार धुरी और दबाव उत्पाद को कमजोर बनाता है। बहुत सारे प्रोजेक्ट पुनर्निर्देशन के साथ तेजी से कोडिंग, उत्पाद की कोड गुणवत्ता को कम करता है, इसलिए परिवर्तन कठिन हो जाते हैं। अधिक तर्कसंगत और शांत विकास उत्पाद विकास के बाद के चरणों में परिवर्तन करने की दक्षता में सुधार करता है। हम इस बात से सहमत हैं कि बदलावों का स्वागत किया जाना चाहिए, लेकिन अन्य अनुबंध / समझौते खंडों को भी आनुपातिक रूप से बदलना चाहिए! कई मामलों में, उत्पाद को उसी समय में तैनात किए जाने की उम्मीद की जाती है क्योंकि यह अतिरिक्त परिवर्तन की आवश्यकता के मामले में नहीं होता। अछा नहीं लगता।

चपलता अपेक्षित परिवर्तनों के लिए तैयार होने के बारे में है, न कि सब कुछ और हमेशा बदलने के बारे में। संभावित ग्राहक / ग्राहक के साथ संवाद करने के लिए मान्यता प्राप्त लोगों को शुरू से ही यथार्थवादी समझौते पर बातचीत करनी चाहिए। अक्सर, सही समय (परियोजना की शुरुआत) में कलम और कागज के साथ 10 मिनट बाद के चरणों में दिनों, हफ्तों और यहां तक ​​कि विकास के महीनों (पुनर्निर्देशन, धुरी, बदलते) को बचाता है! उत्पादों की शुरुआत में इस तरह के उतार-चढ़ाव को गैर-लाभकारी माना जाना चाहिए, क्योंकि यह बहुत अधिक है! "चलो बस ग्राहक प्राप्त करते हैं, बाद में हम नौकरी खत्म करने के लिए कुछ सोचेंगे" मानसिकता अनैतिक है, और अक्सर डेवलपर्स के लिए "दिन को बचाने" (कार्य समयोपरि, कार्य सप्ताहांत, घर से काम करना, काम करना) आता है तनावपूर्ण आसपास) ... शांत नहीं। और सचमुच - फुर्तीली भी नहीं।

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

मुझे केवल इस एक के साथ अच्छे अनुभव हैं। यह शुरुआती कर्षण-परीक्षण-शिक्षण-सुधार-प्रतिक्रिया के लिए संभावनाएं देता है। अगर सामान अवधारणा आवश्यक उत्पाद के सॉफ्टवेयर विकास में लागू होती है तो बढ़िया सामान। (हमेशा मामला नहीं है, यह विश्वास है या नहीं।)

व्यवसाय से जुड़े लोगों और डेवलपर्स को काम करना चाहिए
परियोजना के दौरान रोजाना एक साथ।

ठीक है, शायद दैनिक नहीं, लेकिन यह भी - अंगूठे! हम (लोग) पिछले 15 वर्षों में इसे बर्बाद करने में कामयाब नहीं हुए हैं ... हमें समय दें।

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

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

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

खैर, हम इस एक के खिलाफ कुछ भी नहीं कह सकते। इसके विपरीत, इसके लिए हुर्रे!

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

हाँ। समस्या यह है कि कई तथाकथित आंदोलनकारी भी इस खंड का सम्मान नहीं करते हैं।

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

कठिन, लेकिन निश्चित रूप से - महान दिशानिर्देश।

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

फिर, दुख की बात है, तथाकथित फुर्तीली परियोजना प्रबंधक अक्सर इस बारे में भूल जाते हैं, इस प्रकार गंभीर बनाते हैं, यदि घातक परिणाम नहीं।

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

जय हो, सरलता!

सबसे अच्छा आर्किटेक्चर, आवश्यकताओं, और डिजाइन
स्व-आयोजन टीमों से उभरना।

एवेन्यू!

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

तथास्तु!