2401

EN + हिं Medium

GB How does the Spiral model handle the scenario where risk analysis determines a project should be cancelled?

IN स्पाइरल मॉडल उस परिदृश्य को कैसे संभालता है जहां जोखिम विश्लेषण यह निर्धारित करता है कि किसी परियोजना को रद्द कर दिया जाना चाहिए?

A

Spiral model does not allow project cancellation स्पाइरल मॉडल प्रोजेक्ट रद्द करने की अनुमति नहीं देता है

B

Cancellation is an explicit legitimate outcome after risk analysis — stopping a high-risk unviable project is treated as success जोखिम विश्लेषण के बाद रद्दीकरण एक स्पष्ट वैध परिणाम है - एक उच्च जोखिम वाली अव्यवहार्य परियोजना को रोकना सफलता के रूप में माना जाता है

C

Cancellation requires board approval outside the Spiral process रद्दीकरण के लिए स्पाइरल प्रक्रिया के बाहर बोर्ड की मंजूरी की आवश्यकता होती है

D

Spiral escalates to Waterfall mode if cancellation criteria are met यदि रद्दीकरण मानदंड पूरे होते हैं तो स्पाइरल वॉटरफॉल मोड में बढ़ जाता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) One of Spiral's most underappreciated features is that it formally recognises project cancellation as valid. If risk analysis reveals the project cannot achieve acceptable risk levels within budget, cancelling is the correct decision — saving further wasted investment.

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

2402

EN + हिं Medium

GB What is 'risk-driven prototyping' in the Spiral model, and how does it differ from requirements-driven prototyping?

IN स्पाइरल मॉडल में 'जोखिम-संचालित प्रोटोटाइप' क्या है, और यह आवश्यकताओं-संचालित प्रोटोटाइप से कैसे भिन्न है?

A

Risk-driven builds entire system first; requirements-driven builds only UI mockups जोखिम-संचालित पहले संपूर्ण सिस्टम का निर्माण करता है; आवश्यकताओं-संचालित केवल यूआई मॉकअप बनाता है

B

Risk-driven targets highest-risk unknowns to resolve them; requirements-driven builds prototypes to elicit and clarify user requirements जोखिम-संचालित लक्ष्य उच्चतम-जोखिम वाले अज्ञात लोगों को हल करने के लिए; आवश्यकताओं-संचालित उपयोगकर्ता की आवश्यकताओं को जानने और स्पष्ट करने के लिए प्रोटोटाइप बनाता है

C

Risk-driven uses formal mathematical proofs; requirements-driven uses informal walkthroughs जोखिम-संचालित औपचारिक गणितीय प्रमाणों का उपयोग करता है; आवश्यकता-संचालित अनौपचारिक वॉकथ्रू का उपयोग करता है

D

Both terms describe the same activity दोनों शब्द एक ही गतिविधि का वर्णन करते हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) In the Spiral model, prototypes are built to resolve highest-priority risks — not just to clarify requirements. A risk might be technical (can we achieve required performance?) or algorithmic. This differs from exploratory prototyping where the goal is requirements elicitation.

व्याख्या (हिन्दी) स्पाइरल मॉडल में, प्रोटोटाइप सर्वोच्च-प्राथमिकता वाले जोखिमों को हल करने के लिए बनाए जाते हैं - न कि केवल आवश्यकताओं को स्पष्ट करने के लिए। जोखिम तकनीकी हो सकता है (क्या हम आवश्यक प्रदर्शन प्राप्त कर सकते हैं?) या एल्गोरिथम। यह खोजपूर्ण प्रोटोटाइप से भिन्न है जहां लक्ष्य आवश्यकताओं को प्राप्त करना है।

2403

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.

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

2404

EN + हिं Medium

GB Why is the Spiral model considered a 'meta-model' rather than just another process model?

IN स्पाइरल मॉडल को केवल एक अन्य प्रक्रिया मॉडल के बजाय 'मेटा-मॉडल' क्यों माना जाता है?

A

It was designed to model other software process models, not actual software इसे अन्य सॉफ़्टवेयर प्रक्रिया मॉडल को मॉडल करने के लिए डिज़ाइन किया गया था, वास्तविक सॉफ़्टवेयर के लिए नहीं

B

It can accommodate other process models (Waterfall, Incremental, Prototyping) within its framework, selecting the appropriate approach for each cycle based on risk यह जोखिम के आधार पर प्रत्येक चक्र के लिए उपयुक्त दृष्टिकोण का चयन करते हुए, अपने ढांचे के भीतर अन्य प्रक्रिया मॉडल (वाटरफॉल, इंक्रीमेंटल, प्रोटोटाइपिंग) को समायोजित कर सकता है।

C

It requires formal mathematical specifications before any development किसी भी विकास से पहले इसे औपचारिक गणितीय विशिष्टताओं की आवश्यकता होती है

D

It combines UML modelling with runtime process execution traces यह यूएमएल मॉडलिंग को रनटाइम प्रक्रिया निष्पादन ट्रेस के साथ जोड़ता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Boehm called the Spiral a meta-model because it does not mandate a specific development approach. Its risk-driven framework can envelope other models: if risks show requirements are stable, use Waterfall; if unclear, use prototyping.

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

2405

EN + हिं Easy

GB What are 'anchor point milestones' in Boehm's Win-Win Spiral model?

IN बोहेम के विन-विन स्पाइरल मॉडल में 'एंकर प्वाइंट मील के पत्थर' क्या हैं?

A

Mandatory security audits at fixed calendar intervals निश्चित कैलेंडर अंतराल पर अनिवार्य सुरक्षा ऑडिट

B

Defined checkpoints where stakeholders review and agree on progress, risk status, and commitment to proceed — specifically LCO, LCA, and IOC परिभाषित चौकियाँ जहाँ हितधारक प्रगति, जोखिम की स्थिति और आगे बढ़ने की प्रतिबद्धता की समीक्षा करते हैं और सहमत होते हैं - विशेष रूप से एलसीओ, एलसीए और आईओसी

C

Hardware benchmarks to evaluate the deployment platform परिनियोजन प्लेटफ़ॉर्म का मूल्यांकन करने के लिए हार्डवेयर बेंचमार्क

D

Automated test suite checkpoints before each spiral cycle प्रत्येक सर्पिल चक्र से पहले स्वचालित परीक्षण सूट चौकियाँ

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Boehm's Win-Win Spiral introduced anchor point milestones as formal decision gates: LCO validates scope/approach; LCA validates architecture stability; IOC validates readiness for deployment. These prevent the spiral from continuing without explicit stakeholder commitment.

व्याख्या (हिन्दी) बोहेम के विन-विन स्पाइरल ने औपचारिक निर्णय द्वार के रूप में एंकर पॉइंट मील के पत्थर पेश किए: एलसीओ दायरे/दृष्टिकोण को मान्य करता है; एलसीए वास्तुकला स्थिरता को मान्य करता है; आईओसी तैनाती के लिए तैयारी की पुष्टि करता है। ये स्पष्ट हितधारक प्रतिबद्धता के बिना सर्पिल को जारी रखने से रोकते हैं।

2406

EN + हिं Medium

GB A team discovers mid-Spiral that a critical third-party API has been deprecated. How does the Spiral model's structure specifically help?

IN एक टीम को मध्य-सर्पिल में पता चलता है कि एक महत्वपूर्ण तृतीय-पक्ष एपीआई को हटा दिया गया है। स्पाइरल मॉडल की संरचना विशेष रूप से कैसे मदद करती है?

A

Spiral automatically selects an alternative API स्पाइरल स्वचालित रूप से एक वैकल्पिक एपीआई का चयन करता है

B

The risk discovery triggers an explicit risk resolution phase where alternatives are evaluated before committing to the next iteration जोखिम की खोज एक स्पष्ट जोखिम समाधान चरण को ट्रिगर करती है जहां अगले पुनरावृत्ति के लिए प्रतिबद्ध होने से पहले विकल्पों का मूल्यांकन किया जाता है

C

Team must roll back to previous cycle and restart with different technology टीम को पिछले चक्र में वापस जाना होगा और विभिन्न तकनीक के साथ पुनः आरंभ करना होगा

D

Spiral flags this as project failure and recommends termination स्पाइरल ने इसे परियोजना विफलता के रूप में चिह्नित किया और समाप्ति की सिफारिश की

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Risk analysis in the Spiral model surfaces exactly this type of dependency risk early. When identified, the model mandates resolving it before proceeding — preventing the team from discovering the problem deep in implementation when switching approaches would be far more expensive.

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

2407

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.

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

2408

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.

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

2409

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.

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

2410

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 वास्तव में जो पूरा हो चुका है उसके बारे में पारदर्शिता बनाता है।

2411

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× भिन्न हो सकते हैं। जैसे-जैसे डिज़ाइन और कार्यान्वयन आगे बढ़ता है, दायरा कम होता जाता है। फुर्तीली टीमें बिंदु अनुमान के बजाय सीमा अनुमान प्रदान करके और प्रत्येक स्प्रिंट को परिष्कृत करके इसका समाधान करती हैं।

2412

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

2413

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 एकल उत्पाद बैकलॉग को साझा करने वाली कम बड़ी फीचर टीमों के द्वारा स्क्रम को बरकरार रखता है और स्केल करता है।

2414

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.

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

2415

EN + हिं Medium

GB In XP, what is the purpose of pair programming and what does research indicate about its productivity impact?

IN एक्सपी में, जोड़ी प्रोग्रामिंग का उद्देश्य क्या है और अनुसंधान इसके उत्पादकता प्रभाव के बारे में क्या संकेत देता है?

A

Doubles productivity by having two developers work independently in parallel दो डेवलपर्स के समानांतर में स्वतंत्र रूप से काम करने से उत्पादकता दोगुनी हो जाती है

B

Two developers share one workstation — driver writes, navigator reviews real-time; research shows 15% overhead but significantly fewer defects, reducing total project cost दो डेवलपर्स एक वर्कस्टेशन साझा करते हैं - ड्राइवर लिखता है, नेविगेटर वास्तविक समय में समीक्षा करता है; शोध से पता चलता है कि 15% ओवरहेड है लेकिन काफी कम दोष हैं, जिससे कुल परियोजना लागत कम हो गई है

C

Requires two developers to independently implement same feature and choose the better one एक ही सुविधा को स्वतंत्र रूप से लागू करने और बेहतर को चुनने के लिए दो डेवलपर्स की आवश्यकता होती है

D

Only used for debugging; normal development is always solo in XP केवल डिबगिंग के लिए उपयोग किया जाता है; XP में सामान्य विकास हमेशा एकल होता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Pair programming (Williams et al.) shows approximately 15% time overhead but 15–50% fewer defects. Since defect repair is the largest cost driver, the net economics are typically positive — with additional benefits of knowledge sharing and reduced bus factor.

व्याख्या (हिन्दी) जोड़ी प्रोग्रामिंग (विलियम्स एट अल.) लगभग 15% समय ओवरहेड लेकिन 15-50% कम दोष दिखाता है। चूंकि दोष की मरम्मत सबसे बड़ी लागत चालक है, इसलिए शुद्ध अर्थशास्त्र आम तौर पर सकारात्मक है - ज्ञान साझा करने के अतिरिक्त लाभ और कम बस कारक के साथ।

Software Engineering — MCQ Practice