Software Engineering — MCQ Practice

Hindi aur English dono mein practice karo — click karo answer check karne ke liye

📚 647 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
647 questions
211
EN + हिं Medium
GB What is 'process tailoring' in software development, and why is it necessary?
IN सॉफ़्टवेयर विकास में 'प्रोसेस टेलरिंग' क्या है और यह क्यों आवश्यक है?
A
Writing custom code libraries to replace standard frameworks मानक फ्रेमवर्क को बदलने के लिए कस्टम कोड लाइब्रेरी लिखना
B
Adapting a standard process model to fit the specific constraints, size, domain, and team characteristics of a particular project किसी विशेष परियोजना की विशिष्ट बाधाओं, आकार, डोमेन और टीम विशेषताओं को फिट करने के लिए एक मानक प्रक्रिया मॉडल को अपनाना
C
Hiring specialised developers for niche technology domains विशिष्ट प्रौद्योगिकी डोमेन के लिए विशेष डेवलपर्स को नियुक्त करना
D
Automatically generating test cases from requirements specifications आवश्यकताओं के विनिर्देशों से स्वचालित रूप से परीक्षण मामले तैयार करना
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) No single process model suits all projects. Process tailoring adjusts documentation requirements, review gates, iteration length, and tool choices to match the project's risk profile, team size, customer expectations, and regulatory environment.
व्याख्या (हिन्दी) कोई भी एकल प्रक्रिया मॉडल सभी परियोजनाओं के लिए उपयुक्त नहीं है। प्रक्रिया सिलाई परियोजना के जोखिम प्रोफ़ाइल, टीम के आकार, ग्राहकों की अपेक्षाओं और नियामक वातावरण से मेल खाने के लिए दस्तावेज़ीकरण आवश्यकताओं, समीक्षा द्वार, पुनरावृत्ति की लंबाई और उपकरण विकल्पों को समायोजित करती है।
212
EN + हिं Medium
GB Which metric best captures the 'goodness' of a software process rather than just output quality?
IN कौन सा मीट्रिक केवल आउटपुट गुणवत्ता के बजाय सॉफ़्टवेयर प्रक्रिया की 'अच्छाई' को सबसे अच्छी तरह से पकड़ता है?
A
Defect density of the released product जारी उत्पाद का दोष घनत्व
B
Process capability metrics such as defect removal efficiency and rework percentage across multiple projects प्रक्रिया क्षमता मेट्रिक्स जैसे दोष निवारण दक्षता और कई परियोजनाओं में पुन: कार्य प्रतिशत
C
Customer satisfaction survey scores from final release अंतिम रिलीज़ से ग्राहक संतुष्टि सर्वेक्षण स्कोर
D
Total LOC produced per developer per sprint प्रति स्प्रिंट प्रति डेवलपर द्वारा उत्पादित कुल एलओसी
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Process quality is distinct from product quality. Metrics like defect removal efficiency (DRE) and rework percentage across multiple projects reveal how reliably the process performs — independent of any single project's luck. These are the metrics CMM/CMMI use.
व्याख्या (हिन्दी) प्रक्रिया की गुणवत्ता उत्पाद की गुणवत्ता से भिन्न होती है। दोष निवारण दक्षता (डीआरई) और कई परियोजनाओं में पुनः कार्य प्रतिशत जैसे मेट्रिक्स से पता चलता है कि प्रक्रिया कितनी विश्वसनीय रूप से प्रदर्शन करती है - किसी एक परियोजना की किस्मत से स्वतंत्र। ये मेट्रिक्स सीएमएम/सीएमएमआई उपयोग हैं।
213
EN + हिं Easy
GB When switching from a plan-driven to an agile process mid-project, what is the most significant risk?
IN परियोजना के मध्य में योजना-चालित से तीव्र प्रक्रिया पर स्विच करते समय, सबसे महत्वपूर्ण जोखिम क्या है?
A
The project will fail because mixed methodologies are IEEE-forbidden परियोजना विफल हो जाएगी क्योंकि मिश्रित पद्धतियाँ IEEE-निषिद्ध हैं
B
Loss of traceability, incomplete documentation, team confusion about roles, and contractual conflicts with fixed-scope agreements ट्रेसेबिलिटी का नुकसान, अधूरा दस्तावेज, भूमिकाओं के बारे में टीम का भ्रम, और निश्चित दायरे वाले समझौतों के साथ संविदात्मक टकराव
C
Developers will refuse to work without additional compensation डेवलपर्स अतिरिक्त मुआवजे के बिना काम करने से इंकार कर देंगे
D
Agile processes require more powerful hardware चुस्त प्रक्रियाओं के लिए अधिक शक्तिशाली हार्डवेयर की आवश्यकता होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Mid-project process switching disrupts team rhythm, invalidates existing plans and contracts, creates documentation gaps (especially in regulated domains), and leaves roles unclear. Existing deliverables may not align with new process artefacts.
व्याख्या (हिन्दी) मध्य-परियोजना प्रक्रिया स्विचिंग टीम की लय को बाधित करती है, मौजूदा योजनाओं और अनुबंधों को अमान्य कर देती है, दस्तावेज़ीकरण अंतराल पैदा करती है (विशेषकर विनियमित डोमेन में), और भूमिकाएँ अस्पष्ट हो जाती हैं। मौजूदा डिलिवरेबल्स नई प्रक्रिया कलाकृतियों के साथ संरेखित नहीं हो सकते हैं।
214
EN + हिं Medium
GB Why is discovering requirement errors during the testing phase fundamentally problematic in Waterfall?
IN वाटरफॉल में परीक्षण चरण के दौरान आवश्यकता त्रुटियों की खोज करना मौलिक रूप से समस्याग्रस्त क्यों है?
A
Testing phase has the smallest budget in a Waterfall project झरना परियोजना में परीक्षण चरण का बजट सबसे छोटा होता है
B
Requirement errors in testing necessitate traversing back through design and implementation, causing exponential cost escalation due to Waterfall's sequential nature परीक्षण में आवश्यकता त्रुटियों के कारण डिज़ाइन और कार्यान्वयन के माध्यम से वापस जाना आवश्यक हो जाता है, जिससे वॉटरफॉल की अनुक्रमिक प्रकृति के कारण लागत में तेजी से वृद्धि होती है।
C
Testers are not qualified to evaluate requirement-level defects परीक्षक आवश्यकता-स्तरीय दोषों का मूल्यांकन करने के लिए योग्य नहीं हैं
D
Testing environments are not connected to requirements systems परीक्षण वातावरण आवश्यकता प्रणालियों से जुड़े नहीं हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Waterfall's strict sequential phases mean a late-discovered requirement error invalidates downstream design and implementation work. Boehm showed that defects found in testing cost 100× more to fix than those found during requirements review.
व्याख्या (हिन्दी) वॉटरफ़ॉल के सख्त अनुक्रमिक चरणों का मतलब है कि देर से खोजी गई आवश्यकता त्रुटि डाउनस्ट्रीम डिज़ाइन और कार्यान्वयन कार्य को अमान्य कर देती है। बोहेम ने दिखाया कि परीक्षण में पाए गए दोषों को आवश्यकताओं की समीक्षा के दौरान पाए गए दोषों की तुलना में ठीक करने में 100× अधिक लागत आती है।
215
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 जैसे मानकों के लिए व्यापक ट्रैसेबिलिटी और औपचारिक समीक्षा/अनुमोदन द्वार की आवश्यकता होती है। झरने की चरण संरचना स्वाभाविक रूप से इस दस्तावेजी निशान का निर्माण करती है, यही कारण है कि सुरक्षा-महत्वपूर्ण उद्योगों ने ऐतिहासिक रूप से इसका समर्थन किया है।
216
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.
व्याख्या (हिन्दी) झरने की सबसे बड़ी कमजोरी एक चरण पूरा होने के बाद आवश्यकता परिवर्तनों को खूबसूरती से समायोजित करने में असमर्थता है। यूआई-भारी उपभोक्ता उत्पादों के लिए जहां प्रयोज्य परीक्षण से आवश्यक परिवर्तनों का पता चलता है, यह कठोरता घातक है।
217
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 के पेपर ने वास्तव में चेतावनी दी थी कि सरल अनुक्रमिक झरना जोखिम भरा था और पहले एक प्रारंभिक पायलट संस्करण बनाने की सिफारिश की गई थी, साथ ही आसन्न चरणों के बीच स्पष्ट रूप से प्रतिक्रिया की अनुमति दी गई थी। 'शुद्ध' झरना जो उद्योग की हठधर्मिता बन गया, एक गलत व्याख्या थी।
218
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× अधिक खर्च होता है।
219
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'.
व्याख्या (हिन्दी) बड़ी मल्टी-टीम वॉटरफ़ॉल परियोजनाओं में, टीमें इंटरफ़ेस समझौतों के आधार पर समवर्ती रूप से सबसिस्टम डिज़ाइन करती हैं। इंटरफ़ेस ग़लतफ़हमियाँ एकीकरण परीक्षण तक अदृश्य रूप से जमा होती रहती हैं, जो दोषों के एक समूह के रूप में सामने आती हैं - 'एकीकरण नरक'।
220
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.
व्याख्या (हिन्दी) वॉटरफॉल की घातक धारणा यह है कि विकास शुरू होने से पहले आवश्यकताएं पूरी तरह से जानने योग्य और स्थिर होती हैं। वास्तव में, उपयोगकर्ताओं को शायद ही कभी पता चलता है कि वे क्या चाहते हैं जब तक कि वे एक कार्य प्रणाली, बाज़ार में बदलाव और प्रौद्योगिकी विकसित नहीं हो जाते - जिससे स्थिर आवश्यकताओं को असंभव बना दिया जाता है।
221
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.
व्याख्या (हिन्दी) स्पाइरल मॉडल बिल्कुल इसी परिदृश्य के लिए डिज़ाइन किया गया है। जोखिम विश्लेषण से अव्यवहार्यता का पता चलने पर हितधारकों के साथ एक औपचारिक समीक्षा शुरू हो जाती है जो निर्णय ले सकते हैं: आवश्यकता में ढील दें, बजट बढ़ाएं, एक अलग दृष्टिकोण का उपयोग करें, या रद्द करें।
222
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.
व्याख्या (हिन्दी) एजाइल मेनिफेस्टो में स्पष्ट रूप से कहा गया है कि वह बाईं ओर की वस्तुओं को अधिक महत्व देता है, न कि दाईं ओर की वस्तुओं का कोई मूल्य नहीं है। एजाइल में योजना अभी भी आवश्यक है; टीमें अलग-अलग योजना बनाती हैं (छोटे चक्र, अनुकूली पुनर्योजना) और अनुकूलन क्षमता को प्राथमिकता देती हैं।
223
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.
व्याख्या (हिन्दी) स्प्रिंट समीक्षा उत्पाद-केंद्रित है - यह दिखाती है कि प्रतिक्रिया के लिए हितधारकों को क्या बनाया गया था। स्प्रिंट रेट्रोस्पेक्टिव प्रक्रिया-केंद्रित है - टीम इस बात पर विचार करती है कि उन्होंने कैसे काम किया और सुधार योजनाएं बनाती हैं। दोनों को मिलाने से दोनों उद्देश्य कमजोर हो जाते हैं।
224
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.
व्याख्या (हिन्दी) वेलोसिटी (प्रति स्प्रिंट कहानी बिंदु) टीमों को ऐतिहासिक प्रदर्शन के आधार पर भविष्य की डिलीवरी का पूर्वानुमान लगाने में मदद करती है। हालाँकि कहानी के बिंदु सापेक्ष और टीम-विशिष्ट हैं - टीमों में वेग की तुलना करना अर्थहीन है। जब प्रबंधन इसे प्रदर्शन लक्ष्य के रूप में उपयोग करता है तो वेग से भी खिलवाड़ किया जा सकता है।
225
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 वास्तव में जो पूरा हो चुका है उसके बारे में पारदर्शिता बनाता है।
211–225 of 647