Agile को अलविदा कहते हुए
(lewiscampbell.tech)- सॉफ्टवेयर उद्योग पर लंबे समय तक हावी रही Agile methodology की एक आलोचनात्मक पुनर्समीक्षा, जिसमें कहा गया है कि यह व्यवहार में अस्पष्ट सिद्धांतों और पहले से हल हो चुकी समस्याओं की दोबारा पैकेजिंग भर थी
- Waterfall के साथ इसका टकराव काफी हद तक एक भ्रम था, और iterative development और customer participation जैसे इसके मुख्य विचार 1970 के दशक के शोधों में पहले ही प्रस्तुत किए जा चुके थे
- Agile को हमेशा Waterfall model के उलट के रूप में ही परिभाषित किया गया, जबकि Waterfall model की सीमाएँ 1970 के दशक में ही व्यापक रूप से ज्ञात थीं
- हाल में large language models (LLM) के उभार के साथ, spec-driven development फिर से महत्वपूर्ण बन रहा है और documentation-केंद्रित development दोबारा उभर रहा है
- “comprehensive documentation से अधिक working software” वाला Agile का नारा अब “comprehensive documentation working software बनाती है” जैसी समझ में बदल रहा है
- Agile की छोड़ी हुई अस्पष्टता से आगे बढ़कर, स्पष्ट सिद्धांतों और engineering दृष्टिकोण की ओर लौटने का समय आ गया है
RIP Agile, we hardly knew ye.
And I mean that literally - because no one was ever clear on what it was.
Agile, शांति से विश्राम करो। हम तुम्हें ठीक से जान भी नहीं पाए।
और मेरा मतलब सचमुच यही है — क्योंकि कोई भी कभी साफ़ तौर पर नहीं जानता था कि यह आखिर था क्या।
Agile की पहचान की समस्या
- Agile सॉफ्टवेयर उद्योग में छा जाने वाली एक बड़ी धारा थी, लेकिन वास्तव में यह अपने अर्थ की अस्पष्टता के साथ ही फैलती गई
- जब भी इस पर सवाल उठे, जवाब बार-बार यही रहा: “वह असली Agile नहीं है”
- Agile Manifesto (2001) को सचमुच पढ़ें तो उसमें ठोस दिशानिर्देश लगभग नहीं हैं, और वह “customer collaboration contract negotiation से ज़्यादा महत्वपूर्ण है” जैसे अस्पष्ट सूत्रवाक्यों के स्तर पर है
- “development के आख़िरी चरण में भी requirement changes का स्वागत करो” जैसे सिद्धांत व्यावसायिक रूप से अवास्तविक हैं
- “True Agile” के दावे के तहत, व्यवहार में आने वाली समस्याओं को manifesto से असंबंधित बताकर टाला जाता रहा है
- अगर Agile industry खुद Agile को ठीक से लागू नहीं करती, और manifesto भी अपने आप में अर्थपूर्ण नहीं है, तो सवाल उठता है कि आखिर Agile की वास्तविकता क्या है
"सॉफ्टवेयर में Waterfall का भूत मंडरा रहा है"
- Agile ने हमेशा खुद को केवल उस चीज़ के रूप में परिभाषित किया जो वह नहीं है, यानी Waterfall; मानो यदि आप Agile नहीं कर रहे, तो आप Waterfall कर रहे हैं, और Waterfall काम नहीं करता
- लेकिन Waterfall काम नहीं करता, यह बात 1970 से ही जानी जाती थी, और Winston W. Royce ने उसके कारणों को स्पष्ट रूप से समझाया था
- Royce ने विकल्प के रूप में program design से शुरुआत करने, software prototype बनाकर requirements को refine करने, और customer को औपचारिक, गहन और निरंतर रूप से शामिल करने की सिफारिश की थी
- बाद में यही सब Agile की innovation बताई गई, जबकि यह सब वास्तव में चाँद पर उतरने के अगले ही साल (1970) में लिखा जा चुका था
- फुटनोट1: Apollo Guidance Computer के programmers ने बिना story points के, और “technical excellence पर निरंतर ध्यान agility को बढ़ाता है” जैसे सिद्धांत जाने बिना, ऐसा महान काम आखिर कैसे कर लिया?
1976 के Bell-Thayer paper और iterative development का इतिहास
- 1976 में Bell और Thayer का paper वह दस्तावेज़ था जिसमें "Waterfall" शब्द का पहली बार उपयोग हुआ, और यह शब्द स्वयं इस रूप में इस्तेमाल हुआ कि क्या नहीं करना चाहिए
- उस paper के empirical study का निष्कर्ष था: requirements की खामियाँ सॉफ्टवेयर development process में तभी सामने आती हैं जब हम design के ज़रिए requirements को पूरा करने की कोशिश करते हैं
- iterative development कोई नई चीज़ नहीं थी, बल्कि Agile से पहले के दशकों में इसे लगातार refine किया गया था
- manifesto के उद्योग को मुक्त करने से पहले भी Waterfall कोई cutting-edge तकनीक नहीं था, और requirements तथा specifications की उपयोगिता पर गंभीरता से शक करने वाले लोग लगभग नहीं थे
spec-driven development का उभार और Agile के बाद
- large language models (LLM) के प्रसार के साथ, programmers फिर से specification लिखने की ओर लौट रहे हैं
- LLM अस्पष्ट input के प्रति संवेदनशील होते हैं, इसलिए समस्या को स्पष्ट रूप से लिखना सही code generation में मदद करने के तरीके के रूप में उभर रहा है
- अगर Agile ने “comprehensive documentation से अधिक working software” पर ज़ोर दिया था, तो spec-driven development इसका उलटा कथन रखता है: "comprehensive documentation working software बनाती है"
- Royce ने 1970 में ही कहा था कि “documentation, specification, और design code लिखे जाने से पहले तक एक ही अवधारणा हैं; अगर documentation खराब है, तो design भी खराब है”
- उन्होंने इस बात पर ज़ोर दिया कि अगर documentation मौजूद नहीं है, तो design भी मौजूद नहीं है
- 1970 और 1976 के शोधों को फिर से देखने पर साफ़ होता है कि 2001 का Agile Manifesto कोई नई अंतर्दृष्टि नहीं दे पाया
- Agile ने अस्पष्ट परिभाषाओं और व्यावसायिक पैकेजिंग के ज़रिए मौजूदा engineering approach को बस प्रतिस्थापित किया, पर वास्तविक प्रगति नहीं की
- उन engineers के papers कहीं अधिक स्पष्ट अर्थ रखते थे
- जब सॉफ्टवेयर development लगातार बदल रहा है और विकसित हो रहा है, तो Agile को इतिहास के हवाले कर नए दृष्टिकोण की ओर मुड़ने का समय आ गया है
- हमें अतीत के गंभीर engineers द्वारा छोड़े गए स्पष्ट सिद्धांतों और engineering सोच की ओर लौटना चाहिए
21 टिप्पणियां
मुझे समझ नहीं आता कि लोग methodology को धर्मग्रंथ की तरह क्यों मानते हैं। मेरा मानना है कि मूल लेखक भी बस दिशा में अलग थे, लेकिन doctrinaire होने के मामले में वे भी कुछ अलग नहीं थे।
निष्कर्ष थोड़ा ज़्यादा अतिरंजित लगता है। commercialization या formalization समस्या हो सकती है, लेकिन sprint या backlog जैसे tools बेकार हो गए हों, ऐसा नहीं है। इन्होंने horizontal और goal-oriented meeting culture को जमने में मदद भी की है। यह सही है कि SDD ज़्यादा महत्वपूर्ण हो गया है, लेकिन उस spec को भी AI के साथ collaborative तरीके से तेज़ी से लिखा जा सकता है, इसलिए यह अब भी agile ही है। बस 2 हफ़्ते के sprint कुछ घंटों तक सिमट गए हैं; बार-बार iterate करके निखारने का मूल स्वभाव वही का वही लगता है।
मैं सहमत हूँ
ऊर्ध्वाधर निर्णय-प्रक्रिया को तोड़ना और छोटे cycles में बार-बार सुधार करना—सिर्फ इन्हीं बातों से भी हमें एक बड़ा संदेश मिलता है (और निश्चित ही project managing techniques/tools के लिए भी यही बात लागू होती है)।
यह निष्कर्ष कि 'Agile खुद कोई नई अंतर्दृष्टि देने में विफल रहा, और Agile का समर्थन करने वाले पूरे समूह को अंधभक्त Agile समर्थक बताकर खारिज कर दिया जाए' कुछ ज़्यादा ही उग्र लगता है।
सहमत हूँ। Agile अब भी प्रासंगिक है। यह उन लोगों की हवा-हवाई बात लगती है जो असली कामकाजी माहौल में रहे ही नहीं हैं।
यह बहुत ही बेवकूफ़ाना लेख है। मुख्य बात यह है कि spec. को ही agile तरीके से लिखा जाना चाहिए... agile का मतलब है ग्राहक की आवश्यकताओं में तेज़ बदलाव के अनुसार खुद को ढालना।
Agile को लेकर ऐसी गलतफ़हमियाँ और अधपकी कल्पनाएँ रखने वाले लोगों की वजह से ही agile हो या development culture, सब कुछ गलत दिशा में जा रहा है।
आख़िर
specको agile तरीके से लिखने का मतलब क्या है?specको मोटे तौर पर लिखना।specको ग्राहक जैसा बोलता जाए वैसा लिखना।specको जल्दी बदल सकें, इसके लिए tools की मदद से उसका maintenance करना।specको agile तरीके से लिखना।असल में उस लेख की बात ही यही है कि agile आखिर है क्या, यह समझ नहीं आता। Agile में ये-ये विशेषताएँ होती हैं, और ऐसे-वैसे करना चाहिए—यह बातें तो बहुत कही जाती हैं, लेकिन यह दिखाने वाला लेख कि "यह ऐसा product है जो सच में agile methodology से बना है" मैंने अब तक नहीं देखा। Manifesto को देखकर भी बात कुछ धुंधली ही लगी। एक बार दिखाकर समझाएँ तो कैसा रहेगा?
Kent Beck की Extreme Programming, Jeff Sutherland की Scrum वगैरह ज़्यादातर Agile तकनीकों की किताबों में यह बुनियादी तौर पर आता है। आप user story भी देख सकते हैं। ज़्यादातर लोग यह अच्छी तरह नहीं जानते कि Agile की बुनियाद ग्राहक की requirements के लिए तेज़ी से अनुकूलन करने वाले छोटे sprint और demo हैं।
3, 4 नंबर ही हैं। स्पेक को बहुत डिटेल में लिखने की गहराई अनंत हो सकती है। बात यह है कि हर संगठन के हिसाब से उसका एक उपयुक्त स्तर होता है। मेरी समझ में, सफल सेवाएँ किस तरह बनाई गईं इसका इतिहास देखें तो 99% मामलों में अहम बात यह रही है कि स्पेक को बिल्कुल सटीक लिखने पर ज़रूरत से ज़्यादा ऊर्जा नहीं लगाई जाती। यानी उसमें फँस नहीं जाना चाहिए। Summoners War, Dungeon & Fighter, Zigbang, Lineage जैसी चीज़ें कैसे बनाई गईं, यह देखें तो समझ आ जाता है।
अगर Waterfall cycle एक ही दिन में चल जाए तो?
आजकल ऐसे मामले ज़्यादा बार देखने को मिलते हैं।
डरावनी बात है कि शायद यही चीज़ मैं सबसे ज़्यादा बार देखता हूँ...
यहाँ Agile, डेवलपर्स पर डेडलाइन का दबाव डालने के एक साधन से ज़्यादा कुछ भी नहीं है।
कुछ मानकों के हिसाब से तो सब लोग agile हैं। सोचता हूँ, क्या कभी ऐसा दौर रहा है जैसा अभी है, जब इतनी तेज़ी से deploy किया जाता है और feedback मिलता है।
छोटे चक्र वाले deployment के अलावा Agile में आखिर बचता क्या है, यह समझ नहीं आता।
बैकलॉग और sprint भी पहले से ही किसी और रूप में मौजूद थे, और ग्राहकों के साथ communication में भी कई बातें वास्तविकता से मेल नहीं खातीं। आखिरकार, मुझे लगता है कि Agile की तुलना में DevOps सुधारों ने development में कहीं ज़्यादा प्रगति लाई।
यह लेख खुद ही agile नहीं है!
कोड पढ़ने की ज़रूरत पूरी तरह ख़त्म नहीं होती, इसलिए इस नज़रिए से यह कहना कि दस्तावेज़ों से ज़्यादा कोड महत्वपूर्ण है, सही लगता है। और चूँकि निर्देश के रूप में दस्तावेज़ों को उन्हें लागू करने वाला LLM पढ़ता है, इस दृष्टिकोण से भी मैं सहमत हूँ। इसलिए निष्कर्ष यही लगता है कि दोनों एक साथ महत्वपूर्ण हैं।
अभी LLM-आधारित प्रोडक्ट्स की समस्या वह debt है जो operations चरण में जमा होती जाती है। लगातार operations के लिए डेवलपर का कोड में शामिल रहना ज़रूरी है, और उसके लिए अभी तक मेरा मानना है कि कोड को दस्तावेज़ों की जगह लेने में सक्षम होना चाहिए।
अगर मैं सावधानी से एक आपत्ति रखूँ, तो मेरा मानना है कि code documentation की जगह नहीं ले सकता। Programming language में अभी भी natural language जैसी समृद्ध अभिव्यक्ति और संप्रेषण क्षमता नहीं है, और व्यावहारिक रूप से देखें तो इतना सारा code आखिर कब पढ़ा जाएगा?
Documentation की जगह ले सकने वाले code का होना एक उम्मीद और आकांक्षा है, लेकिन वह बाबेल के मीनार की तरह है जिस तक पहुँचा नहीं जा सकता।
उससे बेहतर तो यह लगता है कि OOAD को ही मन लगाकर किया जाए.
इसके उलट, मुझे यह भी लगता है कि natural language का code की जगह लेना मुश्किल है। natural language, code की तुलना में जितनी तेज़ है, उतनी ही ज़्यादा abstract भी है। computing के लिए आखिरकार details भरनी ही पड़ती हैं, और यह भूमिका natural language के निभाने में मुझे कठिनाई दिखती है।
SW लिखने में समस्या अमूर्तन से ज़्यादा अस्पष्टता की होती है। प्राकृतिक भाषा स्वभाव से ही अस्पष्ट होती है। वह बहुअर्थी भी होती है। इसलिए शायद प्राकृतिक भाषा से coding करने की कोशिशें अच्छी तरह काम नहीं कर पातीं।
जब स्थिति ऐसी है, तो यह सोचना भी मुश्किल है कि प्राकृतिक भाषा code की जगह ले लेगी।
आपकी कही बात से सहमति महसूस होती है.
कुछ हिस्से ऐसे होते हैं जिन्हें स्पष्ट रूप से code से replace नहीं किया जा सकता.
इसी अर्थ में अगर थोड़ा अलग तरह से समझाऊँ, तो मैं यह कहना चाहता था कि उच्च पठनीयता वाला code ऐसा बनाता है कि documents बनाने की ज़रूरत कम पड़े.
समय के साथ software के लंबे समय तक चलते रहने पर जमा होने वाले documents भी developers पर cognitive load डालते हैं. मूल बात यह है कि code और documents को बारी-बारी से देखने का काम कम किया जाए.
मुझे नहीं लगता कि केवल code ही पूरी तरह छोड़ा जा सकता है.
मेरा मानना है कि यह context और सामने की situation के अनुसार अलग हो सकता है.
टिप्पणी के लिए धन्यवाद.
Hacker News की राय
Agile के ज़रिए एक दिलचस्प पैटर्न देखने को मिला
अगर यह असफल हो जाए, तो उसकी व्याख्या अक्सर “इसे पर्याप्त रूप से लागू नहीं किया गया” के रूप में की जाती है
cloud, microservices, austerity policy जैसी चीज़ों में भी यही पैटर्न दिखा — असफलता का कारण हमेशा कमज़ोर execution माना जाता है, approach खुद कभी गलत नहीं मानी जाती
अगर किसी टीम ने Agile आज़माया और वह सफल नहीं हुआ, तो तुरंत यह बचाव सामने आ जाता है: “वह असली Agile था ही नहीं।” नतीजा यह कि Agile एक ऐसा विचार बन जाता है जो असफल हो ही नहीं सकता
Agile Manifesto सिर्फ values और principles की बात करता है। समस्या उन संगठनात्मक संस्कृतियों में है जो उसे ज़बरदस्ती एक process में बदल देती हैं
असफलता पर भीतर झाँकने के लिए मजबूर करने वाली संरचना अपने आप में बुरी नहीं है। बाहरी कारणों को दोष देने के बजाय आत्मचिंतन करवाने के लिहाज़ से यह एक स्वस्थ प्रणाली भी हो सकती है
ग्राहकों से किया गया roadmap का वादा और लचीली प्रतिक्रिया, दोनों साथ निभाना मुश्किल है। हक़ीक़त में plan-केंद्रित संगठन सिर्फ Agile की नकल करते हैं
असफलता होने पर निष्कर्ष यही निकलता है कि “हमें agents का और इस्तेमाल करना चाहिए था।” यह लगभग उस मज़ाक जैसा लगता है कि “tokens कभी पर्याप्त नहीं होते”
मुझे Agile के औपचारिककरण से डर लगने लगा है
मैंने 40 लोगों की टीम सफलतापूर्वक चलाई है, लेकिन असली Agile को सिर्फ चार वाक्यों में समेटा जा सकता है — लोग, काम करने वाला software, ग्राहक सहयोग, और बदलाव के प्रति प्रतिक्रिया
समस्या यह है कि ‘बड़े अक्षर वाला Agile’ खुद एक अकड़ा हुआ process बन गया
लोगों की संख्या बढ़ते ही goals को align करना मुश्किल हो जाता है, और आखिरकार control और procedures की ज़रूरत पड़ती है
यहाँ तक कि ticket बनाने का अधिकार भी सीमित कर दिया जाता है, जो flexibility से बिल्कुल उलट है
documentation कम हो तो maintenance असंभव हो जाता है, और अंततः चीज़ें YOLO development की ओर बहने लगती हैं
जिन बड़ी कंपनियों में मैंने काम किया, वहाँ का Agile झूठ था
एक सहकर्मी ने कहा था, “अगर अगली sprint का काम पहले ही कर लो, तो सब कुछ हमेशा समय पर पूरा हो जाता है।”
यानी Agile असली काम से ज़्यादा metrics बनाने वाली व्यवस्था के रूप में काम कर रहा था
managers सिर्फ numbers ऊपर जाते देख खुश हो जाते हैं, और product आँकड़ों का उप-उत्पाद बनकर रह जाता है
Agile Manifesto के मूल पाठ को फिर से देखना चाहिए
वही एकमात्र साझा आधार है। Agile से पहले का Waterfall कितना भयानक था, यह याद रखना चाहिए
उसने उस दौर का अंत किया जिसमें fixed schedule और deliverables थोपे जाते थे
क्योंकि अगर टीम स्वायत्तता से काम करे, तो उनकी अपनी भूमिका खतरे में पड़ जाती है
जैसा Kent Beck ने “Extreme Programming” में कहा था, Agile कल्पित सर्वज्ञता की तानाशाही से बचने की कोशिश थी
पुराने Waterfall में design phase के दौरान सब कुछ पहले से भाँप लेने की कोशिश की जाती थी, और learning व feedback को नज़रअंदाज़ किया जाता था
लेकिन समय के साथ Agile के rituals और formalities ने उसकी मूल भावना को ढक दिया
मुझे अब भी Agentic programming पसंद है, लेकिन अंत में सबसे महत्वपूर्ण चीज़ context को जोड़ने में इंसान की भूमिका ही है
मूल लेख उलझाऊ था
एक तरफ़ वह कहता है कि Agile ने कुछ नया बनाया ही नहीं, दूसरी तरफ़ यह दावा करता है कि LLM जब code लिखते हैं तो Agile मर गया
लेकिन Agile का सार है अपूर्ण specifications को स्वीकार करना और iteration के ज़रिए सुधार करना
यह सिद्धांत अब भी वैध है
Agile उसकी सिर्फ एक variation है; समस्या यह है कि इसके बहुत से खराब implementations रहे हैं
अच्छे products आखिरकार specification → learning → revision के चक्र से ही निकलते हैं
Backlog Grooming, Sprint Review जैसी प्रक्रियाएँ उल्टा changes को दबाने लगती हैं
Spec-आधारित development शायद ज़्यादा लंबे समय तक नहीं टिकेगा
अब भी काम करने वाला software बनाना और iteration करना ज़्यादा तेज़ है — यानी आखिरकार Agile की वापसी
specifications की quality बेहतर हुई है, और code की तुलना में review आसान हो गया है
GitHub लिंक देखें
manifesto में Daily Standup या Agile Coach जैसी कोई बात नहीं है
मूल बात यह है: “programmers को micromanage मत करो”
यानी संदेश यह है कि प्रेरित लोगों को माहौल और भरोसा दो
Kent Beck, Martin Fowler जैसे संस्थापकों का मूल इरादा लचीली guidelines देना था
लेकिन समय के साथ यह व्यावसायिक उत्पाद बन गया, और अंधभक्त अनुयायी पैदा हो गए, जिससे भ्रम और बढ़ा
सफलता आखिरकार लोगों की क्षमता और रवैये पर निर्भर करती है
sprint की लंबाई भी हालात के मुताबिक़ समायोजित होनी चाहिए, और अगर specification न हो तो टीम को खुद बनानी चाहिए
AI के युग में भी, अगर कोई Agile का समझदारी से उपयोग करे, तो यह अब भी प्रासंगिक है
मैं यह जानने को उत्सुक था कि “Spec लिखना” से ठीक-ठीक मतलब क्या है
जिन भी Agile projects पर मैंने काम किया, उनमें design documents थे, और tickets उन्हीं दस्तावेज़ों से निकलते थे
दस्तावेज़ों के बिना ticket-आधारित development तो नर्क जैसा होगा
हर कोई उन्हें अपने हिसाब से समझ लेता है
ticket-केंद्रित approach उल्टा अधिक शुद्ध Agile के क़रीब है
नकली Agile में PO या PM द्वारा बनाए गए documents को ही सच मान लिया जाता है
आपने जो तरीका बताया, वही मेरी नज़र में ‘spec लिखने’ के अर्थ के सबसे क़रीब है