Agile को अलविदा कहते हुए

• सॉफ्टवेयर उद्योग पर लंबे समय तक हावी रही 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 सोच की ओर लौटना चाहिए