Agile और Jira की धीमी और पीड़ादायक मौत
(ehandbook.com)"जब Agile अब Agile नहीं रहा, तो अब समय आ गया है कि Agile, Jira को साथ लेकर गायब हो जाए"
- सॉफ़्टवेयर डेवलपमेंट चक्र लगातार लंबे होते जा रहे हैं, टेक टीमों का आकार लगातार बढ़ रहा है, डेवलपमेंट मैनेजमेंट के लिए लगातार अधिक ऐप्स की ज़रूरत पड़ रही है, वास्तव में कोड लिखने वाले लोग लगातार कम होते जा रहे हैं, और लगातार छोटे-छोटे अंतरालों में, निरंतर चेकपॉइंट्स के बीच प्रगति लगातार कम होती जा रही है
- Agile कहाँ से गलत होने लगा?
- Agile 2000 के दशक की शुरुआत में दस्तावेज़-केंद्रित, भारी-भरकम पारंपरिक सॉफ़्टवेयर डेवलपमेंट प्रोसेस के विकल्प के रूप में विकसित की गई एक कार्यप्रणाली थी
- लेकिन आज Agile खुद पारंपरिक जटिल प्रोजेक्ट मैनेजमेंट कार्यप्रणाली जैसा बनता जा रहा है
Tech Bloat मुख्य समस्या है
- बहुत से लोगों के Agile को छोड़ने या छोड़ने पर विचार करने की सबसे बड़ी वजह Tech Bloat है
- Tech Bloat हर टेक कंपनी का दुश्मन है, और उन गैर-तकनीकी कंपनियों के लिए भी ख़तरनाक है जिनके पास इन-हाउस या आउटसोर्स डेवलपमेंट टीमें हैं
- Tech Bloat, technical debt से अलग है, लेकिन यह technical debt पैदा करता है
- Tech Bloat के लक्षण इस प्रकार हैं:
- ग्राहक से बार-बार बातचीत करना, लेकिन ग्राहक के व्यवहार का विशेषज्ञ न बन पाना
- deadlines और delivery dates का लगातार मूल्यांकन और पुनर्मूल्यांकन करना
- जब तक हर छोटी-बड़ी बात दस्तावेज़ में न आ जाए, तब तक डेवलपमेंट प्रोसेस शुरू करने में अत्यधिक हिचकिचाहट
- सबसे जोखिमपूर्ण काम की बजाय सबसे आसान काम से शुरुआत करने की प्रेरणा
Tech Bloat के उलझनभरे परिणाम
- दस्तावेज़ीकरण में वृद्धि
- प्रोसेस में ऐसा दस्तावेज़ीकरण घुलमिल जाता है जो सिर्फ यह नहीं बताता कि क्या और क्यों बनाया गया, बल्कि यह भी ट्रैक करता है कि उसे "कैसे" बनाया गया
- यही "कैसे" status updates का केंद्र बन जाता है, और टीम लगातार यह दोबारा परखती रहती है कि वह काम कैसे कर रही है
- टीम असल काम करने से ज़्यादा समय इस पर चर्चा करने में बिताती है कि काम पूरा क्यों नहीं हुआ
- बार-बार deadlines तय करना
- अधिक बार होने वाले checkpoints पर अधिक deadlines तय की जाती हैं, जिससे मूलतः रचनात्मक प्रक्रिया के हर मोड़ पर micromanagement पैदा होता है
- यह अच्छी गुणवत्ता वाला सॉफ़्टवेयर बनाने के ख़िलाफ़ जाता है, क्योंकि हर काम इस बात से परे तय समय तक पहुँचा दिया जाता है कि उसे कितनी अच्छी तरह किया गया
- पुनर्मूल्यांकन की प्रक्रिया में लगातार संदेह
- पुनर्मूल्यांकन के दौरान लगातार संदेह बना रहने से best practices घोषित नहीं हो पातीं, बर्बादी दूर नहीं होती, और economies of scale पहचानी नहीं जातीं
- प्रोडक्शन प्रक्रिया का micromanagement
- जब तक किसी पूरे feature का लगभग 30% तैयार होता है, तब तक वह अक्सर प्राथमिकता ही नहीं रह जाता
- संगठन इस घातक चक्र में फँस जाते हैं कि रोडमैप में जो है वही बनाते रहें, चाहे रोडमैप अब भी सफल प्रोडक्ट बनाने की सही परिभाषा देता हो या नहीं
- अंतिम परिणाम
- प्रोडक्ट तरह-तरह की और परस्पर टकराती ग्राहक ज़रूरतों के बोझ तले दब जाता है
- features अक्सर बाज़ार में देर से आते हैं, और उन्हें उस तरीके व क्रम में जारी किया जाता है जो बाज़ार के लिए सबसे उपयुक्त नहीं बल्कि टेक टीम के लिए सबसे सुविधाजनक होता है
- अंततः sales/marketing टीमें विरोध करने लगती हैं, क्योंकि उन्हें समझ नहीं आता कि वे क्या बेच रही हैं और ग्राहक क्या खरीद रहे हैं
- इसके बाद संगठन बड़े पैमाने पर सफ़ाई अभियान में लग जाता है
दुनिया को अधिक features नहीं, बल्कि ऐसे हल्के सॉफ़्टवेयर की ज़रूरत है जो महत्वपूर्ण काम बेहतर ढंग से करे
- यह कोई नया विचार नहीं है, लेकिन हर कार्यप्रणाली अंततः इसी विचार से दूर चली जाती है
- लोग आख़िरकार यह पूछने लगते हैं कि Toyota Way, Toyota के लिए काफ़ी Toyota-जैसी है भी या नहीं, और यह खुद और काम पैदा करने वाला काम बन जाता है
- Agile अब प्यारे नाम, छोटी बैठकों और अधिक नियमों वाला PMP बन चुका है
- समस्या Agile के विचार में नहीं, बल्कि उसके अमल और उसे नियंत्रण में रखने वाले नेतृत्व की कमी में है
- यह उन middle managers की समस्या है जो उपयोगिता से ज़्यादा deadlines पर, growth से ज़्यादा कटौती पर, और progress से ज़्यादा बचत पर ध्यान देते हैं
GN⁺ की राय
- Agile, अपने मूल इरादे के उलट, अब नौकरशाही और औपचारिकता का शिकार होकर सॉफ़्टवेयर डेवलपमेंट को धीमा करने वाला कारक बन गया है
- Tech Bloat सिर्फ Agile ही नहीं, हर तकनीकी संगठन के लिए एक ऐसा जोखिम है जिस पर नज़र रखनी चाहिए
- दस्तावेज़ीकरण, deadline तय करना, micromanagement आदि उल्टा गुणवत्ता और गति दोनों को गिरा सकते हैं
- Agile का सार ग्राहक-केंद्रितता, सहयोग और लचीलापन है, इसलिए रूप-रंग में उलझने के बजाय उसके सिद्धांतों को फिर से याद करने की ज़रूरत है
- सॉफ़्टवेयर डेवलपमेंट में महत्वपूर्ण बात अधिक features नहीं, बल्कि मुख्य capabilities को अच्छी तरह लागू करना है
- संगठनात्मक संस्कृति और नेतृत्व Agile की सफलता या विफलता तय करते हैं, इसलिए तकनीकी प्रबंधकों को इस पर ध्यान देना चाहिए
- लगता है कि अब Agile से आगे बढ़कर नई कार्यप्रणाली खोजने का समय आ गया है
17 टिप्पणियां
मैं मूल लेख paywalled होने की वजह से अंत तक नहीं देख पाया, लेकिन लगता है कि अनुवादित अभिव्यक्ति को थोड़ा और सँवारा जा सकता है.
"Agile अब agile नहीं रहा, इसलिए अब समय आ गया है कि Agile, Jira को साथ लेकर गायब हो जाए"
=> "Agile ने being agile होना बंद कर दिया है, इसलिए अब समय आ गया है कि Agile, Jira को साथ लेकर गायब हो जाए"
यहाँ बड़े अक्षर वाले Agile और छोटे अक्षर वाले agile को अलग करके इस्तेमाल करने की एक अवधारणा है,
और being agile तथा doing agile आपस में जुड़े हुए होते हुए भी अलग-अलग समझे जाते हैं.
being agile by doing agile.
Agile को अपनाने की वजह मायने रखती है। क्या इसे development बेहतर करने के लिए अपनाया जाता है? नहीं, बात यह होती है: मैं तुम लोगों को यूँ आराम करते नहीं देख सकता। ज़रा देखूँ तो सही, तुम कितनी मेहनत कर रहे हो। इसी mindset के साथ इसे लागू किया जाता है। फिर यह नरक ही बन जाता है।
अब तो लगता है कि Agile अनुपालन के लिए एक चेकलिस्ट की ज़रूरत पड़ेगी।
Agile हो या waterfall, उससे पहले असली समस्या लोगों, संस्कृति और पूरे माहौल की है; अगर वह ज्यों का त्यों रहे, तो आप कितनी भी नई-नवेली development methodology ले आएँ, उसका अंजाम बस K-OOO जैसा बनना ही है।
अगर requirements में (लगभग) कोई बदलाव नहीं होता, तो development करने वाले के नज़रिए से waterfall सच में एक आरामदायक तरीका है। बशर्ते requirements में बदलाव बिल्कुल न हो…
K Agile का तो कोई पुनर्मूल्यांकन ही नहीं है.!
ग्राहक : इस स्क्रीन पर बटन यहाँ हो तो अच्छा रहेगा
डेवलपर : (आज रात जागना पड़ेगा, नए काम भी पड़े हैं)
ग्राहक : दूसरी स्क्रीन पर भी बटन होना चाहिए
डेवलपर : (कोई मुझे cloning की शक्ति दे दो) जी हाहा..
ग्राहक : अभी तक नहीं हुआ? शेड्यूल के हिसाब से तो सब खत्म हो जाना चाहिए था, है ना?
डेवलपर : (बचा लो) जी..;;
Agile को सच में Agile तरीके से लंबे समय तक इस्तेमाल किए जाने के उदाहरण बहुत कम हैं,
और लगता है कि ज़्यादातर संगठन आखिरकार कम डेडलाइन वाले waterfall कामकाज की ओर सिमट जाते हैं।
Agile समस्या नहीं है। समस्या उसे करने वाले लोग हैं। आप कोई भी methodology ले आइए, आखिर में बात इस पर आती है कि उसे लागू करने वाला व्यक्ति उसे कैसे करता है। मेरे हिसाब से Agile methodology से ज़्यादा एक ऐसी mindset के करीब है जिसमें हर चक्र के साथ product को आगे बढ़ाया जाता है। अगर इस बात को छोड़कर बस आँख मूंदकर planning और retrospective करते रहें, तो वह समय की बर्बादी लगती है।
मुझे लगा था कि ऐसा सिर्फ़ K-Agile में है, लेकिन यह तो एक global phenomenon निकला।
लगता है ये बार-बार बिल्कुल गलत चीज़ पर प्रहार कर रहे हैं... फैसला इस आधार पर होना चाहिए कि यह Agile manifesto के अनुरूप है या नहीं...
Agile घोषणा में शामिल uncle bob ने भी इस समस्या को जल्दी समझ लिया था और गलत Agile को ठीक करने के लिए 2019 में Clean Agile किताब प्रकाशित की थी, लेकिन यह समस्या अभी भी जारी है। व्यक्तिगत रूप से मुझे लगता है कि इसकी वजह यह है कि Agile के लिए कोई standard guideline नहीं है और इसमें "culture" जैसी अस्पष्ट अभिव्यक्ति का उपयोग किया जाता है। काश कोई ठोस standard guideline पेश की गई होती।
लेखक शायद यह कहेंगे कि कोई भी methodology जैसे ही bureaucratic बन जाए, उसे छोड़ देना चाहिए।
सहमत हूँ। ऐसा लगता है कि गलत तरीके से Agile अपनाकर फिर यह कहा जा रहा है कि Agile ही गलत है, ऐसी बातें बढ़ती जा रही हैं।
दूसरी ओर, यह भी लगता है कि इसे आए काफी समय हो चुका है, फिर भी practices को अच्छी तरह बनाना मुश्किल है, और शायद इससे बचा नहीं जा सकता।
घूम-फिरकर क्या हम फिर वहीं लौट रहे हैं?
Hacker News राय
Agile की समस्याएं
Agile Manifesto के सिद्धांत
Agile का मूल
Agile की लचीलापन
JIRA पर राय
Agile की उत्पत्ति
Agile की वर्तमान स्थिति
JIRA की समस्याएं
Agile का अनुप्रयोग