601

EN + हिं Easy

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

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

A

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

B

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

C

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

D

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

✅ Correct Answer:

💡 Explanation / व्याख्या

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

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

602

EN + हिं Easy

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

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

A

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

B

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

C

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

D

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

✅ Correct Answer:

💡 Explanation / व्याख्या

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

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

603

EN + हिं Easy

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

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

A

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

B

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

C

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

D

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

✅ Correct Answer:

💡 Explanation / व्याख्या

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

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

604

EN + हिं Easy

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

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

A

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

B

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

C

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

D

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

✅ Correct Answer:

💡 Explanation / व्याख्या

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

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

605

EN + हिं Easy

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

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

A

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

B

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

C

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

D

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

✅ Correct Answer:

💡 Explanation / व्याख्या

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

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

606

EN + हिं Easy

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

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

A

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

B

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

C

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

D

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

✅ Correct Answer:

💡 Explanation / व्याख्या

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

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

607

EN + हिं Easy

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

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

A

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

B

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

C

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

D

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

✅ Correct Answer:

💡 Explanation / व्याख्या

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

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

608

EN + हिं Medium

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

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

A

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

B

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

C

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

D

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

✅ Correct Answer:

💡 Explanation / व्याख्या

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

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

609

EN + हिं Easy

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

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

A

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

B

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

C

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

D

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

✅ Correct Answer:

💡 Explanation / व्याख्या

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

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

610

EN + हिं Easy

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

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

A

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

B

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

C

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

D

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

✅ Correct Answer:

💡 Explanation / व्याख्या

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

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

611

EN + हिं Easy

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

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

A

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

B

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

C

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

D

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

✅ Correct Answer:

💡 Explanation / व्याख्या

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

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

612

EN + हिं Easy

GB What is the 'product owner anti-pattern' of being a 'proxy product owner' and what organisational dysfunction does it indicate?

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

A

A proxy product owner is an AI system that automatically makes all backlog prioritisation decisions प्रॉक्सी उत्पाद स्वामी एक एआई प्रणाली है जो स्वचालित रूप से सभी बैकलॉग प्राथमिकता निर्णय लेती है

B

A proxy product owner relays decisions from a 'real' decision-maker (often a business stakeholder unwilling to engage directly with the team) without having genuine authority to make prioritisation trade-offs — this indicates the organisation hasn't genuinely empowered the product owner role, causing decision delays and information loss through the relay chain एक प्रॉक्सी उत्पाद स्वामी प्राथमिकता निर्धारण व्यापार-बंद करने के लिए वास्तविक अधिकार के बिना एक 'वास्तविक' निर्णय-निर्माता (अक्सर एक व्यावसायिक हितधारक टीम के साथ सीधे जुड़ने के लिए अनिच्छुक होता है) के निर्णयों को रिले करता है - यह इंगित करता है कि संगठन ने उत्पाद स्वामी की भूमिका को वास्तव में सशक्त नहीं किया है, जिससे निर्णय में देरी होती है और रिले श्रृंखला के माध्यम से जानकारी की हानि होती है।

C

Proxy product owners are an officially recommended Scrum practice for large enterprises प्रॉक्सी उत्पाद स्वामी बड़े उद्यमों के लिए आधिकारिक तौर पर अनुशंसित स्क्रम अभ्यास हैं

D

Having a proxy product owner always improves decision-making speed and quality प्रॉक्सी उत्पाद स्वामी होने से निर्णय लेने की गति और गुणवत्ता में हमेशा सुधार होता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) The Scrum Guide requires the Product Owner to have real authority over the backlog. A proxy PO ('let me check with the VP and get back to you') reintroduces the latency and information distortion that direct stakeholder engagement was meant to eliminate. The team's questions get answered days later, often inaccurately relayed. This pattern reveals an organisation that has adopted Scrum's ceremonies without addressing the underlying authority and accountability structure required for it to function effectively.

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

613

EN + हिं Easy

GB What is the 'requirements elicitation interview bias' problem and what techniques mitigate the 'leading question' bias specifically?

IN 'आवश्यकताएँ प्राप्त साक्षात्कार पूर्वाग्रह' समस्या क्या है और कौन सी तकनीकें विशेष रूप से 'अग्रणी प्रश्न' पूर्वाग्रह को कम करती हैं?

A

Interview bias does not affect requirements quality if the interviewer is a senior business analyst यदि साक्षात्कारकर्ता एक वरिष्ठ व्यवसाय विश्लेषक है तो साक्षात्कार पूर्वाग्रह आवश्यकताओं की गुणवत्ता को प्रभावित नहीं करता है

B

Interview bias occurs when the interviewer's questions, framing, or assumptions inadvertently shape stakeholder answers — leading questions ('don't you think the system should have feature X?') are mitigated by open-ended questioning techniques, asking stakeholders to describe current workflows before discussing solutions, and triangulating answers across multiple independent stakeholders साक्षात्कार पूर्वाग्रह तब होता है जब साक्षात्कारकर्ता के प्रश्न, फ़्रेमिंग, या धारणाएँ अनजाने में हितधारक उत्तरों को आकार देते हैं - प्रमुख प्रश्न ('क्या आपको नहीं लगता कि सिस्टम में फ़ीचर एक्स होना चाहिए?') को ओपन-एंडेड प्रश्न तकनीकों द्वारा कम किया जाता है, समाधानों पर चर्चा करने से पहले हितधारकों से वर्तमान वर्कफ़्लो का वर्णन करने के लिए कहा जाता है, और कई स्वतंत्र हितधारकों के बीच उत्तरों को त्रिकोणित किया जाता है।

C

Interview bias only affects technical stakeholders, not business stakeholders साक्षात्कार पूर्वाग्रह केवल तकनीकी हितधारकों को प्रभावित करता है, व्यावसायिक हितधारकों को नहीं

D

The best way to eliminate interview bias is to only interview one stakeholder per requirement साक्षात्कार पूर्वाग्रह को खत्म करने का सबसे अच्छा तरीका यह है कि आवश्यकता के अनुसार केवल एक हितधारक का साक्षात्कार लिया जाए

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Leading questions plant the interviewer's assumption in the answer: stakeholders often agree with suggested features even if they wouldn't have thought of them independently, creating false validation. Open-ended techniques ('walk me through how you currently handle X') reveal actual needs without contaminating them with the interviewer's preconceptions. Triangulation across multiple stakeholders catches individual interview distortions through pattern consistency.

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

614

EN + हिं Easy

GB What is 'requirements negotiation' (Win-Win) and what specific outcome distinguishes it from simple requirements prioritisation?

IN 'आवश्यकताओं पर बातचीत' (विन-विन) क्या है और कौन सा विशिष्ट परिणाम इसे साधारण आवश्यकताओं की प्राथमिकता से अलग करता है?

A

Requirements negotiation and prioritisation are identical activities with no meaningful distinction आवश्यकताओं पर बातचीत और प्राथमिकता बिना किसी सार्थक अंतर के समान गतिविधियां हैं

B

Win-Win negotiation seeks mutually satisfactory agreement among conflicting stakeholders, identifying creative compromises that satisfy multiple parties' underlying interests; prioritisation simply orders requirements by importance without resolving the underlying conflicts between stakeholder interests विन-विन वार्ता परस्पर विरोधी हितधारकों के बीच पारस्परिक रूप से संतोषजनक समझौते की तलाश करती है, ऐसे रचनात्मक समझौतों की पहचान करती है जो कई पक्षों के अंतर्निहित हितों को संतुष्ट करते हैं; प्राथमिकताकरण केवल हितधारक हितों के बीच अंतर्निहित संघर्षों को हल किए बिना आवश्यकताओं को महत्व देता है

C

Win-Win negotiation always means each stakeholder gets exactly 50% of their original request विन-विन बातचीत का हमेशा मतलब होता है कि प्रत्येक हितधारक को उनके मूल अनुरोध का ठीक 50% मिलता है

D

Win-Win negotiation is only applicable when there are exactly two conflicting stakeholders विन-विन वार्ता केवल तभी लागू होती है जब वास्तव में दो परस्पर विरोधी हितधारक हों

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Boehm's Win-Win Spiral approach: rather than simply ranking 'security' above 'usability' (prioritisation), negotiation explores why each stakeholder wants what they want and seeks solutions satisfying both underlying interests — perhaps biometric authentication satisfies both security (strong authentication) and usability (no password to remember). This creative problem-solving produces better outcomes than zero-sum prioritisation where one party's win is another's loss.

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

615

EN + हिं Easy

GB What is 'requirements smell' and what specific patterns indicate poorly written requirements?

IN 'आवश्यकताओं की गंध' क्या है और कौन से विशिष्ट पैटर्न खराब लिखित आवश्यकताओं को दर्शाते हैं?

A

Requirements smell refers to the physical odour of paper-based requirement documents in archives आवश्यकताओं की गंध अभिलेखागार में कागज-आधारित आवश्यकता दस्तावेजों की भौतिक गंध को संदर्भित करती है

B

Requirements smell (analogous to code smell) identifies surface patterns indicating underlying problems: vague adjectives ('user-friendly', 'fast'), conjunctions joining multiple requirements into one ('the system shall do X and Y'), passive voice obscuring responsibility, and unbounded superlatives ('all', 'every', 'never') आवश्यकताओं की गंध (कोड गंध के अनुरूप) अंतर्निहित समस्याओं को इंगित करने वाले सतह पैटर्न की पहचान करती है: अस्पष्ट विशेषण ('उपयोगकर्ता के अनुकूल', 'तेज'), कई आवश्यकताओं को एक में जोड़ने वाले संयोजन ('सिस्टम एक्स और वाई करेगा'), निष्क्रिय आवाज अस्पष्ट जिम्मेदारी, और असीमित अतिशयोक्ति ('सभी', 'प्रत्येक', 'कभी नहीं')

C

Requirements smell only applies to requirements written in languages other than English आवश्यकताएँ गंध केवल अंग्रेजी के अलावा अन्य भाषाओं में लिखी गई आवश्यकताओं पर लागू होती हैं

D

All requirements containing adjectives are automatically considered to have requirements smell विशेषणों से युक्त सभी आवश्यकताओं को स्वचालित रूप से आवश्यकताओं की गंध वाला माना जाता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) 'The system shall process orders quickly and notify the customer' has the conjunction smell — this is actually two requirements (processing speed and notification) bundled together, making it impossible to trace or test independently. 'All errors shall be logged' has the unbounded superlative smell — what about expected validation errors vs unexpected system errors? Each smell type signals a specific rewrite needed to make the requirement clear, testable, and traceable.

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

Software Engineering — MCQ Practice