Agile के 20 साल: असफल विद्रोह

<p>- Agile Manifesto (एजाइल घोषणा-पत्र) को जारी हुए 20 साल बीत चुके हैं, और अब दो बातें साफ़ हैं<br /> 1. Agile नाम जीत गया। कोई भी खुद को non-Agile कहलाना नहीं चाहता<br /> 2. लेकिन Agile को लागू करने के मामले में, यह संस्थापकों के क्रांतिकारी विचारों से काफ़ी कमतर रहा<br /> - "हर कोई कहता है कि वे Agile करते हैं, लेकिन सच में Agile बहुत कम लोग हैं" — ऐसा क्यों हुआ?<br /> <br /> [ Whence The Manifesto : घोषणा-पत्र की शुरुआत कैसे हुई ]<br /> - फ़रवरी 2001 में, 17 software experts का एक समूह Utah के एक ski resort में मिला<br /> - कई दिनों की चर्चा के बाद उन्होंने मिलकर "Agile Software Development Manifesto" लिखा<br /> <br /> - महत्वपूर्ण बात यह थी कि वे "Practitioner (व्यावहारिक काम करने वाले लोग)" थे। वे PM, CTO, VP Eng जैसे लोग नहीं थे। वे developers, programmers, scientists और engineers थे। वे उस समय भी लगातार code लिख रहे थे, stakeholders के साथ मिलकर समस्याएँ सुलझा रहे थे। यह सच में बहुत महत्वपूर्ण है.<br /> - दूसरा बिंदु यह है कि Agile Manifesto शून्य से नहीं बना था। उनमें से कई लोगों के पास पहले से अपनी बनाई या प्रचारित methodologies थीं।<br /> → XP, Scrum, DSDM, Adaptive Software Development, Crystal, FDD, Progmatic Programming <br /> <br /> - समूह के सभी लोगों के पास software development का लंबा अनुभव था, और वे उस भारी-भरकम, document-driven software development process का विकल्प खोज रहे थे जो उस समय बाज़ार की मुख्यधारा थी.<br /> - घोषणा-पत्र का केंद्र 4 मूल्यों की व्याख्या था<br /> <br /> "हम software विकसित करते हुए, और दूसरों को software विकसित करने में मदद करते हुए, software development के बेहतर तरीक़े खोज रहे हैं। इस काम के ज़रिए हमने इन बातों को अधिक मूल्यवान माना है:<br /> - प्रक्रियाओं और tools (processes and tools) की तुलना में individuals and interactions को<br /> - comprehensive documentation की तुलना में working software को<br /> - contract negotiation की तुलना में customer collaboration को<br /> - following a plan की तुलना में responding to change को<br /> यानी बाईं ओर की चीज़ों का भी मूल्य है, लेकिन हम दाईं ओर की चीज़ों को अधिक महत्व देते हैं।"<br /> <br /> [ A New Hope : एक नई उम्मीद ]<br /> - 2021 के नज़रिए से देखें तो आधुनिक software development practices को स्वाभाविक मान लेना आसान है, लेकिन 2001 में ये विचार बेहद क्रांतिकारी थे.<br /> - क्या? आप सभी requirements इकट्ठी करने और सभी features का मूल्यांकन करने से पहले ही software बनाना शुरू कर देंगे? पागलपन है!<br /> - एक महत्वपूर्ण बात जिसे लोग भूलते जा रहे हैं, यह है कि शुरुआत में Agile खुलकर और लड़ाकू अंदाज़ में anti-management था<br /> <br /> - उदाहरण के लिए, Scrum के सह-निर्माता Ken Schwaber ने कहा था कि सभी project managers को हटा देना चाहिए। उनका कहना सिर्फ़ इतना नहीं था कि projects से PM हटाए जाएँ, बल्कि यह कि industry से ही यह job role समाप्त कर देना चाहिए.<br /> <br /> "हमें पता चला कि project manager की भूमिका जटिल और रचनात्मक काम में अल्प-उत्पादक होती है।<br /> project plan में दिखाई देने वाली project manager की सोच,<br /> समस्या को सबसे अच्छे ढंग से सुलझाने के लिए सबकी बुद्धिमत्ता इकट्ठा करने के बजाय,<br /> योजना में लिखी बातों तक ही सबकी रचनात्मकता और बुद्धिमत्ता को सीमित कर देती है।"<br /> <br /> - Scrum master के पास लगभग कोई अधिकार नहीं होता था, और issues पर उनका वोट भी नहीं होता था। वे servant leader* थे; वे टीम की रक्षा करते थे, बाधाएँ हटाते थे, लेकिन टीम को manage नहीं करते थे.<br /> → servant leader : ऐसा नेता जो सेवा-भाव से लोगों की growth और development में मदद करे, leader और टीम के बीच trust बनाए, और संगठन के लक्ष्य हासिल करने में लोगों को स्वयं योगदान देने लायक बनाए<br /> - XP में भी मूल रूप से Tracker और Coach की भूमिकाएँ थीं, और वे लगभग इसी तरह काम करती थीं.<br /> <br /> - Crystal और Hexagonal architecture के संस्थापक Alistair Cockburn ने हाल ही में एक tweet thread में यह बात कही थी<br /> "Scrum ने एक hostile territory में बहुत बड़ा सौदा कराया:<br /> - executives साल में 12 बार, हर sprint के बाद, अपनी इच्छा से दिशा बदल सकते थे<br /> - टीम को गहरे सोचने और काम करने के लिए बिना interruptions और बिना direction changes वाला पूरा एक महीना मिल जाता था<br /> - टीम management की दखलअंदाज़ी के बिना, Bid (priorities तय करने के लिए) के समय यह घोषित कर सकती थी कि एक महीने में क्या हो सकता है और क्या नहीं<br /> - किसी executive ने इससे बेहतर deal कभी नहीं की थी<br /> - किसी development team ने भी इससे बेहतर deal कभी नहीं की थी<br /> "<br /> (अनुवादक टिप्पणी: यह tweet thread मूल रूप से इस सवाल के जवाब में शुरू हुई थी: "यह विचार कहाँ से आया कि Scrum team को sprint में दिए गए सभी items 100% पूरे करने ही चाहिए? यह तो बेतुका है।" पूरी thread पढ़ने की सलाह दी जाती है.)<br /> <br /> - मैंने 15 साल से अधिक समय Agile teams में काम किया है, certified Scrum master भी रहा हूँ, और इस विषय पर कई लोकप्रिय किताबें पढ़ी हैं, लेकिन Scrum के विचार को इतना स्पष्ट और संक्षिप्त रूप में समझाते हुए मैंने पहले कभी नहीं देखा था.<br /> - Scrum एक hostile environment में काम करने के लिए बनाया गया था। यह सोचने और खोजने के लिए समय चाहने वाले developers और दबाव डालने वाले managers के बीच एक तरह का अनुबंध था.<br /> <br /> [ The Empire Strikes Back : साम्राज्य की वापसी ]<br /> - एक मायने में Agile एक grassroots labor movement था। यह practitioners से शुरू होकर executives तक पहुँचा। यह कैसे सफल हुआ?<br /> - आंशिक रूप से इसलिए कि developers की संख्या बढ़ रही थी और business के लिए उनकी value भी बढ़ रही थी<br /> - और बड़ा कारण यह था कि पारंपरिक waterfall development model ठीक से काम नहीं कर रहा था<br /> - जैसे-जैसे software अधिक जटिल हुआ, business की रफ़्तार बढ़ी, और users अधिक परिष्कृत हुए, वैसे-वैसे सब कुछ पहले से plan कर पाना असंभव हो गया.<br /> - iterative development को स्वीकार करना तर्कसंगत था, लेकिन उन managers के लिए यह थोड़ा डरावना था जो सब कुछ पहले से plan करते थे.<br /> <br /> - 2000 के दशक के मध्य तक executives ने इसे पूरी तरह स्वीकार नहीं किया था.<br /> - फिर किसी ने कहा, "चलो engineers जिस पागल idea की बात करते रहते हैं, उसे एक बार आज़माते हैं। हम वैसे भी deadline नहीं पकड़ पा रहे, इससे ज़्यादा बुरा क्या होगा?"<br /> - लेकिन हैरानी की बात यह रही कि यह काम करने लगा। शुरुआत में teams थोड़ी सिमट गईं (धीमी रहीं), लेकिन फिर जैसे-जैसे उन्होंने समझा कि कौन से patterns हर team के लिए काम करते हैं, रफ़्तार बढ़ने लगी.<br /> - कुछ sprints के बाद उन्हें working software, collaboration, inspection and adaptation के लिए समय निकालने, और बाकी हर चीज़ की तुलना में इन्हें प्राथमिकता देने की ताक़त समझ में आने लगी.<br /> <br /> - लगभग 5 वर्षों में Agile सुनी-सुनाई methodology से बदलकर ऐसी चीज़ बन गया जिससे हर कोई परिचित था, भले ही सब उसे पूरी तरह समझते न हों.<br /> - 2005 में Agile और TDD असली differentiators थे<br /> - 2010 तक आधुनिक software teams किसी न किसी रूप में Agile कर रही थीं.<br /> - कम से कम consulting industry में तो यह bubble जैसा था। हालाँकि बड़े enterprises हमेशा धीमे चलते हैं.<br /> <br /> "हमने कर दिखाया! हम जीत गए! आइए, सब जश्न मनाएँ"<br /> यहीं कहानी ख़त्म होती है, और आप browser का tab बंद कर सकते हैं.<br /> <br /> "Winning was easy, young man. Governing’s harder."<br /> "जीतना आसान था, नौजवान। शासन करना ज़्यादा कठिन है।"<br /> → musical Hamilton में चित्रित George Washington<br /> <br /> - दुर्भाग्य से, कई क्रांतियों की तरह Agile की कहानी भी उसके संस्थापकों की कल्पना के मुताबिक़ आगे नहीं बढ़ी.<br /> → यह सामने आया कि "individuals and interactions" को प्राथमिकता देना लोगों को समझाना आसान नहीं है। processes and tools को बेचना कहीं आसान है<br /> (अनुवादक टिप्पणी: यहाँ Sell का अर्थ केवल बेचने से नहीं, बल्कि दूसरों को किसी बात के लिए राज़ी या आश्वस्त करने से भी है, इसलिए इसे मूल रूप में रखा गया है.)<br /> → यह भी स्पष्ट हुआ कि "working software" बनाना, अवास्तविक plans और ढेर सारे documents बनाने से कहीं कठिन है.<br /> → "customer collaboration" के लिए trust और vulnerability चाहिए, लेकिन business में ये हमेशा मौजूद नहीं होते.<br /> → "responding to change" के मुकाबले अक्सर ज़ोर उन executives पर चला गया जो long-term planning और control चाहते थे.<br /> <br /> "यह भी पता चला कि जब Agile को सही ढंग से लागू नहीं किया जाता, तो वह अक्सर chaos जैसा महसूस होता है"<br /> <br /> - लेकिन इसका मतलब यह नहीं कि ये चारों values ग़लत थीं<br /> - इसका मतलब सिर्फ़ इतना है कि यह सब सही ढंग से करने के लिए कुछ मेहनत चाहिए, और यह स्वीकार करने का साहस भी कि software अपनी प्रकृति में अव्यवस्थित और अस्त-व्यस्त होता है.<br /> - आपको यह समझना और मानना होगा कि अगर आप लगातार सीखते, ढलते, सुधारते और ship करते रहें, तो अंततः आप waterfall की तुलना में कहीं बेहतर जगह पहुँच सकते हैं — अधिक ईमानदार, अधिक वास्तविक और अधिक उत्पादक जगह.<br /> <br /> "Agile movement anti-methodology नहीं है।<br /> असल में हममें से कई लोग चाहते हैं कि 'methodology' शब्द पर भरोसा फिर से लौटे। हम संतुलन की बहाली चाहते हैं।<br /> हम modeling को स्वीकार करते हैं, लेकिन इसलिए नहीं कि diagrams को किसी धूल भरे corporate storeroom में रख दिया जाए।<br /> हम documentation को स्वीकार करते हैं, लेकिन ऐसी सैकड़ों पन्नों की किताबों को नहीं जो maintained न हों और शायद ही कभी उपयोग में आएँ।<br /> हम plans बनाते हैं, लेकिन उथल-पुथल भरे environment में उनकी सीमाएँ भी पहचानते हैं।<br /> जो लोग XP, Scrum या अन्य Agile methodologies के समर्थकों को 'Hacker' कहकर खारिज करते हैं, वे 'methodology' और 'hacker' दोनों शब्दों की मूल परिभाषाओं से अनजान हैं।"<br /> - Jim Highsmith, History: The Agile Manifesto<br /> <br /> - यही मुख्य बिंदु हैं। हम अब भी plans और documents बनाते हैं, और हमें Agile के प्रति अनुशासित रहना चाहिए। बात संतुलन की है.<br /> - लेकिन यदि आपका organization Agile transition में संघर्ष कर रहा है और chaos में फँसा है, तो अगर कोई certification, process, tool जैसी lifeboat ऑफ़र करे, तो आप तुरंत उधर कूद पड़ते हैं.<br /> - executives को "self-organizing team" की तुलना में processes और tools कहीं बेहतर समझ आते हैं.<br /> <br /> [ R̶e̶t̶u̶r̶n̶ ̶o̶f̶ ̶t̶h̶e̶ Rogue One : Rogue One की वापसी ]<br /> - यहीं मेरी तीन-अंकीय संरचना थोड़ी टूट जाती है, क्योंकि मुझे ऐसा कोई बहादुर विद्रोही वापस आता नहीं दिखता जो Agile का नाम लिए बिना लौटे<br /> (अनुवादक टिप्पणी: यह Star Wars series के शीर्षकों की ओर इशारा है — यानी Agile के विकल्प के रूप में कोई और चीज़ सामने नहीं आई.)<br /> <br /> - tool vendors, process consultants और experts अक्सर ऐसे वादे करते हैं जिन्हें वे कभी पूरा नहीं कर सकते.<br /> - यही वजह है कि हमने SAFe (Scale Agile Framework for Enterprise), Scaled Scrum और enterprise के लिए Agile के अन्य versions बनाए.<br /> - ये frameworks किसी बुरी नीयत से नहीं बनाए गए थे, और शायद सही context में इनमें कुछ value भी हो.<br /> - लेकिन मैं उन्हें Agile नहीं कहूँगा<br /> - जब आप individuals and interactions पर केंद्रित methodology को scale करने की कोशिश करते हैं, तो समस्याएँ लगभग अनिवार्य होती हैं, और methodology की मूल values को नुकसान पहुँचता है.<br /> <br /> - Agile Manifesto के हस्ताक्षरकर्ताओं में से एक और XP के सह-संस्थापक Ron Jeffries ने 2018 में एक प्रसिद्ध लेख लिखा था<br /> <br /> "Developers को Agile छोड़ देना चाहिए।<br /> जब 'Agile' ideas को सही ढंग से लागू नहीं किया जाता, तो developers पर ज़्यादा दखलअंदाज़ी होती है, उन्हें काम के लिए कम समय दिया जाता है, उन पर ज़्यादा दबाव डाला जाता है, और उनसे 'तेज़ी से आगे बढ़ने' की माँग की जाती है। यह developers के लिए अच्छा नहीं है, और अंततः company के लिए भी अच्छा नहीं है। क्योंकि 'Agile' को सही ढंग से न करने पर अक्सर कहीं ज़्यादा defects और कहीं धीमी प्रगति मिलती है, जितनी वास्तव में हासिल की जा सकती थी। कई बार बेहतरीन developers ऐसी companies छोड़ देते हैं, और नतीजा यह होता है कि company 'Agile' अपनाने से पहले की तुलना में भी कम प्रभावी हो जाती है।"<br /> <br /> - एक अन्य हस्ताक्षरकर्ता और Pragmatic Programming के सह-संस्थापक Dave Thomas ने 2014 में एक प्रसिद्ध लेख लिखा था<br /> <br /> "Agile मर चुका है। (Agility अमर रहे)<br /> 'Agile' शब्द को इस हद तक subvert कर दिया गया है कि वह लगभग अर्थहीन हो चुका है, और Agile community बड़े पैमाने पर consultants और vendors के लिए services और products बेचने की जगह बन गई है। जैसे-जैसे Manifesto लोकप्रिय हुआ, 'Agile' शब्द एक ऐसे चुंबक में बदल गया जो हर उस चीज़ को खींच लाता था जिसके पीछे कोई समर्थन, billable hours, या बेचने लायक product हो। इस तरह यह एक marketing term बन गया।<br /> <br /> इसलिए मुझे लगता है कि अब 'Agile' शब्द को retire कर देने का समय आ गया है।"<br /> <br /> [ Retro : अतीत की ओर वापसी ]<br /> - सबसे दुखद बात यह है कि युवा developers को Agile एक ऐसे साधन के रूप में दिखता है जो developers को नीचा दिखाता है, executives से अवास्तविक commitments निकलवाता है, और developers को बेहद लंबे घंटे काम करने के लिए धकेलता है.<br /> - उनके लिए Agile का मतलब वही control mechanism है जो उन पर थोपा गया, न कि वह empowering tool जिसे कभी खुशी से अपनाया गया था.<br /> - फिर भी, उम्मीद है कि इस इतिहास और मूल vision पर चर्चा शुरू करना हमें यह याद रखने में मदद करेगा कि आगे कैसे बढ़ना है.<br /> <br /> - इसके बावजूद अच्छी खबर यह है कि Agile Manifesto के principles आज भी उतने ही समझदार और प्रासंगिक हैं जितने 20 साल पहले थे। और Jeffries या Thomas जैसे कथित apostates भी अभी तक ऐसा ही मानते हैं.<br /> <br /> - ऊपर उल्लेखित लेख में Jeffries ने यह कहा था<br /> "लेकिन Agile Software Development Manifesto के values और principles अब भी मुझे software बनाने का सबसे अच्छा ज्ञात तरीका देते हैं, और अपने लंबे व विविध अनुभव के आधार पर मैं किसी बड़े organization में कोई भी methodology उपयोग करूँ, फिर भी उन्हीं values और principles का पालन करूँगा।"<br /> <br /> - मैं इस राय से सहमत हूँ<br /> - आज Agile के बारे में बात करना न तो trendy है और न cool। Agile अब boring है.<br /> "सब Agile करते हैं, है ना?"<br /> - अभी पिछले 20 वर्षों को पलटकर देखने और खुद से कुछ सवाल पूछने का बिल्कुल सही समय है<br /> → क्या सही हुआ?<br /> → क्या ग़लत हुआ?<br /> → अगली बार हम क्या अलग करना चाहेंगे?<br /> - अगले कुछ महीनों में मैं मूल 12 Agile principles को फिर से देखना, उनके मूल अर्थ को context में रखना, और आज के software development environment में उनकी value पर विचार करना चाहता हूँ.<br /> <br /> "मेरी आशा है कि संस्थापक principles का अध्ययन करके हम अतीत से सीख सकें, और Dave Thomas के शब्दों में, भले ही 'Agile' को छोड़ दें, लेकिन 'Agility' को बनाए रखें।"</p>

[kaykim]

<p>मैं नीचे दिए गए विवरण से सहमत हूँ, और बाकी बातों को उतना महत्व नहीं देता।<br /> <br /> &gt; &quot;'Agile' शब्द को व्यावहारिक रूप से इतना उलट-पुलट दिया गया है कि उसका अर्थ लगभग खत्म हो गया है, और Agile community भी कुल मिलाकर consultants और vendors के लिए अपनी services और products बेचने की जगह बन गई है।&quot;<br /> <br /> उसका कारण, जैसा कि हम सब पहले से जानते हैं, यह है कि कोई भी method commercial (या project) सफलता की गारंटी नहीं देता। यहाँ तक कि खास तौर पर games के संदर्भ में एक ऐसा अध्ययन भी था जिसमें पाया गया कि Agile, दूसरे approaches की तुलना में सांख्यिकीय रूप से अधिक महत्वपूर्ण परिणाम नहीं देता:<br /> <br /> &quot;महान game development teams यह सुनिश्चित करती हैं कि सभी सदस्य studio की development methodology को अच्छी तरह सीखें और उसका पालन करें [1]। साथ ही, game development के दौरान भी वे लगातार मेहनत करके development methods को निखारती और सुधारती रहती हैं। इसके बावजूद, हम Agile, Agile-Scrum, और waterfall development methods के बीच प्रदर्शन में कोई सांख्यिकीय रूप से महत्वपूर्ण अंतर नहीं खोज पाए [2]। development methodologies में प्रदर्शन का अंतर सिर्फ एक मामले में दिखा: जब कोई development methodology थी ही नहीं। हमारे अध्ययन में पाया गया कि team members की संख्या चाहे अधिक हो या कम, development methodology का न होना विनाशकारी है।<br /> <br /> development methodology के लिए कोई सार्वभौमिक सही उत्तर नहीं है। वही methodology चुनिए जो आपको अपने team और project के लिए सबसे उपयुक्त लगती हो।&quot;<br /> <br /> (स्रोत: https://masterfarseer.blogspot.com/2015/03/5.html )<br /> <br /> फिर भी, मैं Agile approach (और अधिक सटीक रूप से Scrum, XP, और Kanban) को इसलिए पसंद करता हूँ क्योंकि यह उन समस्याओं को हल करती है जिनका मैं सामना कर रहा हूँ (It works!)। इसी कारण &quot;Agile Manifesto&quot; का मेरा सबसे पसंदीदा हिस्सा है: &quot;हम software develop करके, और दूसरों को software develop करने में मदद करके, software development के बेहतर तरीकों की खोज कर रहे हैं।&quot; मुझे यह इसलिए पसंद है क्योंकि यह किसी सिद्धांत के आधार पर methodology बनाने की बात नहीं करता, बल्कि इस आधार पर टिका है कि 'मैंने इसे खुद करके देखा, प्रभाव मिला, और दूसरों को भी सुझाया तो वहाँ भी असर हुआ।' Ken Schwaber और Mike Beedle की Agile Software Deveopment with Scrum में भी उस यात्रा का उल्लेख है जिसमें पहले practices विकसित हुईं, और बाद में उनका सैद्धांतिक आधार खोजा गया। और यदि इस दृष्टिकोण से देखें, तो मुझे लगता है कि कभी न कभी कोई Agile को और विकसित कर सकता है, या Agile से भी बेहतर कुछ आविष्कार कर सकता है।<br /> <br /> बाकी सभी tools की तरह Agile भी कोई रामबाण इलाज नहीं है, इसलिए मुझे लगता है कि यह कुछ लोगों के लिए प्रभावी होगा और कुछ के लिए नहीं। इसलिए अब अगर कोई Agile से सफल हुआ हो तो मुझे उससे कोई विशेष अतिरिक्त हौसला नहीं मिलता, और अगर कोई असफल हुआ हो तो उससे मैं खास तौर पर निराश भी नहीं होता। साथ ही, अगर कोई बेहतर तरीका है, तो मैं उसे कभी भी आज़माने और उसके अनुसार ढलने (inspect and adapt) के लिए पूरी तरह तैयार हूँ। क्योंकि वही असली सीख है जो Scrum ने मुझे दी है।</p>

[kenuheo]

<p>- प्रक्रिया और टूल्स &lt; व्यक्ति और इंटरैक्शन<br /> - व्यापक दस्तावेज़ीकरण &lt; काम करने वाला सॉफ़्टवेयर<br /> - कॉन्ट्रैक्ट नेगोशिएशन &lt; ग्राहक के साथ सहयोग<br /> - योजना का पालन करना &lt; बदलाव के प्रति प्रतिक्रिया देना<br /> <br /> अब यहाँ असमानता का चिह्न बदलकर देखें<br /> <br /> - प्रक्रिया और टूल्स &gt; व्यक्ति और इंटरैक्शन<br /> - व्यापक दस्तावेज़ीकरण &gt; काम करने वाला सॉफ़्टवेयर<br /> - कॉन्ट्रैक्ट नेगोशिएशन &gt; ग्राहक के साथ सहयोग<br /> - योजना का पालन करना &gt; बदलाव के प्रति प्रतिक्रिया देना<br /> <br /> तो यह SI बन जाता है।<br /> <br /> सारांश अनुवाद के लिए धन्यवाद।</p>

[xguru]

<p>- क्यों (कुछ) डेवलपर्स Agile को नापसंद करते हैं https://hi.news.hada.io/topic?id=661<br /> - क्यों कुछ Google डेवलपर्स कहते हैं कि एजाइल डेवलपमेंट बेमानी है, इस पर एक पूर्व Google Engineering Director का जवाब https://hi.news.hada.io/topic?id=265<br /> - Spotify का Squad टीम मॉडल विफल था https://hi.news.hada.io/topic?id=2191<br /> → 2012 में मशहूर हुआ Spotify का &quot;Scaling Agile&quot; श्वेतपत्र सिर्फ उनकी आशा था, इसे कभी पूरी तरह लागू नहीं किया गया।<br /> <br /> - What is Agile? | Atlassian - Atlassian द्वारा समझाया गया Agile A to Z https://hi.news.hada.io/topic?id=4389</p&gt;