391

EN + हिं Medium

GB Which characteristic of Waterfall makes it well-suited for safety-critical systems like avionics software?

IN वॉटरफॉल की कौन सी विशेषता इसे एवियोनिक्स सॉफ़्टवेयर जैसी सुरक्षा-महत्वपूर्ण प्रणालियों के लिए उपयुक्त बनाती है?

A

Waterfall supports continuous deployment for rapid safety patches झरना तेजी से सुरक्षा पैच के लिए निरंतर तैनाती का समर्थन करता है

B

Its emphasis on comprehensive upfront documentation and phase-gate reviews aligns with regulatory certification requirements like DO-178C व्यापक अग्रिम दस्तावेज़ीकरण और चरण-गेट समीक्षाओं पर इसका जोर डीओ-178सी जैसी नियामक प्रमाणन आवश्यकताओं के अनुरूप है

C

Waterfall allows users to modify requirements during implementation वॉटरफॉल उपयोगकर्ताओं को कार्यान्वयन के दौरान आवश्यकताओं को संशोधित करने की अनुमति देता है

D

Waterfall automatically detects hardware failures during testing परीक्षण के दौरान वॉटरफॉल स्वचालित रूप से हार्डवेयर विफलताओं का पता लगाता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Standards like DO-178C (avionics) and IEC 61508 require extensive traceability and formal review/approval gates. Waterfall's phase structure naturally produces this documented trail, which is why safety-critical industries have historically favoured it.

व्याख्या (हिन्दी) DO-178C (एवियोनिक्स) और IEC 61508 जैसे मानकों के लिए व्यापक ट्रैसेबिलिटी और औपचारिक समीक्षा/अनुमोदन द्वार की आवश्यकता होती है। झरने की चरण संरचना स्वाभाविक रूप से इस दस्तावेजी निशान का निर्माण करती है, यही कारण है कि सुरक्षा-महत्वपूर्ण उद्योगों ने ऐतिहासिक रूप से इसका समर्थन किया है।

392

EN + हिं Easy

GB A project manager uses Waterfall for an e-commerce platform where UI preferences are unknown. What is the most critical flaw?

IN एक प्रोजेक्ट मैनेजर एक ई-कॉमर्स प्लेटफॉर्म के लिए वॉटरफॉल का उपयोग करता है जहां यूआई प्राथमिकताएं अज्ञात हैं। सबसे गंभीर दोष क्या है?

A

Waterfall does not support web-based technologies वॉटरफॉल वेब-आधारित प्रौद्योगिकियों का समर्थन नहीं करता है

B

Waterfall requires complete stable requirements upfront; unknown UI preferences mean requirements will change after implementation, triggering costly rework झरने के लिए पहले से ही पूर्ण स्थिर आवश्यकताओं की आवश्यकता होती है; अज्ञात यूआई प्राथमिकताओं का मतलब है कि कार्यान्वयन के बाद आवश्यकताएं बदल जाएंगी, जिससे महंगा पुनर्कार्य शुरू हो जाएगा

C

Waterfall cannot produce graphical user interfaces वॉटरफ़ॉल ग्राफ़िकल यूज़र इंटरफ़ेस उत्पन्न नहीं कर सकता

D

The e-commerce domain requires agile certification ई-कॉमर्स डोमेन के लिए त्वरित प्रमाणीकरण की आवश्यकता होती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Waterfall's biggest weakness is its inability to gracefully accommodate requirement changes after a phase is complete. For UI-heavy consumer products where usability testing reveals needed changes, this rigidity is fatal.

व्याख्या (हिन्दी) झरने की सबसे बड़ी कमजोरी एक चरण पूरा होने के बाद आवश्यकता परिवर्तनों को खूबसूरती से समायोजित करने में असमर्थता है। यूआई-भारी उपभोक्ता उत्पादों के लिए जहां प्रयोज्य परीक्षण से आवश्यक परिवर्तनों का पता चलता है, यह कठोरता घातक है।

393

EN + हिं Easy

GB What does Royce's original 1970 Waterfall paper actually recommend that many practitioners ignore?

IN रॉयस का मूल 1970 वॉटरफ़ॉल पेपर वास्तव में क्या अनुशंसा करता है जिसे कई चिकित्सक अनदेखा कर देते हैं?

A

Software should be written in COBOL for maximum portability अधिकतम पोर्टेबिलिटी के लिए सॉफ़्टवेयर को COBOL में लिखा जाना चाहिए

B

The Waterfall should include a preliminary iteration before main development, and feedback loops between phases are necessary झरने में मुख्य विकास से पहले एक प्रारंभिक पुनरावृत्ति शामिल होनी चाहिए, और चरणों के बीच फीडबैक लूप आवश्यक हैं

C

All testing should be outsourced to independent QA companies सभी परीक्षण स्वतंत्र QA कंपनियों को आउटसोर्स किए जाने चाहिए

D

Requirements should never be written down, only verbally communicated आवश्यकताओं को कभी भी लिखा नहीं जाना चाहिए, केवल मौखिक रूप से संप्रेषित किया जाना चाहिए

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Royce's 1970 paper actually warned that the simple sequential Waterfall was risky and recommended building a preliminary pilot version first, plus explicitly allowing feedback between adjacent phases. The 'pure' Waterfall that became industry dogma was a misreading.

व्याख्या (हिन्दी) रॉयस के 1970 के पेपर ने वास्तव में चेतावनी दी थी कि सरल अनुक्रमिक झरना जोखिम भरा था और पहले एक प्रारंभिक पायलट संस्करण बनाने की सिफारिश की गई थी, साथ ही आसन्न चरणों के बीच स्पष्ट रूप से प्रतिक्रिया की अनुमति दी गई थी। 'शुद्ध' झरना जो उद्योग की हठधर्मिता बन गया, एक गलत व्याख्या थी।

394

EN + हिं Medium

GB Which Waterfall phase is most commonly associated with the highest rework cost when defects escape it?

IN जब दोष बच जाते हैं तो कौन सा झरना चरण सबसे अधिक पुनः कार्य लागत से जुड़ा होता है?

A

Implementation phase कार्यान्वयन चरण

B

Requirements phase आवश्यकताएँ चरण

C

Integration and Testing phase एकीकरण और परीक्षण चरण

D

System Design phase सिस्टम डिज़ाइन चरण

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Requirements defects are the most expensive to fix when discovered late because they affect every downstream phase. Capers Jones and Boehm documented that fixing a requirements defect in maintenance costs 100–200× more than fixing it during requirements review.

व्याख्या (हिन्दी) देर से पता चलने पर आवश्यकता दोषों को ठीक करना सबसे महंगा होता है क्योंकि वे प्रत्येक डाउनस्ट्रीम चरण को प्रभावित करते हैं। केपर्स जोन्स और बोहेम ने दस्तावेजीकरण किया कि रखरखाव में आवश्यकताओं की खराबी को ठीक करने में आवश्यकताओं की समीक्षा के दौरान इसे ठीक करने की तुलना में 100-200× अधिक खर्च होता है।

395

EN + हिं Medium

GB Why does Waterfall struggle with large multi-team projects despite its structured nature?

IN वाटरफॉल अपनी संरचित प्रकृति के बावजूद बड़ी बहु-टीम परियोजनाओं के साथ संघर्ष क्यों करता है?

A

Large projects require more programming languages than Waterfall supports बड़ी परियोजनाओं के लिए वॉटरफॉल समर्थन की तुलना में अधिक प्रोग्रामिंग भाषाओं की आवश्यकता होती है

B

Integration of subsystems developed in parallel reveals interface mismatches that cannot be detected until the integration phase, causing cascading rework समानांतर में विकसित उपप्रणालियों के एकीकरण से इंटरफ़ेस बेमेल का पता चलता है जिसे एकीकरण चरण तक पता नहीं लगाया जा सकता है, जिससे कैस्केडिंग पुनर्कार्य होता है

C

Waterfall requires all team members to be co-located वॉटरफॉल के लिए टीम के सभी सदस्यों का एक साथ स्थित होना आवश्यक है

D

Waterfall does not support module-level version control वॉटरफ़ॉल मॉड्यूल-स्तरीय संस्करण नियंत्रण का समर्थन नहीं करता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) In large multi-team Waterfall projects, teams design subsystems concurrently based on interface agreements. Interface misunderstandings accumulate invisibly until integration testing, surfacing as a cluster of defects — 'integration hell'.

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

396

EN + हिं Medium

GB What fundamental assumption of Waterfall makes it unsuitable for most modern software projects?

IN वॉटरफॉल की कौन सी मूलभूत धारणा इसे अधिकांश आधुनिक सॉफ्टवेयर परियोजनाओं के लिए अनुपयुक्त बनाती है?

A

All software can be built by a single developer सभी सॉफ़्टवेयर एक ही डेवलपर द्वारा बनाए जा सकते हैं

B

Complete and stable requirements can be elicited and frozen before any design or implementation begins किसी भी डिज़ाइन या कार्यान्वयन के शुरू होने से पहले पूर्ण और स्थिर आवश्यकताओं को प्राप्त और स्थिर किया जा सकता है

C

Testing is unnecessary if design reviews are thorough यदि डिज़ाइन समीक्षाएँ गहन हैं तो परीक्षण अनावश्यक है

D

All software follows the same domain-specific patterns सभी सॉफ़्टवेयर समान डोमेन-विशिष्ट पैटर्न का अनुसरण करते हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Waterfall's fatal assumption is that requirements are fully knowable and stable before development begins. In reality, users rarely know exactly what they want until they see a working system, markets change, and technology evolves — making frozen requirements an impossibility.

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

397

EN + हिं Medium

GB A hospital system using Spiral reveals that real-time data sync is technically infeasible within budget during cycle 3. What should happen?

IN स्पाइरल का उपयोग करने वाली एक अस्पताल प्रणाली से पता चलता है कि चक्र 3 के दौरान बजट के भीतर वास्तविक समय डेटा सिंक तकनीकी रूप से असंभव है। क्या होना चाहिए?

A

Development team must implement it anyway and request a retroactive budget increase विकास दल को इसे वैसे भी लागू करना होगा और पूर्वव्यापी बजट वृद्धि का अनुरोध करना होगा

B

The risk finding should trigger stakeholder negotiation to revise requirement, increase budget, or reduce scope जोखिम खोज को आवश्यकता को संशोधित करने, बजट बढ़ाने या दायरे को कम करने के लिए हितधारक बातचीत को ट्रिगर करना चाहिए

C

Project must restart from cycle one with different technology प्रोजेक्ट को अलग-अलग तकनीक के साथ चक्र एक से पुनः आरंभ करना होगा

D

Spiral requires implementing a workaround even when risks are unacceptable जोखिम अस्वीकार्य होने पर भी स्पाइरल को वर्कअराउंड लागू करने की आवश्यकता होती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) This is exactly the scenario the Spiral model is designed for. Risk analysis revealing infeasibility triggers a formal review with stakeholders who can decide: relax the requirement, increase budget, use a different approach, or cancel.

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

398

EN + हिं Easy

GB What does the Agile Manifesto's 'responding to change over following a plan' specifically NOT mean?

IN एजाइल मेनिफेस्टो के 'योजना का पालन करने के बजाय परिवर्तन पर प्रतिक्रिया' का विशेष रूप से क्या मतलब नहीं है?

A

That planning is unnecessary and teams should work without structure वह योजना अनावश्यक है और टीमों को संरचना के बिना काम करना चाहिए

B

That plans are bad and should be entirely avoided ये योजनाएँ ख़राब हैं और इनसे पूरी तरह बचा जाना चाहिए

C

That teams should abandon plans whenever a member suggests a new idea जब भी कोई सदस्य कोई नया विचार सुझाता है तो टीमों को योजनाएँ छोड़ देनी चाहिए

D

All the above are incorrect interpretations of the Agile value उपरोक्त सभी एजाइल मूल्य की गलत व्याख्याएँ हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) The Agile Manifesto explicitly states it values items on the left MORE, not that items on the right have no value. Planning is still essential in Agile; teams plan differently (short cycles, adaptive replanning) and prioritise adaptability.

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

399

EN + हिं Medium

GB In Scrum, what is the primary purpose of the Sprint Retrospective, and how does it differ from the Sprint Review?

IN स्क्रम में, स्प्रिंट रेट्रोस्पेक्टिव का प्राथमिक उद्देश्य क्या है, और यह स्प्रिंट समीक्षा से कैसे भिन्न है?

A

Sprint Retrospective reviews product increment with customers; Sprint Review assesses team processes स्प्रिंट रेट्रोस्पेक्टिव ग्राहकों के साथ उत्पाद वृद्धि की समीक्षा करता है; स्प्रिंट रिव्यू टीम प्रक्रियाओं का आकलन करता है

B

Sprint Retrospective is an internal team inspection of their working process to identify improvements; Sprint Review demonstrates the increment to stakeholders for product feedback स्प्रिंट रेट्रोस्पेक्टिव सुधारों की पहचान करने के लिए उनकी कार्य प्रक्रिया का एक आंतरिक टीम निरीक्षण है; स्प्रिंट समीक्षा उत्पाद प्रतिक्रिया के लिए हितधारकों की वृद्धि को दर्शाती है

C

Sprint Retrospective updates Sprint Backlog; Sprint Review updates Product Backlog स्प्रिंट पूर्वव्यापी अद्यतन स्प्रिंट बैकलॉग; स्प्रिंट समीक्षा उत्पाद बैकलॉग को अद्यतन करती है

D

Both events serve the same purpose and can be combined दोनों घटनाएँ एक ही उद्देश्य की पूर्ति करती हैं और इन्हें जोड़ा जा सकता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) The Sprint Review is product-focused — showing what was built to stakeholders for feedback. The Sprint Retrospective is process-focused — the team reflects on how they worked and creates improvement plans. Conflating the two undermines both purposes.

व्याख्या (हिन्दी) स्प्रिंट समीक्षा उत्पाद-केंद्रित है - यह दिखाती है कि प्रतिक्रिया के लिए हितधारकों को क्या बनाया गया था। स्प्रिंट रेट्रोस्पेक्टिव प्रक्रिया-केंद्रित है - टीम इस बात पर विचार करती है कि उन्होंने कैसे काम किया और सुधार योजनाएं बनाती हैं। दोनों को मिलाने से दोनों उद्देश्य कमजोर हो जाते हैं।

400

EN + हिं Easy

GB What does 'velocity' in Scrum measure and what is its most critical limitation?

IN स्क्रम में 'वेग' क्या मापता है और इसकी सबसे महत्वपूर्ण सीमा क्या है?

A

Team physical movement between workstations कार्यस्थानों के बीच टीम की शारीरिक गतिविधि

B

Story points completed per sprint; its limitation is team-specificity, non-comparability across teams, and susceptibility to gaming by inflating estimates प्रति स्प्रिंट पूरी की गई कहानी के बिंदु; इसकी सीमा टीम-विशिष्टता, टीमों में गैर-तुलनीयता और अनुमान बढ़ाकर गेमिंग के प्रति संवेदनशीलता है।

C

Number of customer complaints resolved per sprint प्रति स्प्रिंट हल की गई ग्राहक शिकायतों की संख्या

D

Lines of code written per day — an industry-standard metric प्रतिदिन लिखी गई कोड की पंक्तियाँ - एक उद्योग-मानक मीट्रिक

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Velocity (story points per sprint) helps teams forecast future delivery based on historical performance. However story points are relative and team-specific — comparing velocity across teams is meaningless. Velocity can also be gamed when management uses it as a performance target.

व्याख्या (हिन्दी) वेलोसिटी (प्रति स्प्रिंट कहानी बिंदु) टीमों को ऐतिहासिक प्रदर्शन के आधार पर भविष्य की डिलीवरी का पूर्वानुमान लगाने में मदद करती है। हालाँकि कहानी के बिंदु सापेक्ष और टीम-विशिष्ट हैं - टीमों में वेग की तुलना करना अर्थहीन है। जब प्रबंधन इसे प्रदर्शन लक्ष्य के रूप में उपयोग करता है तो वेग से भी खिलवाड़ किया जा सकता है।

401

EN + हिं Medium

GB What is the 'Definition of Done' (DoD) in Scrum and what happens when a team lacks a shared DoD?

IN स्क्रम में 'डन की परिभाषा' (डीओडी) क्या है और जब किसी टीम के पास साझा डीओडी की कमी होती है तो क्या होता है?

A

DoD is the list of features planned for the next sprint DoD अगले स्प्रिंट के लिए नियोजित सुविधाओं की सूची है

B

DoD is the shared standard defining when an increment is complete and shippable; without it different team members have different completion criteria leading to hidden technical debt DoD एक साझा मानक है जो परिभाषित करता है कि वेतन वृद्धि कब पूर्ण और शिप करने योग्य है; इसके बिना अलग-अलग टीम के सदस्यों के पास अलग-अलग पूर्णता मानदंड होते हैं, जिससे छिपे हुए तकनीकी ऋण का सामना करना पड़ता है

C

DoD specifies which developers handle which user stories DoD निर्दिष्ट करता है कि कौन से डेवलपर कौन सी उपयोगकर्ता कहानियों को संभालते हैं

D

DoD is optional; teams can operate effectively without it डीओडी वैकल्पिक है; टीमें इसके बिना प्रभावी ढंग से काम कर सकती हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Without a shared DoD, 'done' means different things to different people, accumulating as undeclared technical debt and making sprint velocity unreliable. The DoD creates transparency about what has truly been completed.

व्याख्या (हिन्दी) साझा DoD के बिना, 'किया गया' का अलग-अलग लोगों के लिए अलग-अलग मतलब होता है, जो अघोषित तकनीकी ऋण के रूप में जमा होता है और स्प्रिंट वेग को अविश्वसनीय बनाता है। DoD वास्तव में जो पूरा हो चुका है उसके बारे में पारदर्शिता बनाता है।

402

EN + हिं Easy

GB What is the 'cone of uncertainty' in agile estimation and what does it imply for release planning?

IN त्वरित अनुमान में 'अनिश्चितता का शंकु' क्या है और रिलीज़ योजना के लिए इसका क्या अर्थ है?

A

Physical area where developers can work without distractions भौतिक क्षेत्र जहां डेवलपर्स बिना ध्यान भटकाए काम कर सकते हैं

B

Project estimation uncertainty is highest at the start and narrows as the project progresses — early release commitments will have large uncertainty ranges परियोजना अनुमान की अनिश्चितता शुरुआत में सबसे अधिक होती है और जैसे-जैसे परियोजना आगे बढ़ती है, यह कम होती जाती है - प्रारंभिक रिलीज प्रतिबद्धताओं में अनिश्चितता की बड़ी सीमाएँ होंगी

C

Maximum team size beyond which Agile methods become ineffective अधिकतम टीम आकार जिसके आगे एजाइल विधियां अप्रभावी हो जाती हैं

D

Period between Sprint Planning and Sprint execution स्प्रिंट योजना और स्प्रिंट निष्पादन के बीच की अवधि

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) The Cone of Uncertainty shows initial estimates can vary by 4× in either direction. As design and implementation proceed, the range narrows. Agile teams address this by providing range estimates rather than point estimates and refining each sprint.

व्याख्या (हिन्दी) अनिश्चितता का शंकु दर्शाता है कि प्रारंभिक अनुमान किसी भी दिशा में 4× भिन्न हो सकते हैं। जैसे-जैसे डिज़ाइन और कार्यान्वयन आगे बढ़ता है, दायरा कम होता जाता है। फुर्तीली टीमें बिंदु अनुमान के बजाय सीमा अनुमान प्रदान करके और प्रत्येक स्प्रिंट को परिष्कृत करके इसका समाधान करती हैं।

403

EN + हिं Easy

GB In Kanban, what is a WIP limit and what systemic problem does it solve?

IN कानबन में, WIP सीमा क्या है और यह किस प्रणालीगत समस्या का समाधान करती है?

A

WIP limits restrict number of developers in the office at any time WIP सीमाएं किसी भी समय कार्यालय में डेवलपर्स की संख्या को सीमित करती हैं

B

WIP limits cap items in each workflow stage, exposing bottlenecks and preventing work piling up faster than it can be completed — solving multitasking overload and hidden queuing delays WIP प्रत्येक वर्कफ़्लो चरण में कैप आइटम को सीमित करता है, बाधाओं को उजागर करता है और काम को पूरा होने की तुलना में तेजी से जमा होने से रोकता है - मल्टीटास्किंग अधिभार और छिपी हुई कतार में देरी को हल करता है

C

WIP limits define maximum story point value for a single user story WIP सीमाएँ एकल उपयोगकर्ता कहानी के लिए अधिकतम कहानी बिंदु मान को परिभाषित करती हैं

D

WIP limits ensure only senior developers work on critical path items WIP सीमाएँ सुनिश्चित करती हैं कि केवल वरिष्ठ डेवलपर ही महत्वपूर्ण पथ आइटम पर काम करें

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) WIP limits are Kanban's core flow optimisation mechanism. When a stage hits its WIP limit, upstream workers must stop and help clear the bottleneck rather than adding more work — revealing systemic constraints per Little's Law and reducing context switching.

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

404

EN + हिं Medium

GB What is the critical difference between SAFe and LeSS in scaling Agile across multiple teams?

IN कई टीमों में एजाइल को बढ़ाने में SAFe और LeSS के बीच महत्वपूर्ण अंतर क्या है?

A

SAFe only works for software companies; LeSS for all industries SAFe केवल सॉफ्टवेयर कंपनियों के लिए काम करता है; सभी उद्योगों के लिए एलईएसएस

B

SAFe adds prescriptive structure (Program Increments, ARTs, hierarchical roles) to coordinate large organisations; LeSS deliberately minimises additional structure, preserving Scrum's simplicity through team self-organisation SAFe बड़े संगठनों के समन्वय के लिए निर्देशात्मक संरचना (कार्यक्रम वृद्धि, एआरटी, पदानुक्रमित भूमिकाएं) जोड़ता है; LeSS जानबूझकर अतिरिक्त संरचना को कम करता है, टीम स्व-संगठन के माध्यम से स्क्रम की सादगी को संरक्षित करता है

C

SAFe uses 3-month sprints; LeSS uses 1-week sprints SAFe 3 महीने की स्प्रिंट का उपयोग करता है; LeSS 1-सप्ताह की स्प्रिंट का उपयोग करता है

D

Both are identical differing only in ceremony terminology दोनों समान हैं, केवल समारोह शब्दावली में अंतर है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) SAFe addresses enterprise scaling through formal structure — Program and Solution levels, Agile Release Trains, PI Planning. Critics argue this re-introduces bureaucracy. LeSS keeps Scrum intact and scales by having fewer larger feature teams sharing a single product backlog.

व्याख्या (हिन्दी) SAFe औपचारिक संरचना के माध्यम से उद्यम स्केलिंग को संबोधित करता है - कार्यक्रम और समाधान स्तर, एजाइल रिलीज़ ट्रेनें, पीआई योजना। आलोचकों का तर्क है कि यह नौकरशाही को फिर से प्रस्तुत करता है। LeSS एकल उत्पाद बैकलॉग को साझा करने वाली कम बड़ी फीचर टीमों के द्वारा स्क्रम को बरकरार रखता है और स्केल करता है।

405

EN + हिं Easy

GB What is 'continuous integration' in Agile development and what specific failure mode does it prevent?

IN एजाइल विकास में 'निरंतर एकीकरण' क्या है और यह किस विशिष्ट विफलता मोड को रोकता है?

A

Integrating new team members without formal onboarding औपचारिक ऑनबोर्डिंग के बिना नई टीम के सदस्यों को एकीकृत करना

B

Merging developers' code into a shared repository frequently with automated build/test verification — preventing 'integration hell' where long-lived branches diverge so far that merging becomes extremely complex स्वचालित बिल्ड/परीक्षण सत्यापन के साथ डेवलपर्स के कोड को एक साझा रिपॉजिटरी में बार-बार मर्ज करना - 'एकीकरण नरक' को रोकना जहां लंबे समय तक रहने वाली शाखाएं इतनी दूर तक अलग हो जाती हैं कि विलय बेहद जटिल हो जाता है

C

A deployment strategy releasing new features to users automatically without testing एक परिनियोजन रणनीति बिना परीक्षण के उपयोगकर्ताओं को स्वचालित रूप से नई सुविधाएँ जारी करती है

D

Integrating customer feedback sessions into the development calendar विकास कैलेंडर में ग्राहक प्रतिक्रिया सत्रों को एकीकृत करना

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) CI prevents 'integration hell' — the painful experience of merging months of parallel development where teams have made incompatible changes. By integrating frequently with automated tests, conflicts are detected within hours of introduction when the context is fresh.

व्याख्या (हिन्दी) सीआई 'एकीकरण नरक' को रोकता है - समानांतर विकास के महीनों के विलय का दर्दनाक अनुभव जहां टीमों ने असंगत परिवर्तन किए हैं। स्वचालित परीक्षणों के साथ बार-बार एकीकरण करके, संदर्भ ताज़ा होने पर परिचय के कुछ घंटों के भीतर विरोधों का पता लगाया जाता है।

Software Engineering — MCQ Practice