XP और Agile के 20.5 साल (2020)
Agile और Extreme Programming (XP) पर यहाँ 20+ वर्षों के अभ्यास के बाद फिर से विचार किया गया है, जहाँ डेवलपर्स वास्तविक लाभ—इटरेटिव विकास, स्वचालित परीक्षण, रिफैक्टरिंग, और करीबी सहयोग—की तुलना अनिवार्य पेयर प्रोग्रामिंग की थकान और कठोर प्रक्रिया-धर्मिता से करते हैं। कई लोगों का तर्क है कि short feedback loops और CI/CD जैसे मूल विचार मुख्यधारा में आकर मूल्यवान हो गए हैं, लेकिन “capital-A Agile” को नौकरशाही, प्रमाणन उद्योगों, और प्रबंधन रिचुअल्स ने हड़प लिया है, जो परिणामों को बेहतर किए बिना केवल ओवरहेड बढ़ाते हैं। केंद्रीय प्रश्न यह है कि क्या agile विधियाँ आज भी टीमों को बेहतर सॉफ़्टवेयर देने में मदद करती हैं, या फिर लचीली, संदर्भ-विशिष्ट प्रथाओं ने चुपचाप उनके ब्रांडेड फ्रेमवर्क्स की जगह ले ली है।
पेयर प्रोग्रामिंग और XP प्रथाएँ
- कई लोगों ने पूर्णकालिक पेयरिंग को थकाऊ, दखल देने वाला, या अपनी काम करने की शैली के अनुकूल नहीं पाया; कुछ ने कहा कि वे इसे लगातार करने के बजाय नौकरी छोड़ देंगे।
- दूसरों ने तीव्र पेयरिंग के दौरान, खासकर “शिक्षक/छात्र” मोड में या जब तालमेल अच्छा था, चरम उत्पादकता और सीखने की रिपोर्ट की।
- कई लोगों ने नोट किया कि पेयरिंग सबसे अच्छा अच्छी संस्कृति और स्वैच्छिक उपयोग के साथ काम करती है; जबरन XP को घमंडी या कट्टरपंथी माना जाता है।
- XP की प्रशंसा इसलिए की जाती है कि यह प्रोग्रामरों को क्या करना चाहिए, इस बारे में ठोस मार्गदर्शन देता है (टेस्ट, रिफैक्टरिंग, इंक्रीमेंटल डिज़ाइन), न कि केवल कोडिंग के आसपास की प्रक्रिया पर।
Agile, Scrum, और दुरुपयोग
- आम शिकायत: Scrum और Agile को अक्सर कट्टरपंथी ढंग से लागू किया जाता है, और आलोचना को टालने के लिए “आप इसे गलत कर रहे हैं” कहा जाता है।
- कई लोग बताते हैं कि “रिचुअल्स” (स्टैंडअप, रिव्यू, स्प्रिंट) को यांत्रिक रूप से, बिना स्पष्ट लक्ष्यों, सहयोग, या अनुकूलन के, निभाया जाता है।
- स्प्रिंट्स को निश्चित समय-सीमाओं के रूप में गलत समझने से सैंडबैगिंग, कम आँके गए अनुमान, और धीमापन की धारणा बनती है।
- कुछ का तर्क है कि agile स्वयं सही है, लेकिन इसे नौकरशाही और कंसल्टिंग ने हड़प लिया है; अन्य कहते हैं कि यह हमेशा सेवाएँ बेचने और डेवलपर्स को नियंत्रित करने के बारे में था।
- कुछ लोगों के अनुसार Kanban इंटरप्ट-चालित काम के साथ अधिक बेहतर मेल खाता है।
टेस्टिंग, TDD, और कवरेज
- यूनिट टेस्ट, रिफैक्टरिंग, और टेस्ट-सचेत डिज़ाइन को व्यापक रूप से दीर्घकालिक बड़ी जीत माना जाता है।
- अन्य लोगों का तर्क है कि यूनिट टेस्ट बनाए रखने में महँगे होते हैं, अक्सर दोहराव वाले होते हैं, और एंड-टू-एंड टेस्ट की तुलना में कम मूल्यवान हैं।
- “100% कवरेज” पर बहस: कुछ इसे हानिकारक अतिवाद मानते हैं; अन्य बताते हैं कि XP के पाठ स्पष्ट रूप से कहते हैं कि हर मेथड के लिए टेस्ट जरूरी नहीं है, बल्कि भरोसे पर ध्यान दिया जाता है।
- चिंता यह है कि टेस्टेबिलिटी के लिए डिज़ाइन करने से बैकडोर, प्रदर्शन संबंधी समस्याएँ, या टेस्टिंग कोड का प्रोडक्शन में रिसाव हो सकता है।
प्रथाओं और टूलिंग का विकास
- कई प्रथाएँ जिन्हें कभी “कट्टर” माना जाता था (CI, स्वचालित बिल्ड/टेस्ट, रिफैक्टरिंग, इंक्रीमेंटल डिज़ाइन, सोर्स कंट्रोल) अब मुख्यधारा हैं, जिसका श्रेय आंशिक रूप से व्यापक agile/XP लहर को दिया जाता है।
- अन्य लोग जवाब देते हैं कि ये पहले भी “waterfall” या pre-agile वातावरण में मौजूद थीं; agile ने इन्हें आविष्कार नहीं किया, लेकिन इन्हें फैलाने में मदद कर सकता है।
Agile उद्योग और संगठनात्मक गतिशीलता
- “agile थिएटर” की कड़ी आलोचना: भूमिकाओं (कोच, scrum masters, product owners) का प्रसार, जबकि वास्तविक बाधाएँ हटाई नहीं जातीं।
- डेवलपर्स स्वयं को समारोहों, clerical work, और अपने नियंत्रण से बाहर देरी के लिए जवाबदेही में अतिभारित महसूस करते हैं।
- कुछ लोग agile की विफलता को राजनीतिक मानते हैं: नौकरशाही ने सिद्धांतों को कमजोर करते हुए भाषा अपना ली, जिसके परिणामस्वरूप “WaterScrumFall” और कठोर, गैर-agile कार्यान्वयन हुए।