2626

EN + हिं Easy

GB What is 'software architecture documentation' and what does the 4+1 view model address?

IN 'सॉफ़्टवेयर आर्किटेक्चर दस्तावेज़ीकरण' क्या है और 4+1 व्यू मॉडल का पता क्या है?

A

4+1 view model creates four backup copies of the architecture document plus one master copy 4+1 व्यू मॉडल आर्किटेक्चर दस्तावेज़ की चार बैकअप प्रतियां और एक मास्टर कॉपी बनाता है

B

Kruchten's 4+1 view model documents architecture from five stakeholder perspectives: Logical (classes, components), Process (concurrency, threads), Development (source organisation, build), Physical (deployment, servers), + Use cases (scenarios tying the four views together) क्रुचटेन का 4+1 दृश्य मॉडल पांच हितधारक दृष्टिकोणों से वास्तुकला का दस्तावेजीकरण करता है: तार्किक (वर्ग, घटक), प्रक्रिया (समवर्ती, धागे), विकास (स्रोत संगठन, निर्माण), भौतिक (तैनाती, सर्वर), + उपयोग के मामले (चार विचारों को एक साथ जोड़ने वाले परिदृश्य)

C

4+1 model is only used for documenting database schemas, not software architecture 4+1 मॉडल का उपयोग केवल डेटाबेस स्कीमा के दस्तावेज़ीकरण के लिए किया जाता है, सॉफ़्टवेयर आर्किटेक्चर के लिए नहीं

D

4+1 view model requires all five views to be simultaneously maintained at the same level of detail 4+1 दृश्य मॉडल के लिए सभी पांच दृश्यों को एक साथ विवरण के समान स्तर पर बनाए रखने की आवश्यकता होती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Different stakeholders need different architectural views: end users need the logical view (what the system does); developers need the development view (how to organise code); system integrators need the physical view (where things run); QA needs the process view (concurrency behaviour). Use cases tie all four together as concrete cross-cutting scenarios. The 4+1 model prevents documentation that serves only one audience while leaving others without necessary information.

व्याख्या (हिन्दी) विभिन्न हितधारकों को अलग-अलग वास्तुशिल्प विचारों की आवश्यकता होती है: अंतिम उपयोगकर्ताओं को तार्किक दृष्टिकोण की आवश्यकता होती है (सिस्टम क्या करता है); डेवलपर्स को विकास दृश्य की आवश्यकता है (कोड को कैसे व्यवस्थित करें); सिस्टम इंटीग्रेटर्स को भौतिक दृश्य (जहां चीजें चलती हैं) की आवश्यकता होती है; QA को प्रक्रिया दृश्य (समवर्ती व्यवहार) की आवश्यकता है। उपयोग के मामले इन चारों को ठोस क्रॉस-कटिंग परिदृश्यों के रूप में एक साथ जोड़ते हैं। 4+1 मॉडल उन दस्तावेज़ों को रोकता है जो केवल एक दर्शक को सेवा प्रदान करते हैं जबकि अन्य को आवश्यक जानकारी के बिना छोड़ देते हैं।

2627

EN + हिं Easy

GB What is 'software cost estimation' and why do most software projects consistently underestimate?

IN 'सॉफ़्टवेयर लागत अनुमान' क्या है और अधिकांश सॉफ़्टवेयर परियोजनाएँ लगातार कम क्यों आंकी जाती हैं?

A

Software projects underestimate because developers deliberately lie to management about effort सॉफ़्टवेयर प्रोजेक्ट को कम आंका जाता है क्योंकि डेवलपर जानबूझकर प्रयास के बारे में प्रबंधन से झूठ बोलते हैं

B

Cost estimation predicts effort, schedule, and resources needed; underestimation is driven by: optimism bias (planning fallacy), omitting activities (testing, documentation, meetings), unclear requirements at estimation time, political pressure to win contracts, and the cone of uncertainty being ignored लागत का अनुमान प्रयास, कार्यक्रम और आवश्यक संसाधनों की भविष्यवाणी करता है; कम आकलन इसके द्वारा प्रेरित होता है: आशावाद पूर्वाग्रह (योजना की भ्रांति), गतिविधियों को छोड़ना (परीक्षण, दस्तावेज़ीकरण, बैठकें), अनुमान के समय अस्पष्ट आवश्यकताएं, अनुबंध जीतने के लिए राजनीतिक दबाव, और अनिश्चितता के शंकु को नजरअंदाज किया जाना

C

Underestimation only occurs in government projects due to bureaucratic planning processes नौकरशाही नियोजन प्रक्रियाओं के कारण केवल सरकारी परियोजनाओं में कम आकलन होता है

D

Software estimation is inherently impossible and all estimates are equally unreliable सॉफ़्टवेयर अनुमान स्वाभाविक रूप से असंभव है और सभी अनुमान समान रूप से अविश्वसनीय हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Kahneman's planning fallacy (optimism bias) is empirically documented: people systematically underestimate completion time while being accurate about others' similar tasks. Software-specific causes: requirements are incomplete at estimation time, integration and testing effort is systematically underestimated, non-development work (meetings, reviews, documentation) is forgotten. CHAOS Report data (Standish Group) consistently shows ~50% of projects overrun their original estimates.

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

2628

EN + हिं Easy

GB What is 'agile scaling challenge' and what specific problems arise when applying Scrum to a 200-developer programme?

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

A

Agile scaling challenges are only technical; organisational factors are irrelevant at scale तीव्र स्केलिंग चुनौतियाँ केवल तकनीकी हैं; संगठनात्मक कारक बड़े पैमाने पर अप्रासंगिक हैं

B

Scrum at 200+ developers faces: dependency management across 20+ teams, synchronisation overhead (Scrum of Scrums coordination), architectural alignment (preventing Conway's Law fragmentation), release coordination (all teams must be shippable simultaneously), and cultural resistance from middle management whose roles are disrupted 200+ डेवलपर्स पर स्क्रम का सामना: 20+ टीमों में निर्भरता प्रबंधन, सिंक्रनाइज़ेशन ओवरहेड (स्क्रम्स समन्वय का स्क्रम), वास्तुशिल्प संरेखण (कॉनवे के कानून विखंडन को रोकना), रिलीज समन्वय (सभी टीमों को एक साथ शिप करने योग्य होना चाहिए), और मध्य प्रबंधन से सांस्कृतिक प्रतिरोध जिनकी भूमिकाएं बाधित हैं

C

Scrum scales perfectly to any team size without modification as long as sprints remain 2 weeks जब तक स्प्रिंट 2 सप्ताह तक रहता है तब तक स्क्रम बिना किसी संशोधन के किसी भी टीम के आकार के लिए पूरी तरह से स्केल करता है

D

200-developer programmes always use Waterfall; Agile is only for teams under 20 people 200-डेवलपर प्रोग्राम हमेशा वॉटरफॉल का उपयोग करते हैं; एजाइल केवल 20 लोगों से कम उम्र की टीमों के लिए है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) SAFe, LeSS, Nexus, and Scrum@Scale all address these scaling problems differently. The core challenges: inter-team dependencies create sprint impediments that individual teams cannot resolve; architectural decisions made by one team cascade to others; 'done' for the programme requires all teams ready to ship simultaneously; middle management roles (project managers, functional managers) become redundant in agile, creating resistance that must be managed explicitly.

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

2629

EN + हिं Easy

GB What is 'hybrid process model' and when is it more appropriate than a pure agile or pure plan-driven approach?

IN 'हाइब्रिड प्रक्रिया मॉडल' क्या है और यह कब शुद्ध चुस्त या शुद्ध योजना-संचालित दृष्टिकोण से अधिक उपयुक्त है?

A

Hybrid models are always inferior to pure approaches because they lack clear methodology हाइब्रिड मॉडल हमेशा शुद्ध दृष्टिकोण से कमतर होते हैं क्योंकि उनमें स्पष्ट कार्यप्रणाली का अभाव होता है

B

Hybrid models combine elements from different process models tailored to specific project characteristics — appropriate when part of the system has stable requirements (use plan-driven phases for architecture/safety-critical components) while other parts have volatile requirements (use agile for UI/features) हाइब्रिड मॉडल विशिष्ट परियोजना विशेषताओं के अनुरूप विभिन्न प्रक्रिया मॉडल से तत्वों को जोड़ते हैं - उपयुक्त जब सिस्टम के हिस्से में स्थिर आवश्यकताएं होती हैं (आर्किटेक्चर/सुरक्षा-महत्वपूर्ण घटकों के लिए योजना-संचालित चरणों का उपयोग करें) जबकि अन्य भागों में अस्थिर आवश्यकताएं होती हैं (यूआई/सुविधाओं के लिए एजाइल का उपयोग करें)

C

Hybrid models are only used in organisations that cannot commit to a single methodology हाइब्रिड मॉडल का उपयोग केवल उन संगठनों में किया जाता है जो किसी एक पद्धति के लिए प्रतिबद्ध नहीं हो सकते

D

Hybrid models require separate teams for each methodology component, doubling staffing costs हाइब्रिड मॉडल में प्रत्येक कार्यप्रणाली घटक के लिए अलग-अलग टीमों की आवश्यकता होती है, जिससे स्टाफिंग लागत दोगुनी हो जाती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Real-world example: a medical device project uses formal methods and Waterfall for safety-critical embedded firmware (regulatory requirement), while the companion mobile app uses Scrum for its evolving user experience. Forcing one methodology on both produces worse outcomes — Waterfall applied to UI creates irrelevant designs; Agile applied to firmware creates unacceptable regulatory risk.

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

2630

EN + हिं Medium

GB What is the 'executable specification' approach and how does it change the role of requirements documents?

IN 'निष्पादन योग्य विशिष्टता' दृष्टिकोण क्या है और यह आवश्यकता दस्तावेजों की भूमिका को कैसे बदलता है?

A

Executable specifications are UML class diagrams that generate database schemas निष्पादन योग्य विनिर्देश यूएमएल वर्ग आरेख हैं जो डेटाबेस स्कीमा उत्पन्न करते हैं

B

Executable specifications express requirements as runnable tests (BDD scenarios, acceptance tests) — changing the role of requirements documents from static text to living documentation that is simultaneously a specification, a test suite, and proof of implementation correctness निष्पादन योग्य विनिर्देश आवश्यकताओं को चलाने योग्य परीक्षणों (बीडीडी परिदृश्यों, स्वीकृति परीक्षणों) के रूप में व्यक्त करते हैं - आवश्यकताओं के दस्तावेज़ों की भूमिका को स्थिर पाठ से जीवित दस्तावेज़ में बदलना जो एक साथ एक विनिर्देश, एक परीक्षण सूट और कार्यान्वयन शुद्धता का प्रमाण है

C

Executable specifications replace all software development — no additional coding is needed निष्पादन योग्य विनिर्देश सभी सॉफ़्टवेयर विकास को प्रतिस्थापित करते हैं - किसी अतिरिक्त कोडिंग की आवश्यकता नहीं है

D

Executable specifications are only valid in functional programming languages like Haskell निष्पादन योग्य विनिर्देश केवल हास्केल जैसी कार्यात्मक प्रोग्रामिंग भाषाओं में मान्य हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Tools like Cucumber (Ruby/Java), Behave (Python), and SpecFlow (C#) enable Given-When-Then scenarios to be simultaneously: business-readable requirements, automated acceptance tests, and regression safeguards. When requirements change, the failing tests immediately signal which implementation needs updating — eliminating the traditional disconnect between requirements documents and implementation.

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

2631

EN + हिं Easy

GB What is the 'dual-track agile' development model and what problem does it address?

IN 'डुअल-ट्रैक एजाइल' विकास मॉडल क्या है और यह किस समस्या का समाधान करता है?

A

Dual-track agile runs two separate agile teams on the same product simultaneously डुअल-ट्रैक एजाइल एक ही उत्पाद पर दो अलग-अलग एजाइल टीमों को एक साथ चलाता है

B

Dual-track agile runs a discovery track (UX research, prototyping, user testing to validate ideas) parallel to a delivery track (engineering sprints building validated features) — addressing the problem of building features without validating they're the right features to build डुअल-ट्रैक एजाइल एक डिलीवरी ट्रैक के समानांतर एक डिस्कवरी ट्रैक (यूएक्स रिसर्च, प्रोटोटाइपिंग, विचारों को मान्य करने के लिए उपयोगकर्ता परीक्षण) चलाता है (इंजीनियरिंग स्प्रिंट मान्य सुविधाओं का निर्माण करता है) - सत्यापन किए बिना सुविधाओं के निर्माण की समस्या का समाधान करना कि वे निर्माण के लिए सही विशेषताएं हैं

C

Dual-track agile is identical to SAFe's Program Increment planning model डुअल-ट्रैक एजाइल SAFe के प्रोग्राम इंक्रीमेंट प्लानिंग मॉडल के समान है

D

Dual-track agile doubles the cost of development and is only viable for well-funded startups डुअल-ट्रैक एजाइल विकास की लागत को दोगुना कर देता है और यह केवल अच्छी तरह से वित्त पोषित स्टार्टअप के लिए व्यवहार्य है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Without discovery, teams build based on assumptions about what users need — leading to technically correct but user-rejected features. Dual-track (Jeff Gothelf, Josh Seiden) ensures the discovery track stays 1-2 sprints ahead of delivery, validating feature ideas through lightweight user research before committing engineering resources to build them. This prevents the most expensive failure mode: building the wrong product.

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

2632

EN + हिं Medium

GB What is 'evolutionary prototyping' and how does it differ from 'throwaway prototyping'?

IN 'विकासवादी प्रोटोटाइप' क्या है और यह 'थ्रोअवे प्रोटोटाइप' से कैसे भिन्न है?

A

Evolutionary prototyping uses more advanced tools than throwaway prototyping विकासवादी प्रोटोटाइप थ्रोअवे प्रोटोटाइप की तुलना में अधिक उन्नत उपकरणों का उपयोग करता है

B

Evolutionary prototyping builds a prototype with the intention of continuously evolving it into the final system; throwaway prototyping builds a quick-and-dirty prototype solely to elicit requirements, then discards it and rebuilds properly — evolutionary carries architectural risk if not carefully managed विकासवादी प्रोटोटाइप एक प्रोटोटाइप को अंतिम प्रणाली में लगातार विकसित करने के इरादे से बनाता है; थ्रोअवे प्रोटोटाइप पूरी तरह से आवश्यकताओं को पूरा करने के लिए एक त्वरित और गंदा प्रोटोटाइप बनाता है, फिर इसे त्याग देता है और ठीक से पुनर्निर्माण करता है - यदि सावधानी से प्रबंधित नहीं किया जाता है तो विकासवादी वास्तुशिल्प जोखिम उठाता है

C

Both types produce identical system quality outcomes; the choice is purely about timeline preferences दोनों प्रकार समान सिस्टम गुणवत्ता परिणाम उत्पन्न करते हैं; चुनाव पूरी तरह से समयरेखा प्राथमिकताओं के बारे में है

D

Throwaway prototyping is illegal in safety-critical systems; evolutionary prototyping is always required सुरक्षा-महत्वपूर्ण प्रणालियों में थ्रोअवे प्रोटोटाइपिंग अवैध है; विकासवादी प्रोटोटाइप की हमेशा आवश्यकता होती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Evolutionary prototyping risk: the prototype is built quickly with expedient shortcuts; if it 'works well enough', pressure mounts to ship it. The result is a production system built on throwaway-quality foundations. Managing this requires discipline: treat the evolving prototype as production code from the start, applying refactoring and quality practices. Throwaway prototyping avoids this risk by explicitly committing to discarding the prototype.

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

2633

EN + हिं Easy

GB What is the 'agile manifesto's fourth value' ('customer collaboration over contract negotiation') and what contractual mechanism supports it?

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

A

The fourth value eliminates all contracts between customers and development organisations चौथा मान ग्राहकों और विकास संगठनों के बीच सभी अनुबंधों को समाप्त कर देता है

B

The value prioritises ongoing customer collaboration over rigid contract terms — supported by time-and-materials or outcome-based contracts that allow scope to evolve, rather than fixed-price fixed-scope contracts that make change adversarial मूल्य कठोर अनुबंध शर्तों पर चल रहे ग्राहक सहयोग को प्राथमिकता देता है - समय-और-सामग्री या परिणाम-आधारित अनुबंधों द्वारा समर्थित जो निश्चित-मूल्य निश्चित-स्कोप अनुबंधों के बजाय गुंजाइश विकसित करने की अनुमति देता है जो परिवर्तन को प्रतिकूल बनाता है

C

The fourth value requires customers to be employed directly by the development company चौथे मूल्य के लिए ग्राहकों को विकास कंपनी द्वारा सीधे नियोजित किया जाना आवश्यक है

D

Customer collaboration is only possible in co-located teams; remote teams cannot practise this value ग्राहक सहयोग केवल सह-स्थित टीमों में ही संभव है; दूरस्थ टीमें इस मान का अभ्यास नहीं कर सकतीं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Fixed-price fixed-scope contracts make every requirement change a legal dispute between customer and supplier — incentivising adversarial relationships. Time-and-materials contracts align interests: both parties benefit from getting the right product built efficiently. Outcome-based contracts take this further: payment tied to business outcomes (revenue generated, cost saved) rather than deliverables, fully aligning development with business success.

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

2634

EN + हिं Medium

GB What is the 'safe-to-fail experiment' concept in complex adaptive systems and how does it apply to software product development?

IN जटिल अनुकूली प्रणालियों में 'सुरक्षित-से-असफल प्रयोग' की अवधारणा क्या है और यह सॉफ्टवेयर उत्पाद विकास पर कैसे लागू होती है?

A

Safe-to-fail experiments guarantee product success by eliminating all risks before launch सुरक्षित-से-असफल प्रयोग लॉन्च से पहले सभी जोखिमों को समाप्त करके उत्पाद की सफलता की गारंटी देते हैं

B

Safe-to-fail experiments are small, low-cost probes designed so that failure provides learning rather than catastrophe — applied to software by running multiple small A/B tests or MVP variants simultaneously rather than betting everything on a single large release सुरक्षित-से-असफल प्रयोग छोटे, कम लागत वाले जांच होते हैं ताकि विफलता आपदा के बजाय सीख प्रदान कर सके - एक ही बड़ी रिलीज पर सब कुछ दांव पर लगाने के बजाय एक साथ कई छोटे ए/बी परीक्षण या एमवीपी वेरिएंट चलाकर सॉफ्टवेयर पर लागू किया जाता है।

C

Safe-to-fail experiments are only applicable to scientific research, not commercial software सुरक्षित-से-असफल प्रयोग केवल वैज्ञानिक अनुसंधान पर लागू होते हैं, व्यावसायिक सॉफ़्टवेयर पर नहीं

D

Safe-to-fail experiments require a minimum of 6 months to produce statistically valid results सुरक्षित-से-असफल प्रयोगों को सांख्यिकीय रूप से मान्य परिणाम देने के लिए कम से कम 6 महीने की आवश्यकता होती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Cynefin's Complex domain (Snowden): probe-sense-respond replaces plan-execute-monitor. Amazon's 'two-pizza teams' running simultaneous experiments embody this: launch multiple small feature tests, amplify what works, dampen what doesn't. The failed experiments cost little individually but provide learning that guides the amplified investment. This contrasts with traditional 'plan everything upfront' which makes a single large failure catastrophic.

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

2635

EN + हिं Easy

GB What is 'continuous delivery' versus 'continuous deployment' and what organisational capability distinguishes teams that achieve them?

IN 'निरंतर वितरण' बनाम 'निरंतर तैनाती' क्या है और कौन सी संगठनात्मक क्षमता उन्हें हासिल करने वाली टीमों को अलग करती है?

A

Continuous delivery and deployment are synonymous; the terms are used interchangeably निरंतर वितरण और तैनाती पर्यायवाची हैं; शब्दों का प्रयोग परस्पर उपयोग किया जाता है

B

Continuous delivery ensures every commit is releasable (deployable on demand by business decision); continuous deployment automatically releases every passing commit to production without human approval — distinguished by organisational capability: trust in automated testing, deployment automation, monitoring, and cultural acceptance of frequent small releases निरंतर डिलीवरी यह सुनिश्चित करती है कि प्रत्येक प्रतिबद्धता रिलीज़ करने योग्य है (व्यावसायिक निर्णय द्वारा मांग पर तैनाती योग्य); निरंतर तैनाती मानव अनुमोदन के बिना उत्पादन के लिए प्रत्येक गुजरने वाली प्रतिबद्धता को स्वचालित रूप से जारी करती है - संगठनात्मक क्षमता द्वारा प्रतिष्ठित: स्वचालित परीक्षण, तैनाती स्वचालन, निगरानी और लगातार छोटी रिलीज की सांस्कृतिक स्वीकृति में विश्वास

C

Continuous deployment is always preferable to continuous delivery for all organisations सभी संगठनों के लिए निरंतर वितरण की तुलना में निरंतर तैनाती हमेशा बेहतर होती है

D

Both practices require dedicated hardware separate from production for safety दोनों प्रथाओं को सुरक्षा के लिए उत्पादन से अलग समर्पित हार्डवेयर की आवश्यकता होती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Netflix and Amazon practice continuous deployment (thousands of deploys per day). Many enterprises practice continuous delivery — they CAN deploy anytime but choose deployment windows for business reasons (avoid Friday deploys, coordinate with marketing). The capability prerequisite: deployment pipeline (build → test → stage → prod) must be automated, fast (<30 mins end-to-end), and reliable enough to trust without manual verification at each stage.

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

2636

EN + हिं Easy

GB What is 'value stream mapping' applied to software development and what waste categories does it identify?

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

A

Value stream mapping is a UML sequence diagram technique for documenting API interactions वैल्यू स्ट्रीम मैपिंग एपीआई इंटरैक्शन के दस्तावेजीकरण के लिए एक यूएमएल अनुक्रम आरेख तकनीक है

B

Value stream mapping traces the flow of a feature from idea to production, identifying waste in the process — waste categories in software (Poppendieck's lean): partially done work, extra processes, extra features, task switching, waiting, motion (handoffs), defects वैल्यू स्ट्रीम मैपिंग विचार से उत्पादन तक एक सुविधा के प्रवाह का पता लगाती है, प्रक्रिया में अपशिष्ट की पहचान करती है - सॉफ्टवेयर में अपशिष्ट श्रेणियां (पॉपेंडिएक का झुकाव): आंशिक रूप से किया गया कार्य, अतिरिक्त प्रक्रियाएं, अतिरिक्त सुविधाएं, कार्य स्विचिंग, प्रतीक्षा, गति (हैंडऑफ़), दोष

C

Value stream mapping only applies to manufacturing workflows and cannot be used for software वैल्यू स्ट्रीम मैपिंग केवल विनिर्माण वर्कफ़्लो पर लागू होती है और सॉफ़्टवेयर के लिए इसका उपयोग नहीं किया जा सकता है

D

Value stream mapping is identical to a Gantt chart with additional colour coding वैल्यू स्ट्रीम मैपिंग अतिरिक्त रंग कोडिंग के साथ गैंट चार्ट के समान है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Applying VSM to a software feature request reveals hidden waste: 2 days development, 3 days waiting for code review, 1 day review, 2 days waiting for QA, 2 days testing, 5 days waiting for release approval, 1 hour actual deployment. The value-added time is 5 days; total lead time is 15 days — 67% waste. This makes invisible waiting visible, driving improvement focus to cycle time reduction rather than developer productivity.

व्याख्या (हिन्दी) सॉफ़्टवेयर फ़ीचर अनुरोध पर वीएसएम लागू करने से छिपे हुए अपशिष्ट का पता चलता है: 2 दिन का विकास, 3 दिन कोड समीक्षा की प्रतीक्षा, 1 दिन की समीक्षा, 2 दिन क्यूए की प्रतीक्षा, 2 दिन परीक्षण, 5 दिन रिलीज़ अनुमोदन की प्रतीक्षा, 1 घंटा वास्तविक तैनाती। मूल्यवर्धित समय 5 दिन है; कुल लीड टाइम 15 दिन है - 67% बर्बादी। यह अदृश्य प्रतीक्षा को दृश्यमान बनाता है, जिससे डेवलपर उत्पादकता के बजाय चक्र समय में कमी पर सुधार पर ध्यान केंद्रित होता है।

2637

EN + हिं Easy

GB What is 'mob programming' and what does research suggest about its quality and productivity trade-offs?

IN 'मॉब प्रोग्रामिंग' क्या है और शोध इसकी गुणवत्ता और उत्पादकता के बीच के अंतर के बारे में क्या सुझाव देता है?

A

Mob programming means a group of developers working independently on the same repository simultaneously मोब प्रोग्रामिंग का अर्थ है डेवलपर्स का एक समूह जो एक ही रिपॉजिटरी पर एक साथ स्वतंत्र रूप से काम करता है

B

Mob programming has the entire team (3-5+ developers) working at one computer simultaneously with rotating 'drivers' — research and practitioner reports suggest: significantly better code quality and knowledge sharing, lower defect rates, faster onboarding, but higher initial cognitive overhead and requires strong facilitation मॉब प्रोग्रामिंग में पूरी टीम (3-5+ डेवलपर्स) एक ही कंप्यूटर पर घूमने वाले 'ड्राइवरों' के साथ काम करती है - अनुसंधान और व्यवसायी रिपोर्ट से पता चलता है: काफी बेहतर कोड गुणवत्ता और ज्ञान साझा करना, कम दोष दर, तेज ऑनबोर्डिंग, लेकिन उच्च प्रारंभिक संज्ञानात्मक ओवरहेड और मजबूत सुविधा की आवश्यकता है

C

Mob programming has been scientifically proved to produce exactly double the defects of pair programming वैज्ञानिक रूप से यह सिद्ध हो चुका है कि मोब प्रोग्रामिंग जोड़ी प्रोग्रामिंग के दोषों को दोगुना कर देती है

D

Mob programming is only practical for teams working on algorithms; UI development requires individual work मॉब प्रोग्रामिंग केवल एल्गोरिदम पर काम करने वाली टीमों के लिए व्यावहारिक है; यूआई विकास के लिए व्यक्तिगत कार्य की आवश्यकता होती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Woody Zuill's reports from Hunter Industries (where mob programming originated) showed: near-zero defects reaching production, eliminated code review bottlenecks, eliminated handoff waste, and dramatically faster knowledge sharing. Academic research is limited but practitioner evidence is compelling. The overhead is real (one keyboard for 5 people) but the communication bandwidth and collective intelligence can exceed the sum of individual work.

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

2638

EN + हिं Medium

GB What is 'the agile iron triangle' inversion and how does it change project delivery management?

IN 'द एजाइल आयरन ट्राइएंगल' व्युत्क्रम क्या है और यह परियोजना वितरण प्रबंधन को कैसे बदलता है?

A

Agile iron triangle eliminates time and cost constraints entirely by using unlimited sprints एजाइल आयरन ट्राइएंगल असीमित स्प्रिंट का उपयोग करके समय और लागत की बाधाओं को पूरी तरह से समाप्त कर देता है

B

Traditional iron triangle fixes scope and varies time/cost; agile inverts this by fixing time (sprint length) and cost (team size) while varying scope — delivery management shifts from schedule tracking (will we finish everything?) to value maximisation (are we delivering the highest value within the fixed cadence?) पारंपरिक लौह त्रिकोण दायरा तय करता है और समय/लागत बदलता रहता है; एजाइल अलग-अलग दायरे में समय (स्प्रिंट लंबाई) और लागत (टीम का आकार) तय करके इसे उलट देता है - वितरण प्रबंधन शेड्यूल ट्रैकिंग (क्या हम सब कुछ खत्म कर देंगे?) से मूल्य अधिकतमकरण (क्या हम निश्चित ताल के भीतर उच्चतम मूल्य प्रदान कर रहे हैं?) में बदल जाता है।

C

Agile iron triangle fixes all three variables simultaneously, eliminating project uncertainty एजाइल आयरन ट्राइएंगल परियोजना की अनिश्चितता को दूर करते हुए सभी तीन चरों को एक साथ ठीक करता है

D

The iron triangle inversion means agile projects never have deadlines or budget constraints लौह त्रिकोण व्युत्क्रम का मतलब है कि चुस्त परियोजनाओं में कभी भी समय सीमा या बजट की कमी नहीं होती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Traditional PM asks 'how long will it take to build all these features?' (uncertain answer). Agile asks 'what is the most valuable thing we can build in this fixed time with this fixed team?' (always deliverable answer). Sprint commitments are scope commitments for a fixed timebox — the sprint may not complete all planned stories but always ends at its fixed date. This guarantees regular delivery rhythm while preserving scope flexibility.

व्याख्या (हिन्दी) पारंपरिक प्रधानमंत्री पूछते हैं 'इन सभी सुविधाओं को बनाने में कितना समय लगेगा?' (अनिश्चित उत्तर). एजाइल पूछता है 'इस निश्चित टीम के साथ इस निश्चित समय में हम कौन सी सबसे मूल्यवान चीज़ बना सकते हैं?' (हमेशा वितरण योग्य उत्तर)। स्प्रिंट प्रतिबद्धताएँ एक निश्चित टाइमबॉक्स के लिए स्कोप प्रतिबद्धताएँ हैं - स्प्रिंट सभी नियोजित कहानियों को पूरा नहीं कर सकता है लेकिन हमेशा अपनी निश्चित तिथि पर समाप्त होता है। यह स्कोप लचीलेपन को बनाए रखते हुए नियमित डिलीवरी लय की गारंटी देता है।

2639

EN + हिं Easy

GB What is the 'product discovery' phase and what is the 'opportunity solution tree' technique?

IN 'उत्पाद खोज' चरण क्या है और 'अवसर समाधान वृक्ष' तकनीक क्या है?

A

Product discovery is a phase where legal requirements for the product are documented उत्पाद खोज एक ऐसा चरण है जहां उत्पाद के लिए कानूनी आवश्यकताओं का दस्तावेजीकरण किया जाता है

B

Product discovery identifies validated customer needs and solutions before engineering commitment; the opportunity solution tree (Teresa Torres) maps: desired outcome → opportunities (customer needs) → solutions → experiments — ensuring solutions are traceable to real customer problems उत्पाद खोज इंजीनियरिंग प्रतिबद्धता से पहले मान्य ग्राहक आवश्यकताओं और समाधानों की पहचान करती है; अवसर समाधान वृक्ष (टेरेसा टोरेस) मानचित्र: वांछित परिणाम → अवसर (ग्राहक की जरूरतें) → समाधान → प्रयोग - यह सुनिश्चित करना कि समाधान वास्तविक ग्राहक समस्याओं के लिए खोजे जा सकें

C

Product discovery is only relevant for brand new products; existing products skip it entirely उत्पाद खोज केवल बिल्कुल नए उत्पादों के लिए प्रासंगिक है; मौजूदा उत्पाद इसे पूरी तरह से छोड़ देते हैं

D

Opportunity solution tree is a project management scheduling tool for tracking feature completion अवसर समाधान वृक्ष सुविधा पूर्णता पर नज़र रखने के लिए एक परियोजना प्रबंधन शेड्यूलिंग उपकरण है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Teresa Torres' Opportunity Solution Tree prevents 'solution-first thinking' — jumping to building a feature without proving it addresses a real customer problem. Starting from a measurable desired outcome (increase monthly active users by 20%), mapping customer opportunities (pain points, needs), generating multiple solution options per opportunity, and designing experiments before building — this structure ensures engineering investment is traceable to validated business value.

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

2640

EN + हिं Easy

GB What is the 'INVEST criteria' for user stories and what specific problem does each letter address?

IN उपयोगकर्ता कहानियों के लिए 'निवेश मानदंड' क्या है और प्रत्येक पत्र किस विशिष्ट समस्या का समाधान करता है?

A

INVEST is an acronym for five agile ceremonies: Iteration, Negotiation, Velocity, Estimation, Standup, Testing निवेश पांच त्वरित समारोहों का संक्षिप्त रूप है: पुनरावृत्ति, बातचीत, वेग, अनुमान, स्टैंडअप, परीक्षण

B

INVEST: Independent (can be developed in any order, no story blocking another), Negotiable (details subject to discussion), Valuable (delivers user value), Estimable (team can estimate effort), Small (fits in one sprint), Testable (has clear acceptance criteria) — each criterion addresses a failure mode of poorly written stories निवेश: स्वतंत्र (किसी भी क्रम में विकसित किया जा सकता है, कोई भी कहानी किसी अन्य को अवरुद्ध नहीं करती), परक्राम्य (विवरण चर्चा का विषय), मूल्यवान (उपयोगकर्ता मूल्य प्रदान करता है), अनुमान लगाने योग्य (टीम प्रयास का अनुमान लगा सकती है), छोटा (एक स्प्रिंट में फिट बैठता है), परीक्षण योग्य (स्पष्ट स्वीकृति मानदंड) - प्रत्येक मानदंड खराब लिखी गई कहानियों की विफलता मोड को संबोधित करता है

C

INVEST criteria are only applicable to Scrum; Kanban teams do not use user stories निवेश मानदंड केवल स्क्रम पर लागू होते हैं; कानबन टीमें उपयोगकर्ता कहानियों का उपयोग नहीं करती हैं

D

INVEST was developed by the Scrum Alliance as a replacement for use cases निवेश को स्क्रम अलायंस द्वारा उपयोग के मामलों के प्रतिस्थापन के रूप में विकसित किया गया था

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Each letter prevents a specific failure: Non-independent stories create scheduling dependencies that disrupt sprint planning. Non-negotiable stories ('build exactly this') prevent creative solutions. Non-valuable stories waste sprint capacity. Non-estimable stories (too vague or unknown) can't be sprint-committed. Too-large stories won't complete in a sprint. Non-testable stories have no done criteria — enabling endless scope debate at sprint end.

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

Software Engineering — MCQ Practice