2671

EN + हिं Easy

GB What is 'Spiral model cost estimation' and why does it differ fundamentally from Waterfall cost estimation?

IN 'सर्पिल मॉडल लागत अनुमान' क्या है और यह झरना लागत अनुमान से मौलिक रूप से भिन्न क्यों है?

A

Both models use identical cost estimation approaches; the methodology does not affect estimation accuracy दोनों मॉडल समान लागत अनुमान दृष्टिकोण का उपयोग करते हैं; कार्यप्रणाली अनुमान सटीकता को प्रभावित नहीं करती है

B

Spiral estimates costs cycle by cycle with increasing accuracy as risks resolve — early cycles have wide estimate ranges (4x uncertainty); by LCA the range narrows to 1.25x; total project cost emerges as a cumulative sum, unlike Waterfall's single upfront estimate that assumes requirements are complete and stable जैसे-जैसे जोखिम हल होते जाते हैं सर्पिल अनुमान लागत चक्र दर चक्र बढ़ती सटीकता के साथ - प्रारंभिक चक्रों में व्यापक अनुमान सीमाएँ (4x अनिश्चितता) होती हैं; एलसीए द्वारा सीमा 1.25x तक सीमित हो जाती है; कुल परियोजना लागत एक संचयी योग के रूप में उभरती है, वॉटरफॉल के एकल अग्रिम अनुमान के विपरीत जो मानता है कि आवश्यकताएं पूर्ण और स्थिर हैं

C

Spiral model cannot produce cost estimates; it only supports time-and-materials contracts सर्पिल मॉडल लागत अनुमान उत्पन्न नहीं कर सकता; यह केवल समय-और-सामग्री अनुबंधों का समर्थन करता है

D

Spiral cost estimation is always more expensive than Waterfall due to risk analysis overhead जोखिम विश्लेषण ओवरहेड के कारण सर्पिल लागत अनुमान हमेशा वॉटरफॉल से अधिक महंगा होता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) The fundamental difference is honesty about uncertainty. Waterfall produces a single-point estimate at initiation with false precision. Spiral acknowledges the cone of uncertainty: 'early cycle cost is $200K; we estimate 3-5 more cycles but cannot commit to total cost until after LCA.' After LCA: 'total project cost is $2.5M ± 15%.' This progressive commitment model matches the available information, avoiding the classic Waterfall trap of making binding commitments on insufficient knowledge.

व्याख्या (हिन्दी) मूलभूत अंतर अनिश्चितता के बारे में ईमानदारी है। झरना झूठी परिशुद्धता के साथ आरंभ में एकल-बिंदु अनुमान उत्पन्न करता है। स्पाइरल अनिश्चितता के शंकु को स्वीकार करता है: 'प्रारंभिक चक्र लागत $200K है; हम 3-5 और चक्रों का अनुमान लगाते हैं लेकिन एलसीए के बाद तक कुल लागत के लिए प्रतिबद्ध नहीं हो सकते।' एलसीए के बाद: 'कुल परियोजना लागत $2.5 मिलियन ± 15% है।' यह प्रगतिशील प्रतिबद्धता मॉडल उपलब्ध जानकारी से मेल खाता है, अपर्याप्त ज्ञान पर बाध्यकारी प्रतिबद्धता बनाने के क्लासिक वाटरफॉल जाल से बचता है।

2672

EN + हिं Medium

GB In the Spiral model, how is 'prototype fidelity' determined for each risk resolution cycle?

IN स्पाइरल मॉडल में, प्रत्येक जोखिम समाधान चक्र के लिए 'प्रोटोटाइप निष्ठा' कैसे निर्धारित की जाती है?

A

All Spiral prototypes must be high-fidelity working implementations by requirement सभी स्पाइरल प्रोटोटाइप आवश्यकता के अनुसार उच्च-निष्ठा वाले कार्य कार्यान्वयन वाले होने चाहिए

B

Prototype fidelity is determined by the minimum fidelity needed to answer the specific risk question — a paper prototype answers 'do users understand this workflow?'; a performance benchmark answers 'can this algorithm meet latency requirements?'; high fidelity is only used when lower fidelity cannot resolve the uncertainty प्रोटोटाइप निष्ठा विशिष्ट जोखिम प्रश्न का उत्तर देने के लिए आवश्यक न्यूनतम निष्ठा द्वारा निर्धारित की जाती है - एक पेपर प्रोटोटाइप उत्तर देता है 'क्या उपयोगकर्ता इस वर्कफ़्लो को समझते हैं?'; एक प्रदर्शन बेंचमार्क उत्तर देता है 'क्या यह एल्गोरिदम विलंबता आवश्यकताओं को पूरा कर सकता है?'; उच्च निष्ठा का उपयोग केवल तभी किया जाता है जब कम निष्ठा अनिश्चितता का समाधान नहीं कर सकती

C

Prototype fidelity must always increase monotonically across Spiral cycles सर्पिल चक्रों में प्रोटोटाइप निष्ठा हमेशा एकरस रूप से बढ़नी चाहिए

D

Fidelity is always determined by the customer's visual expectations, never by technical risk निष्ठा हमेशा ग्राहक की दृश्य अपेक्षाओं से निर्धारित होती है, तकनीकी जोखिम से कभी नहीं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Minimum viable fidelity principle: a paper sketch resolves 'is this the right layout?' without coding. A Wizard of Oz prototype (human simulating AI response) resolves 'will users trust an AI recommendation?' without building the AI. A performance microbenchmark resolves 'can we process 10K transactions/second?' without building the full system. Overbuilding prototypes wastes resources; under-building (too low fidelity to answer the question) produces misleading results.

व्याख्या (हिन्दी) न्यूनतम व्यवहार्य निष्ठा सिद्धांत: एक पेपर स्केच हल करता है 'क्या यह सही लेआउट है?' बिना कोडिंग के. विज़ार्ड ऑफ ओज़ प्रोटोटाइप (मानव अनुकरण एआई प्रतिक्रिया) का समाधान 'क्या उपयोगकर्ता एआई अनुशंसा पर भरोसा करेंगे?' एआई के निर्माण के बिना। एक प्रदर्शन माइक्रोबेंचमार्क यह हल करता है कि 'क्या हम 10K लेनदेन/सेकंड संसाधित कर सकते हैं?' संपूर्ण सिस्टम बनाए बिना. प्रोटोटाइप के अधिक निर्माण से संसाधन बर्बाद होते हैं; अंडर-बिल्डिंग (प्रश्न का उत्तर देने के लिए बहुत कम निष्ठा) भ्रामक परिणाम उत्पन्न करती है।

2673

EN + हिं Easy

GB What is 'Scrumfall' (or 'Scrum-but') anti-pattern and what root cause typically produces it?

IN 'स्क्रमफ़ॉल' (या 'स्क्रम-बट') विरोधी पैटर्न क्या है और कौन सा मूल कारण आम तौर पर इसे उत्पन्न करता है?

A

Scrumfall is a certified Scrum variant officially endorsed by the Scrum Alliance स्क्रमफ़ॉल एक प्रमाणित स्क्रम संस्करण है जो आधिकारिक तौर पर स्क्रम एलायंस द्वारा समर्थित है

B

Scrumfall describes organisations using Scrum terminology (sprints, standups) while retaining Waterfall's underlying structure (big upfront design, phase gates, no real iteration) — typically caused by organisational resistance to genuine agile transformation, where teams adopt ceremonies without changing fundamental practices स्क्रमफ़ॉल, वॉटरफ़ॉल की अंतर्निहित संरचना (बड़े अपफ्रंट डिज़ाइन, चरण द्वार, कोई वास्तविक पुनरावृत्ति नहीं) को बनाए रखते हुए स्क्रम शब्दावली (स्प्रिंट, स्टैंडअप) का उपयोग करने वाले संगठनों का वर्णन करता है - आमतौर पर वास्तविक चुस्त परिवर्तन के लिए संगठनात्मक प्रतिरोध के कारण होता है, जहां टीमें मौलिक प्रथाओं को बदले बिना समारोह अपनाती हैं

C

Scrumfall is a hybrid methodology specifically designed for hardware-software co-development स्क्रमफ़ॉल एक हाइब्रिड पद्धति है जिसे विशेष रूप से हार्डवेयर-सॉफ़्टवेयर सह-विकास के लिए डिज़ाइन किया गया है

D

Scrumfall occurs only when Scrum Masters lack proper certification स्क्रमफ़ॉल केवल तभी होता है जब स्क्रम मास्टर्स के पास उचित प्रमाणीकरण का अभाव होता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Scrumfall symptoms: sprints exist but requirements are frozen upfront for the entire release; 'sprint review' is a status report rather than genuine stakeholder feedback; the Definition of Done doesn't actually mean shippable. Root cause: management retains command-and-control culture and risk-aversion incompatible with agile's empirical, adaptive philosophy, while mandating 'we're doing Scrum now' without addressing underlying organisational dynamics.

व्याख्या (हिन्दी) स्क्रमफ़ॉल लक्षण: स्प्रिंट मौजूद हैं लेकिन संपूर्ण रिलीज़ के लिए आवश्यकताएँ पहले से ही स्थिर हैं; 'स्प्रिंट समीक्षा' वास्तविक हितधारक प्रतिक्रिया के बजाय एक स्थिति रिपोर्ट है; पूर्ण की परिभाषा का वास्तव में मतलब शिप करने योग्य नहीं है। मूल कारण: प्रबंधन कमांड-एंड-कंट्रोल संस्कृति और जोखिम-विपरीतता को एजाइल के अनुभवजन्य, अनुकूली दर्शन के साथ असंगत बनाए रखता है, जबकि अंतर्निहित संगठनात्मक गतिशीलता को संबोधित किए बिना 'हम अभी स्क्रम कर रहे हैं' को अनिवार्य करते हैं।

2674

EN + हिं Easy

GB What is 'velocity-driven planning' fallacy and why does treating velocity as a target rather than a measurement backfire?

IN 'वेग-संचालित योजना' की भ्रांति क्या है और वेग को माप के बजाय एक लक्ष्य के रूप में मानने का परिणाम उल्टा क्यों पड़ता है?

A

Velocity-driven planning fallacy does not exist; velocity targets always improve team performance वेग-चालित योजना संबंधी भ्रांति मौजूद नहीं है; वेग लक्ष्य हमेशा टीम के प्रदर्शन में सुधार करते हैं

B

When management sets velocity targets ('the team must achieve 50 points per sprint'), teams respond by inflating story point estimates rather than delivering more actual value — converting a useful forecasting metric into a gamed number that loses its predictive value (Goodhart's Law in action) जब प्रबंधन वेग लक्ष्य निर्धारित करता है ('टीम को प्रति स्प्रिंट 50 अंक प्राप्त करने चाहिए'), तो टीमें अधिक वास्तविक मूल्य देने के बजाय कहानी बिंदु अनुमानों को बढ़ाकर प्रतिक्रिया देती हैं - एक उपयोगी पूर्वानुमान मीट्रिक को एक गेम संख्या में परिवर्तित करना जो अपना पूर्वानुमानित मूल्य खो देता है (गुडहार्ट का नियम क्रिया में)

C

Velocity targets are always achievable if the team works overtime consistently यदि टीम लगातार ओवरटाइम काम करती है तो वेग लक्ष्य हमेशा प्राप्त किए जा सकते हैं

D

Velocity should always increase every sprint as a measure of team improvement टीम में सुधार के उपाय के रूप में प्रत्येक स्प्रिंट में वेग हमेशा बढ़ना चाहिए

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Velocity is meant to be a forecasting tool derived from historical data, used by the team for its own sprint planning. When it becomes an external performance target, the team's incentive shifts from accurate estimation to estimate inflation — a story that was '3 points' last month becomes '5 points' this month with no actual change in scope. The metric becomes useless for its original purpose: predicting delivery dates.

व्याख्या (हिन्दी) वेलोसिटी का मतलब ऐतिहासिक डेटा से प्राप्त एक पूर्वानुमान उपकरण है, जिसका उपयोग टीम द्वारा अपनी स्प्रिंट योजना के लिए किया जाता है। जब यह एक बाहरी प्रदर्शन लक्ष्य बन जाता है, तो टीम का प्रोत्साहन सटीक अनुमान से मुद्रास्फीति का अनुमान लगाने के लिए स्थानांतरित हो जाता है - एक कहानी जो पिछले महीने '3 अंक' थी, इस महीने '5 अंक' हो जाती है, जिसमें दायरे में कोई वास्तविक बदलाव नहीं होता है। मीट्रिक अपने मूल उद्देश्य के लिए बेकार हो जाता है: डिलीवरी की तारीखों की भविष्यवाणी करना।

2675

EN + हिं Easy

GB What is 'agile contracts' and what specific contract type (Money for Nothing, Change for Free) addresses agile's scope flexibility?

IN 'एजाइल कॉन्ट्रैक्ट्स' क्या है और कौन सा विशिष्ट अनुबंध प्रकार (मनी फॉर नथिंग, चेंज फॉर फ्री) एजाइल के दायरे के लचीलेपन को संबोधित करता है?

A

Agile contracts are illegal in most jurisdictions because they lack defined deliverables अधिकांश न्यायक्षेत्रों में एजाइल अनुबंध अवैध हैं क्योंकि उनमें परिभाषित डिलिवरेबल्स का अभाव है

B

'Money for Nothing, Change for Free' (Jeff Sutherland) contracts allow the customer to terminate early (paying only for completed work plus a fee, since remaining low-priority backlog has less value) or substitute new requirements for unbuilt ones of equal estimated size at no extra cost — aligning contract terms with agile's iterative value delivery 'मनी फॉर नथिंग, चेंज फॉर फ्री' (जेफ सदरलैंड) अनुबंध ग्राहक को जल्दी समाप्त करने की अनुमति देते हैं (केवल पूर्ण कार्य के लिए भुगतान और शुल्क, क्योंकि शेष कम प्राथमिकता वाले बैकलॉग का मूल्य कम होता है) या बिना किसी अतिरिक्त लागत के समान अनुमानित आकार के अनबिल्ट के लिए नई आवश्यकताओं को प्रतिस्थापित करते हैं - एजाइल के पुनरावृत्त मूल्य वितरण के साथ अनुबंध की शर्तों को संरेखित करना

C

Agile projects can only use time-and-materials contracts; fixed-price is technically impossible एजाइल परियोजनाएँ केवल समय-और-सामग्री अनुबंधों का उपयोग कर सकती हैं; निश्चित कीमत तकनीकी रूप से असंभव है

D

Agile contracts require the vendor to absorb all financial risk regardless of scope changes एजाइल अनुबंधों के लिए विक्रेता को दायरे में बदलाव की परवाह किए बिना सभी वित्तीय जोखिमों को अवशोषित करने की आवश्यकता होती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) This contract structure resolves the fundamental tension in agile fixed-price contracting: if the team delivers the highest-priority items first (agile's core value), by the time 80% of budget is spent, perhaps 95% of business value is delivered (since priority-ordered delivery means diminishing returns on remaining items). 'Money for Nothing' lets the customer stop early, recognising remaining scope has less value than its cost. 'Change for Free' allows requirement evolution without renegotiation, as long as new items are similarly sized to removed items.

व्याख्या (हिन्दी) यह अनुबंध संरचना एजाइल फिक्स्ड-प्राइस कॉन्ट्रैक्टिंग में मूलभूत तनाव को हल करती है: यदि टीम सर्वोच्च-प्राथमिकता वाली वस्तुओं को पहले वितरित करती है (एजाइल का मुख्य मूल्य), तो बजट का 80% खर्च होने तक, शायद 95% व्यावसायिक मूल्य वितरित किया जाता है (चूंकि प्राथमिकता-आदेशित डिलीवरी का मतलब शेष वस्तुओं पर कम रिटर्न है)। 'मनी फॉर नथिंग' ग्राहक को जल्दी रुकने की सुविधा देता है, यह पहचानते हुए कि शेष गुंजाइश का मूल्य इसकी लागत से कम है। 'मुफ़्त में परिवर्तन' बिना दोबारा बातचीत के आवश्यकता के विकास की अनुमति देता है, जब तक कि नई वस्तुओं का आकार हटाए गए वस्तुओं के समान हो।

2676

EN + हिं Easy

GB What is the 'agile fluency model' and what distinguishes 'Focusing' fluency from 'Delivering' fluency?

IN 'फुर्तीली प्रवाह मॉडल' क्या है और 'फोकसिंग' प्रवाह को 'डिलीवरिंग' प्रवाह से क्या अलग करता है?

A

Both fluency levels are identical; the model only has two stages total दोनों प्रवाह स्तर समान हैं; मॉडल में कुल मिलाकर केवल दो चरण हैं

B

The Agile Fluency Model (Shore, Larsen) describes four zones: Focusing (team works as a unit on business priorities, visible progress), Delivering (team produces low-defect releasable software on demand), Optimising (team optimises for business value and market response), Strengthening (organisation-wide agile capability) — each zone requires different investment and provides different benefits एजाइल फ्लुएंसी मॉडल (शोर, लार्सन) चार क्षेत्रों का वर्णन करता है: फोकस करना (टीम व्यावसायिक प्राथमिकताओं, दृश्यमान प्रगति पर एक इकाई के रूप में काम करती है), वितरित करना (टीम मांग पर कम दोष वाले रिलीज करने योग्य सॉफ़्टवेयर का उत्पादन करती है), अनुकूलन (टीम व्यवसाय मूल्य और बाजार प्रतिक्रिया के लिए अनुकूलन करती है), सुदृढ़ीकरण (संगठन-व्यापी चुस्त क्षमता) - प्रत्येक क्षेत्र को अलग-अलग निवेश की आवश्यकता होती है और अलग-अलग लाभ प्रदान करता है

C

Delivering fluency is always achieved before Focusing fluency in proper agile adoption उचित चुस्त अपनाने में प्रवाह पर ध्यान केंद्रित करने से पहले प्रवाह प्रदान करना हमेशा हासिल किया जाता है

D

The Agile Fluency Model only applies to teams larger than 50 developers एजाइल फ़्लुएंसी मॉडल केवल 50 डेवलपर्स से बड़ी टीमों पर लागू होता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) This model addresses the common mistake of expecting all agile benefits from minimal investment. Focusing fluency (achievable in 2-6 months) gives transparency and business alignment but doesn't reduce defects. Delivering fluency (1-2 years investment in technical practices: TDD, CI/CD, pairing) is required for genuinely low-defect, releasable-anytime software. Organisations often stop at Focusing and wonder why quality hasn't improved — Delivering requires deliberate technical practice investment beyond just adopting ceremonies.

व्याख्या (हिन्दी) यह मॉडल न्यूनतम निवेश से सभी त्वरित लाभों की अपेक्षा करने की सामान्य गलती को संबोधित करता है। प्रवाह पर ध्यान केंद्रित करने (2-6 महीने में प्राप्त करने योग्य) पारदर्शिता और व्यावसायिक संरेखण देता है लेकिन दोषों को कम नहीं करता है। वास्तव में कम दोष वाले, कभी भी जारी किए जा सकने वाले सॉफ़्टवेयर के लिए प्रवाह प्रदान करना (तकनीकी प्रथाओं में 1-2 साल का निवेश: टीडीडी, सीआई/सीडी, पेयरिंग) आवश्यक है। संगठन अक्सर फोकस करना बंद कर देते हैं और आश्चर्य करते हैं कि गुणवत्ता में सुधार क्यों नहीं हुआ - वितरण के लिए केवल समारोहों को अपनाने से परे जानबूझकर तकनीकी अभ्यास निवेश की आवश्यकता होती है।

2677

EN + हिं Easy

GB What is 'dark scrum' and what symptom indicates a team has fallen into this anti-pattern?

IN 'डार्क स्क्रम' क्या है और कौन सा लक्षण बताता है कि एक टीम इस विरोधी पैटर्न में फंस गई है?

A

Dark scrum refers to teams that work exclusively at night to avoid management oversight डार्क स्क्रम उन टीमों को संदर्भित करता है जो प्रबंधन की निगरानी से बचने के लिए विशेष रूप से रात में काम करती हैं

B

Dark scrum occurs when Scrum ceremonies become tools for surveillance and control rather than collaboration — symptoms include: daily standups becoming status reports to managers (not peer coordination), retrospectives where no real issues are raised for fear of repercussions, and velocity used to compare/punish individuals डार्क स्क्रम तब होता है जब स्क्रम समारोह सहयोग के बजाय निगरानी और नियंत्रण के लिए उपकरण बन जाते हैं - लक्षणों में शामिल हैं: दैनिक स्टैंडअप प्रबंधकों के लिए स्थिति रिपोर्ट बन जाते हैं (सहकर्मी समन्वय नहीं), पूर्वव्यापी जहां नतीजों के डर से कोई वास्तविक मुद्दा नहीं उठाया जाता है, और व्यक्तियों की तुलना / दंडित करने के लिए उपयोग किया जाने वाला वेग

C

Dark scrum is a certified advanced agile framework for distributed remote teams डार्क स्क्रम वितरित दूरस्थ टीमों के लिए एक प्रमाणित उन्नत चुस्त ढांचा है

D

Dark scrum only occurs in organisations using the Scrum@Scale framework डार्क स्क्रम केवल स्क्रम@स्केल फ्रेमवर्क का उपयोग करने वाले संगठनों में होता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Authentic Scrum relies on psychological safety — team members must feel safe raising blockers, admitting mistakes, and disagreeing with estimates. Dark scrum subverts this: standups become 'what did you do yesterday, justify it to me' rather than 'what do we need to coordinate?'. Retrospectives become performative ('everything is fine') because raising real issues has led to blame in the past. The ceremonies exist but their psychological foundation — trust — has been destroyed.

व्याख्या (हिन्दी) प्रामाणिक स्क्रम मनोवैज्ञानिक सुरक्षा पर निर्भर करता है - टीम के सदस्यों को अवरोधक उठाने, गलतियों को स्वीकार करने और अनुमानों से असहमत होने में सुरक्षित महसूस करना चाहिए। डार्क स्क्रम इसे नष्ट कर देता है: स्टैंडअप 'हमें समन्वय करने की क्या आवश्यकता है?' के बजाय 'आपने कल क्या किया, इसे मेरे लिए उचित ठहराएं' बन जाते हैं। पूर्वव्यापी प्रभाव प्रदर्शनात्मक हो जाते हैं ('सब कुछ ठीक है') क्योंकि वास्तविक मुद्दों को उठाने से अतीत में दोषारोपण हुआ है। समारोह मौजूद हैं लेकिन उनका मनोवैज्ञानिक आधार - विश्वास - नष्ट हो गया है।

2678

EN + हिं Easy

GB What is 'feature toggle' (feature flag) technique in continuous delivery and what risk does it specifically mitigate?

IN निरंतर डिलीवरी में 'फ़ीचर टॉगल' (फ़ीचर फ़्लैग) तकनीक क्या है और यह विशेष रूप से किस जोखिम को कम करती है?

A

Feature toggles only control which programming language compiles a given module फ़ीचर टॉगल केवल यह नियंत्रित करता है कि कौन सी प्रोग्रामिंग भाषा किसी दिए गए मॉड्यूल को संकलित करती है

B

Feature toggles wrap new code behind a runtime switch, allowing code to be merged and deployed to production while remaining invisible/inactive to users — mitigating the risk of long-lived feature branches (merge conflicts, integration hell) while still enabling controlled, gradual feature rollout फ़ीचर टॉगल नए कोड को रनटाइम स्विच के पीछे लपेटते हैं, जिससे कोड को मर्ज किया जा सकता है और उपयोगकर्ताओं के लिए अदृश्य/निष्क्रिय रहते हुए उत्पादन में तैनात किया जा सकता है - नियंत्रित, क्रमिक फ़ीचर रोलआउट को सक्षम करते हुए लंबे समय तक चलने वाली फ़ीचर शाखाओं (मर्ज संघर्ष, एकीकरण नरक) के जोखिम को कम किया जा सकता है।

C

Feature toggles are only used for A/B testing marketing campaigns फ़ीचर टॉगल का उपयोग केवल ए/बी परीक्षण विपणन अभियानों के लिए किया जाता है

D

Feature toggles eliminate the need for any testing because they can be turned off if broken फ़ीचर टॉगल किसी भी परीक्षण की आवश्यकता को ख़त्म कर देते हैं क्योंकि टूटने पर उन्हें बंद किया जा सकता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Without feature toggles, a feature requiring 3 weeks of development means a 3-week-long feature branch — diverging significantly from main, creating merge hell. With feature toggles, code merges to main daily (behind the flag, inactive), maintaining CI's core benefit (frequent integration). When the feature is ready, the flag is flipped — no code merge needed, no deployment needed, just a configuration change, often gradually (1% of users → 10% → 100%) with instant rollback capability.

व्याख्या (हिन्दी) फ़ीचर टॉगल के बिना, 3 सप्ताह के विकास की आवश्यकता वाले फ़ीचर का अर्थ है 3-सप्ताह लंबी फ़ीचर शाखा - मुख्य से महत्वपूर्ण रूप से अलग होना, मर्ज नरक बनाना। फीचर टॉगल के साथ, कोड मुख्य दैनिक (ध्वज के पीछे, निष्क्रिय) में विलीन हो जाता है, जिससे सीआई का मुख्य लाभ (लगातार एकीकरण) बना रहता है। जब सुविधा तैयार हो जाती है, तो फ़्लैग फ़्लिप कर दिया जाता है - किसी कोड मर्ज की आवश्यकता नहीं, किसी परिनियोजन की आवश्यकता नहीं, बस एक कॉन्फ़िगरेशन परिवर्तन, अक्सर धीरे-धीरे (1% उपयोगकर्ता → 10% → 100%) तत्काल रोलबैक क्षमता के साथ।

2679

EN + हिं Easy

GB What is the 'agile testing quadrants' model (Marick, Crispin) and what distinguishes Q1 from Q4?

IN 'एजाइल टेस्टिंग क्वाड्रंट्स' मॉडल (मैरिक, क्रिस्पिन) क्या है और Q1 को Q4 से क्या अलग करता है?

A

Q1 and Q4 represent the same testing activities performed in different sprints Q1 और Q4 अलग-अलग स्प्रिंट में की गई समान परीक्षण गतिविधियों का प्रतिनिधित्व करते हैं

B

Q1 (technology-facing, supports team — unit/component tests automating internal quality) is the opposite corner from Q4 (business-facing, critiques product — exploratory testing, usability testing, UAT evaluating whether the right product was built) — together the four quadrants ensure both internal quality and external value are tested Q1 (प्रौद्योगिकी-सामना, टीम का समर्थन करता है - आंतरिक गुणवत्ता को स्वचालित करने वाली इकाई/घटक परीक्षण) Q4 (व्यापार-सामना, आलोचना उत्पाद - खोजपूर्ण परीक्षण, प्रयोज्य परीक्षण, यूएटी का मूल्यांकन करता है कि सही उत्पाद बनाया गया था) से विपरीत कोने है - चार चतुर्थांश मिलकर सुनिश्चित करते हैं कि आंतरिक गुणवत्ता और बाहरी मूल्य दोनों का परीक्षण किया जाता है

C

The four quadrants only apply to web application testing, not desktop or mobile software चार चतुर्थांश केवल वेब एप्लिकेशन परीक्षण पर लागू होते हैं, डेस्कटॉप या मोबाइल सॉफ़्टवेयर पर नहीं

D

Q1 tests are manual; Q4 tests are always fully automated Q1 परीक्षण मैनुअल हैं; Q4 परीक्षण हमेशा पूर्णतः स्वचालित होते हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) The matrix has two axes: business-facing vs technology-facing, and supporting the team vs critiquing the product. Q1 (tech-facing, support team): unit tests, component tests — fast feedback for developers. Q2 (business-facing, support team): functional acceptance tests, story tests — confirm features work as specified. Q3 (business-facing, critique product): exploratory testing, usability testing, UAT — find what specs missed. Q4 (tech-facing, critique product): performance, security, load testing — non-functional quality attributes.

व्याख्या (हिन्दी) मैट्रिक्स की दो धुरी हैं: व्यवसाय-सामना बनाम प्रौद्योगिकी-सामना, और टीम का समर्थन करना बनाम उत्पाद की आलोचना करना। Q1 (तकनीकी-सामना, सहायता टीम): इकाई परीक्षण, घटक परीक्षण - डेवलपर्स के लिए तेज़ प्रतिक्रिया। Q2 (व्यवसाय-सामना, सहायता टीम): कार्यात्मक स्वीकृति परीक्षण, कहानी परीक्षण - पुष्टि करें कि सुविधाएँ निर्दिष्ट के अनुसार काम करती हैं। Q3 (व्यवसाय-सामना, समालोचना उत्पाद): खोजपूर्ण परीक्षण, प्रयोज्यता परीक्षण, यूएटी - पता लगाएं कि कौन से विवरण छूट गए हैं। Q4 (तकनीकी-सामना, आलोचना उत्पाद): प्रदर्शन, सुरक्षा, लोड परीक्षण - गैर-कार्यात्मक गुणवत्ता विशेषताएँ।

2680

EN + हिं Easy

GB What is 'self-organising team' in agile and what does research show about the management style that enables it?

IN एजाइल में 'स्व-संगठित टीम' क्या है और अनुसंधान उस प्रबंधन शैली के बारे में क्या दिखाता है जो इसे सक्षम बनाती है?

A

Self-organising teams require no management oversight whatsoever and operate completely autonomously स्व-संगठित टीमों को किसी भी प्रकार के प्रबंधन निरीक्षण की आवश्यकता नहीं होती है और वे पूरी तरह से स्वायत्त रूप से काम करती हैं

B

A self-organising team determines how to accomplish its work without being directed by management on the specifics of task assignment — research (Hackman's team effectiveness model) shows this requires management to provide clear direction (what/why), adequate resources, and explicit boundaries while deliberately not controlling the how — a balance many managers find difficult एक स्व-संगठित टीम यह निर्धारित करती है कि कार्य असाइनमेंट की विशिष्टताओं पर प्रबंधन द्वारा निर्देशित किए बिना अपना काम कैसे पूरा किया जाए - अनुसंधान (हैकमैन की टीम प्रभावशीलता मॉडल) से पता चलता है कि प्रबंधन को स्पष्ट दिशा (क्या/क्यों), पर्याप्त संसाधन और स्पष्ट सीमाएं प्रदान करने की आवश्यकता होती है, जबकि जानबूझकर कैसे नियंत्रित नहीं किया जाता है - एक संतुलन जो कई प्रबंधकों को मुश्किल लगता है

C

Self-organising teams perform worse than traditionally managed teams according to all empirical studies सभी अनुभवजन्य अध्ययनों के अनुसार स्व-संगठित टीमें पारंपरिक रूप से प्रबंधित टीमों की तुलना में खराब प्रदर्शन करती हैं

D

Self-organisation only works for teams with fewer than 3 members स्व-संगठन केवल 3 से कम सदस्यों वाली टीमों के लिए काम करता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Hackman's research shows self-organisation isn't 'no management' — it's a specific management discipline: leaders set clear goals and constraints (the 'authority boundary'), then deliberately resist micromanaging task allocation, technical approach, and daily work organisation. This is harder than traditional command-and-control for many managers, who must transition from directive to servant-leadership style, providing support and removing obstacles rather than assigning tasks.

व्याख्या (हिन्दी) हैकमैन के शोध से पता चलता है कि स्व-संगठन 'कोई प्रबंधन नहीं' है - यह एक विशिष्ट प्रबंधन अनुशासन है: नेता स्पष्ट लक्ष्य और बाधाएं ('प्राधिकरण सीमा') निर्धारित करते हैं, फिर जानबूझकर माइक्रोमैनेजिंग कार्य आवंटन, तकनीकी दृष्टिकोण और दैनिक कार्य संगठन का विरोध करते हैं। यह कई प्रबंधकों के लिए पारंपरिक कमांड-एंड-कंट्रोल से कठिन है, जिन्हें कार्यों को सौंपने के बजाय निर्देश से नौकर-नेतृत्व शैली, सहायता प्रदान करना और बाधाओं को दूर करना होगा।

2681

EN + हिं Easy

GB What is the 'iron law of agile metrics' and why do output metrics (velocity, story count) often mislead about outcomes?

IN 'एजाइल मेट्रिक्स का लौह नियम' क्या है और आउटपुट मेट्रिक्स (वेग, कहानी गणना) अक्सर परिणामों के बारे में गुमराह क्यों करते हैं?

A

Output metrics always perfectly correlate with business outcomes in well-run agile teams आउटपुट मेट्रिक्स हमेशा अच्छी तरह से संचालित चुस्त टीमों में व्यावसायिक परिणामों के साथ पूरी तरह से सहसंबद्ध होते हैं

B

Output metrics (velocity, stories completed, sprints delivered) measure activity, not value delivered — a team can have high velocity while building features nobody uses; the iron law states that what matters is outcome metrics (user adoption, business KPIs, customer satisfaction) which output metrics don't capture and can even inversely correlate with आउटपुट मेट्रिक्स (वेग, कहानियां पूरी, स्प्रिंट वितरित) गतिविधि को मापते हैं, वितरित मूल्य को नहीं - एक टीम में उन सुविधाओं का निर्माण करते समय उच्च वेग हो सकता है जिनका उपयोग कोई नहीं करता है; लौह कानून कहता है कि जो मायने रखता है वह परिणाम मेट्रिक्स (उपयोगकर्ता अपनाना, व्यवसाय KPI, ग्राहक संतुष्टि) है जो आउटपुट मेट्रिक्स कैप्चर नहीं करते हैं और इसके साथ विपरीत रूप से सहसंबंध भी कर सकते हैं

C

Story count is always a reliable predictor of customer satisfaction across all product types स्टोरी काउंट हमेशा सभी उत्पाद प्रकारों में ग्राहकों की संतुष्टि का एक विश्वसनीय भविष्यवक्ता होता है

D

Agile metrics are entirely subjective and have no quantitative basis whatsoever एजाइल मेट्रिक्स पूरी तरह से व्यक्तिपरक हैं और इनका कोई भी मात्रात्मक आधार नहीं है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Marty Cagan and others highlight this gap repeatedly: a team can ship 50 story points per sprint (high output) building a feature that increases churn (negative outcome) because it added complexity users didn't want. Outcome-focused metrics (activation rate, retention, NPS, revenue impact) measure whether the work mattered. The risk: organisations that only track output metrics optimise for busyness rather than impact, rewarding teams that ship a lot regardless of whether what they ship helps the business.

व्याख्या (हिन्दी) मार्टी कैगन और अन्य लोग इस अंतर को बार-बार उजागर करते हैं: एक टीम प्रति स्प्रिंट (उच्च आउटपुट) में 50 स्टोरी पॉइंट भेज सकती है, जिससे एक ऐसी सुविधा बनती है जो मंथन (नकारात्मक परिणाम) को बढ़ाती है क्योंकि इससे ऐसी जटिलताएं जुड़ जाती हैं जो उपयोगकर्ता नहीं चाहते थे। परिणाम-केंद्रित मेट्रिक्स (सक्रियण दर, प्रतिधारण, एनपीएस, राजस्व प्रभाव) मापते हैं कि कार्य मायने रखता है या नहीं। जोखिम: संगठन जो केवल आउटपुट मेट्रिक्स को ट्रैक करते हैं, वे प्रभाव के बजाय व्यस्तता के लिए अनुकूलन करते हैं, उन टीमों को पुरस्कृत करते हैं जो बहुत अधिक शिप करते हैं चाहे वे जो भी शिप करते हैं वह व्यवसाय में मदद करता है या नहीं।

2682

EN + हिं Medium

GB What is the 'team topology' concept of 'cognitive load' and how does it inform team boundary decisions?

IN 'संज्ञानात्मक भार' की 'टीम टोपोलॉजी' अवधारणा क्या है और यह टीम सीमा निर्णयों को कैसे सूचित करती है?

A

Cognitive load only refers to the number of meetings a team attends per week संज्ञानात्मक भार केवल उन बैठकों की संख्या को संदर्भित करता है जो एक टीम प्रति सप्ताह भाग लेती है

B

Cognitive load (Skelton, Pais) measures the total mental capacity a team needs to understand and operate the systems they own — team boundaries should be drawn so each team's domain fits within reasonable cognitive load (intrinsic, extraneous, germane), preventing teams from being responsible for more complexity than they can effectively reason about संज्ञानात्मक भार (स्केल्टन, पेस) उस कुल मानसिक क्षमता को मापता है जिसे एक टीम को अपने स्वामित्व वाले सिस्टम को समझने और संचालित करने की आवश्यकता होती है - टीम की सीमाएं खींची जानी चाहिए ताकि प्रत्येक टीम का डोमेन उचित संज्ञानात्मक भार (आंतरिक, बाहरी, जर्मन) के भीतर फिट हो, जिससे टीमों को अधिक जटिलताओं के लिए जिम्मेदार होने से रोका जा सके, जिसके बारे में वे प्रभावी ढंग से तर्क कर सकें।

C

Cognitive load is irrelevant to team design; team size is the only factor that matters टीम डिज़ाइन के लिए संज्ञानात्मक भार अप्रासंगिक है; टीम का आकार ही एकमात्र कारक है जो मायने रखता है

D

Teams should always own the maximum number of services possible to maximise efficiency दक्षता को अधिकतम करने के लिए टीमों के पास हमेशा यथासंभव अधिकतम संख्या में सेवाएँ होनी चाहिए

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) This directly informs microservices decomposition: a team owning 15 microservices with complex interdependencies experiences extraneous cognitive load (effort wasted navigating accidental complexity) that crowds out intrinsic load (effort needed for the actual problem). Team Topologies' four team types (stream-aligned, platform, enabling, complicated-subsystem) are designed specifically to manage cognitive load — platform teams absorb complexity so stream-aligned teams can focus their limited cognitive capacity on business value delivery.

व्याख्या (हिन्दी) यह सीधे माइक्रोसर्विसेज अपघटन को सूचित करता है: जटिल अन्योन्याश्रितताओं के साथ 15 माइक्रोसर्विसेज की मालिक एक टीम बाहरी संज्ञानात्मक भार (आकस्मिक जटिलता को नेविगेट करने में व्यर्थ प्रयास) का अनुभव करती है जो आंतरिक भार (वास्तविक समस्या के लिए आवश्यक प्रयास) को कम कर देती है। टीम टोपोलॉजी के चार टीम प्रकार (स्ट्रीम-संरेखित, प्लेटफ़ॉर्म, सक्षम, जटिल-उपप्रणाली) विशेष रूप से संज्ञानात्मक भार को प्रबंधित करने के लिए डिज़ाइन किए गए हैं - प्लेटफ़ॉर्म टीमें जटिलता को अवशोषित करती हैं ताकि स्ट्रीम-संरेखित टीमें व्यावसायिक मूल्य वितरण पर अपनी सीमित संज्ञानात्मक क्षमता पर ध्यान केंद्रित कर सकें।

2683

EN + हिं Easy

GB What is 'WIP limit psychology' and what behavioural change does enforcing strict WIP limits produce in teams?

IN 'डब्ल्यूआईपी सीमा मनोविज्ञान' क्या है और सख्त डब्ल्यूआईपी सीमाएं लागू करने से टीमों में क्या व्यवहारिक परिवर्तन होता है?

A

WIP limits only affect how many monitors a developer can use simultaneously WIP सीमाएँ केवल इस बात को प्रभावित करती हैं कि कोई डेवलपर एक साथ कितने मॉनिटर का उपयोग कर सकता है

B

Enforcing strict WIP limits forces teams to confront bottlenecks immediately rather than accumulating hidden queues — the psychological shift is from individual productivity ('I'm always coding something') to system throughput ('we finish things'), often producing initial discomfort as developers must help unblock others rather than start new work सख्त डब्ल्यूआईपी सीमाएं लागू करने से टीमों को छिपी हुई कतारों को जमा करने के बजाय तुरंत बाधाओं का सामना करने के लिए मजबूर होना पड़ता है - मनोवैज्ञानिक बदलाव व्यक्तिगत उत्पादकता ('मैं हमेशा कुछ कोड कर रहा हूं') से लेकर सिस्टम थ्रूपुट ('हम चीजें खत्म करते हैं') तक होता है, जिससे अक्सर शुरुआती असुविधा होती है क्योंकि डेवलपर्स को नया काम शुरू करने के बजाय दूसरों को अनब्लॉक करने में मदद करनी चाहिए

C

WIP limits have no measurable psychological effect on team behaviour according to research शोध के अनुसार WIP सीमाओं का टीम के व्यवहार पर कोई मापने योग्य मनोवैज्ञानिक प्रभाव नहीं पड़ता है

D

WIP limits should always be set to infinity to maximise individual developer flexibility व्यक्तिगत डेवलपर लचीलेपन को अधिकतम करने के लिए WIP सीमाएँ हमेशा अनंत पर सेट की जानी चाहिए

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Many developers initially resist WIP limits ('I have nothing to do, my task is blocked, why can't I just start something new?'). But starting new work while old work is blocked creates more WIP, hides the bottleneck, and delays everything's completion (Little's Law). Strict WIP limits force the uncomfortable but valuable behaviour: stop, help unblock the stuck item, swarm on bottlenecks. This produces faster overall flow despite individual developers sometimes being temporarily idle.

व्याख्या (हिन्दी) कई डेवलपर्स शुरू में WIP सीमाओं का विरोध करते हैं ('मुझे कुछ नहीं करना है, मेरा कार्य अवरुद्ध है, मैं कुछ नया क्यों नहीं शुरू कर सकता?')। लेकिन पुराना काम अवरुद्ध होने पर नया काम शुरू करने से अधिक WIP पैदा होता है, अड़चन छिप जाती है और हर चीज के पूरा होने में देरी होती है (लिटिल का नियम)। सख्त डब्ल्यूआईपी सीमाएं असुविधाजनक लेकिन मूल्यवान व्यवहार को मजबूर करती हैं: रुकें, अटकी हुई वस्तु को खोलने में मदद करें, बाधाओं पर झुंड बनाएं। व्यक्तिगत डेवलपर्स के कभी-कभी अस्थायी रूप से निष्क्रिय होने के बावजूद यह तेज़ समग्र प्रवाह उत्पन्न करता है।

2684

EN + हिं Easy

GB What is 'agile transformation failure pattern' and what role does 'middle management vacuum' play in it?

IN 'एजाइल ट्रांसफॉर्मेशन फेलियर पैटर्न' क्या है और 'मिडिल मैनेजमेंट वैक्यूम' इसमें क्या भूमिका निभाता है?

A

Agile transformations always succeed if executive sponsorship is strong, regardless of middle management यदि कार्यकारी प्रायोजन मजबूत है, तो मध्य प्रबंधन की परवाह किए बिना, त्वरित परिवर्तन हमेशा सफल होते हैं

B

A common failure pattern occurs when executives mandate agile and teams adopt ceremonies, but middle managers (whose traditional command-and-control role conflicts with self-organising teams) are neither retrained for new roles (coaching, removing obstacles) nor eliminated — creating organisational confusion where two incompatible management models coexist, undermining both एक सामान्य विफलता पैटर्न तब होता है जब अधिकारी चुस्त-दुरुस्त होते हैं और टीमें समारोह अपनाती हैं, लेकिन मध्य प्रबंधकों (जिनकी पारंपरिक कमांड-और-नियंत्रण भूमिका स्व-संगठित टीमों के साथ संघर्ष करती है) को न तो नई भूमिकाओं (प्रशिक्षण, बाधाओं को दूर करना) के लिए फिर से प्रशिक्षित किया जाता है और न ही समाप्त किया जाता है - संगठनात्मक भ्रम पैदा होता है जहां दो असंगत प्रबंधन मॉडल सह-अस्तित्व में होते हैं, दोनों को कमजोर करते हैं

C

Middle managers always embrace agile transformation enthusiastically with no resistance मध्य प्रबंधक हमेशा बिना किसी प्रतिरोध के उत्साहपूर्वक त्वरित परिवर्तन को अपनाते हैं

D

Eliminating all middle management roles guarantees successful agile transformation सभी मध्य प्रबंधन भूमिकाओं को ख़त्म करना सफल तीव्र परिवर्तन की गारंटी देता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) This is one of the most documented agile transformation failure modes (McKinsey, Forbes case studies). Middle managers previously assigned tasks and reviewed individual performance; agile asks teams to self-organise and Scrum Masters to coach rather than direct. Without clear new roles, middle managers either covertly continue command-and-control (undermining self-organisation) or become disengaged (losing valuable organisational knowledge and support). Successful transformations explicitly redefine middle management's value proposition: removing organisational impediments, career development coaching, and cross-team coordination.

व्याख्या (हिन्दी) यह सबसे प्रलेखित त्वरित परिवर्तन विफलता मोड (मैकिन्से, फोर्ब्स केस स्टडीज) में से एक है। मध्य प्रबंधकों ने पहले कार्य सौंपे और व्यक्तिगत प्रदर्शन की समीक्षा की; एजाइल टीमों को स्वयं-संगठित होने के लिए कहता है और स्क्रम मास्टर्स को निर्देशन के बजाय प्रशिक्षित करने के लिए कहता है। स्पष्ट नई भूमिकाओं के बिना, मध्य प्रबंधक या तो गुप्त रूप से कमांड-एंड-कंट्रोल (स्व-संगठन को कमजोर करना) जारी रखते हैं या अलग हो जाते हैं (मूल्यवान संगठनात्मक ज्ञान और समर्थन खो देते हैं)। सफल परिवर्तन स्पष्ट रूप से मध्य प्रबंधन के मूल्य प्रस्ताव को फिर से परिभाषित करते हैं: संगठनात्मक बाधाओं को दूर करना, कैरियर विकास कोचिंग और क्रॉस-टीम समन्वय।

2685

EN + हिं Easy

GB What is 'agile maturity assessment' and why do simple checklists ('do you do daily standups?') fail to capture true agility?

IN 'फुर्तीली परिपक्वता मूल्यांकन' क्या है और सरल चेकलिस्ट ('क्या आप दैनिक स्टैंडअप करते हैं?') सच्ची चपलता को पकड़ने में क्यों विफल रहती हैं?

A

Checklist-based assessments are the most accurate way to measure agile maturity according to all research सभी शोधों के अनुसार चेकलिस्ट-आधारित आकलन त्वरित परिपक्वता को मापने का सबसे सटीक तरीका है

B

Checklists measure ceremony adoption (doing standups, having a backlog) but not the underlying values and outcomes (responsiveness to change, psychological safety, continuous learning, customer-centricity) — a team can check every box while remaining fundamentally rigid and command-driven (cargo cult agile) चेकलिस्ट समारोह को अपनाने (स्टैंडअप करना, बैकलॉग रखना) को मापते हैं, लेकिन अंतर्निहित मूल्यों और परिणामों (परिवर्तन के प्रति प्रतिक्रिया, मनोवैज्ञानिक सुरक्षा, निरंतर सीखने, ग्राहक-केंद्रितता) को नहीं - एक टीम मौलिक रूप से कठोर और कमांड-संचालित (कार्गो पंथ चुस्त) रहते हुए हर बॉक्स की जांच कर सकती है।

C

Agile maturity cannot be assessed by any method and is purely subjective with no useful measurement approach चंचल परिपक्वता का मूल्यांकन किसी भी विधि से नहीं किया जा सकता है और यह बिना किसी उपयोगी माप दृष्टिकोण के पूरी तरह से व्यक्तिपरक है

D

Agile maturity is solely determined by how many certifications team members hold चंचल परिपक्वता पूरी तरह से इस बात से निर्धारित होती है कि टीम के सदस्यों के पास कितने प्रमाणपत्र हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Cargo cult agile (the term borrowed from Feynman's anecdote about Pacific islanders building fake airport equipment hoping planes would land) describes teams that perform agile rituals without understanding their purpose. Better maturity assessments (Spotify's health check model, Agile Fluency Model) measure outcomes: how quickly can the team respond to a changed priority? Do retrospective action items actually get implemented? Does the team feel safe raising concerns? These outcome-based questions reveal genuine agility that checklists miss.

व्याख्या (हिन्दी) कार्गो पंथ एजाइल (यह शब्द फेनमैन के उस किस्से से लिया गया है जिसमें प्रशांत द्वीपवासियों के बारे में बताया गया है कि वे नकली हवाई अड्डे के उपकरण बना रहे हैं, उम्मीद है कि विमान उतरेंगे) उन टीमों का वर्णन करता है जो अपने उद्देश्य को समझे बिना त्वरित अनुष्ठान करते हैं। बेहतर परिपक्वता आकलन (Spotify का स्वास्थ्य जांच मॉडल, एजाइल फ्लुएंसी मॉडल) परिणामों को मापता है: टीम बदली हुई प्राथमिकता पर कितनी जल्दी प्रतिक्रिया दे सकती है? क्या पूर्वव्यापी कार्रवाई आइटम वास्तव में लागू होते हैं? क्या टीम चिंताएँ व्यक्त करने में सुरक्षित महसूस करती है? ये परिणाम-आधारित प्रश्न वास्तविक चपलता को प्रकट करते हैं जो जाँचकर्ता चूक जाते हैं।

Software Engineering — MCQ Practice