यूजर स्टोरी डीप डाइव: स्वीकृति मानदंड और काम पूरा होने की परिभाषा को समझना

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

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

यूजर स्टोरी क्या है? 📝

एक कहानी के घटकों को विस्तार से समझने से पहले, यह जानना आवश्यक है कि यूजर स्टोरी वास्तव में क्या है। एजाइल फ्रेमवर्क में, यूजर स्टोरी एक नई क्षमता की इच्छा रखने वाले व्यक्ति के दृष्टिकोण से एक फीचर का संक्षिप्त और सरल वर्णन होता है। इसका प्रायः निम्नलिखित रूप होता है:

• एक रूप में [उपयोगकर्ता का प्रकार],
• मैं चाहता हूँ [कोई लक्ष्य],
• ताकि कि [कोई लाभ]।

इस रूप में ध्यान केंद्रित किया जाता है मूल्यउपयोगकर्ता को प्रदान किए जाने वाले मूल्य पर, तकनीकी कार्यान्वयन के बजाय। हालांकि, इस रूप के साथ विकास को निर्देशित करना पर्याप्त नहीं है। यह कार्य की सीमाओं या पूर्णता के लिए आवश्यक मानकों को निर्दिष्ट नहीं करता है। यहीं स्वीकृति मानदंड और काम पूरा होने की परिभाषा का योगदान होता है।

स्वीकृति मानदंड (AC): पूर्णता की शर्तें ✅

स्वीकृति मानदंड एक ऐसी शर्तों का समूह है जिसे यूजर स्टोरी को पूरा मानने के लिए उत्पाद मालिक के दृष्टिकोण से पूरा करना होता है। ये कहानी की सीमाओं को परिभाषित करते हैं और अंतिम उत्पाद के रूप के बारे में स्पष्ट समझ प्रदान करते हैं।

स्वीकृति मानदंड का उद्देश्य

स्वीकृति मानदंड विकास चक्र के भीतर बहुआयामी कार्य करते हैं:

• स्पष्टीकरण: वे अस्पष्टता को दूर करते हैं। यदि एक डेवलपर पूछता है, “होवर पर बटन हरा या नीला होना चाहिए?”, तो AC इसका उत्तर देना चाहिए।
• परीक्षण: वे परीक्षण मामलों के रूप में कार्य करते हैं। QA इंजीनियर इन शर्तों का उपयोग फीचर के अनुमान के लिए करते हैं।
• सहमति: वे सुनिश्चित करते हैं कि उत्पाद मालिक और विकास टीम इस विशिष्ट कहानी के लिए “पूरा” होने के अर्थ पर सहमत हैं।

अच्छे स्वीकृति मानदंडों की विशेषताएं

प्रभावी स्वीकृति मानदंड विशिष्ट, मापनीय और अस्पष्ट नहीं होते हैं। मापदंडों को परिभाषित किए बिना “उपयोगकर्ता-अनुकूल” या “तेज” जैसे अस्पष्ट शब्दों से बचें। बजाय इसके, सटीक व्यवहार को निर्दिष्ट करें।

• परमाणु: प्रत्येक मानदंड एक ही आवश्यकता को संबोधित करना चाहिए।
• परीक्षण योग्य: इस मानदंड को पास या फेल परिणाम के साथ सत्यापित करना संभव होना चाहिए।
• स्वतंत्र: मानदंड किसी बाहरी कहानी पर निर्भर नहीं होना चाहिए ताकि उसकी पुष्टि की जा सके।
• प्रासंगिक: उपयोगकर्ता मूल्य पर ध्यान केंद्रित करें, आंतरिक कोड संरचना पर नहीं।

स्वीकृति मानदंड के उदाहरण

एक “पासवर्ड भूल गए” फीचर जोड़ने के बारे में एक कहानी के बारे में सोचें। यहां AC कैसा दिख सकता है:

• जब उपयोगकर्ता लॉगिन पेज पर है,
  जब वे “पासवर्ड भूल गए” लिंक पर क्लिक करते हैं,
  तब उन्हें पासवर्ड पुनर्प्राप्ति पेज पर पुनर्निर्देशित किया जाता है।
• जब उपयोगकर्ता एक वैध ईमेल दर्ज करता है,
  जब वे फॉर्म जमा करते हैं,
  तब एक पुष्टि संदेश प्रदर्शित किया जाता है।
• जब उपयोगकर्ता एक अमान्य ईमेल दर्ज करता है,
  जब वे फॉर्म जमा करते हैं,
  तब एक त्रुटि संदेश बताता है कि ईमेल प्रारूप गलत है।

ये उदाहरण दिया गया/जब/तब संरचना (आमतौर पर गेर्किन सिंटैक्स से जुड़ी होती है), जो स्पष्टता को बढ़ावा देती है और स्वचालित परीक्षण ढांचों के साथ संरेखित होती है।

पूरा करने की परिभाषा (DoD): गुणवत्ता गेट 🚧

जबकि स्वीकृति मानदंड एक एकल उपयोगकर्ता कहानी के लिए विशिष्ट होते हैं, पूरा करने की परिभाषा एक वैश्विक मानक है जो सभी स्प्रिंट या रिलीज के भीतर काम पर लागू की जाती है। यह आवश्यकताओं की सूची का प्रतिनिधित्व करती है जिन्हें किसी भी काम के अनुभाग को संभावित रूप से डिलीवर करने योग्य मानने के लिए पूरा किया जाना चाहिए।

पूरा करने की परिभाषा का उद्देश्य

DoD गुणवत्ता गेट के रूप में कार्य करता है। यह सुनिश्चित करता है कि तकनीकी ऋण नहीं बढ़ता है और उत्पाद हमेशा डिलीवर करने योग्य स्थिति में रहता है। यदि कोई कहानी अपने स्वीकृति मानदंड पूरे करती है लेकिन पूरा करने की परिभाषा को पूरा नहीं करती है, तो उसे पूरा नहीं माना जा सकता है।

पूरा करने की परिभाषा में पाए जाने वाले सामान्य तत्वों में शामिल हैं:

• कोड समीक्षा: सभी कोड को कम से कम एक सहकर्मी द्वारा समीक्षा की जानी चाहिए।
• यूनिट परीक्षण: स्वचालित परीक्षणों को नए तर्क के लिए 100% कवरेज के साथ पास करना चाहिए।
• दस्तावेज़ीकरण: API दस्तावेज़ीकरण या उपयोगकर्ता मार्गदर्शिकाएँ अद्यतन की गई हैं।
• प्रदर्शन: सुविधा न्यूनतम लोड समय आवश्यकताओं को पूरा करती है।
• पहुँच: सुविधा WCAG दिशानिर्देशों का पालन करती है।
• सुरक्षा: कोई ज्ञात दुर्लभता नहीं जोड़ी गई है।

DoD क्यों महत्वपूर्ण है

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

स्वीकृति मानदंड बनाम डिफ़ाइन्ड ऑफ डन: मुख्य अंतर 🆚

भ्रम अक्सर इसलिए उत्पन्न होता है क्योंकि दोनों अवधारणाएँ ‘पूर्णता’ से संबंधित होती हैं। हालांकि, उनका दायरा और मालिकाना हक बहुत अलग होता है। अंतर को समझने से डेवलपर्स, टेस्टर्स और प्रोडक्ट ओनर्स के बीच असंगति को रोका जा सकता है।

सुविधा	स्वीकृति मानदंड	डिफ़ाइन्ड ऑफ डन
दायरा	एक एकल उपयोगकर्ता कहानी के लिए विशिष्ट	पूरी टीम या परियोजना के लिए सार्वभौमिक
मालिकाना हक	उत्पाद मालिक और विकास टीम	पूरी विकास टीम
लचीलापन	आवश्यकताओं के आधार पर कहानी के अनुसार बदलाव	स्थिर, हालांकि समय के साथ अद्यतन किया जा सकता है
उद्देश्य	कार्यात्मक आवश्यकताओं को परिभाषित करता है	गुणवत्ता और गैर-कार्यात्मक मानकों को परिभाषित करता है
प्रमाणीकरण	उपयोगकर्ता की आवश्यकताओं के विरुद्ध कार्यात्मक परीक्षण	तकनीकी और प्रक्रिया प्रमाणीकरण

स्वीकृति मानदंड को एक विशिष्ट यात्रा के लिए गंतव्य के रूप में सोचिए, जबकि डिफ़ाइन्ड ऑफ डन सड़क पर हर वाहन के लिए आवश्यक सुरक्षा जांच सूची है।

प्रभावी स्वीकृति मानदंड लिखने का तरीका 📝

स्वीकृति मानदंड लिखना एक सहयोगात्मक प्रयास है। इसे उत्पाद अधिकारी द्वारा अलगाव में नहीं किया जाना चाहिए। सर्वोत्तम प्रथा में “तीन दोस्तों” की अवधारणा शामिल है, जहां उत्पाद अधिकारी, एक विकासकर्ता और एक परीक्षक परिष्करण प्रक्रिया के शुरुआती चरण में सहयोग करते हैं।

चरण 1: उपयोगकर्ता लक्ष्य की पहचान करें

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

चरण 2: सकारात्मक और नकारात्मक परिदृश्य को परिभाषित करें

बस खुशहाल मार्ग के बारे में लिखने के लिए न रहें। जब चीजें गलत हो जाएं तो क्या होता है, इस पर विचार करें।

• खुशहाल मार्ग: उपयोगकर्ता उम्मीद के अनुसार क्रिया करता है।
• किनारे के मामले: विशेष अक्षरों, गायब डेटा या धीमी कनेक्शन के साथ क्या होता है?
• नकारात्मक मार्ग: प्रणाली अमान्य इनपुट को बिना तकलीफ के कैसे संभालती है?

चरण 3: स्पष्ट भाषा का उपयोग करें

जहां संभव हो, जार्गन से बचें। यदि तकनीकी शब्दों की आवश्यकता हो, तो यह सुनिश्चित करें कि उनकी परिभाषा की गई हो। सक्रिय वाक्य रूप का उपयोग करें। उदाहरण के लिए, “प्रणाली को सत्यापित करना होगा…” बहुत स्पष्ट नहीं है, जबकि “उपयोगकर्ता को त्रुटि संदेश प्राप्त होता है…” बेहतर है।

चरण 4: प्राथमिकता निर्धारित करें

यदि कहानी बड़ी है, तो उसे छोटे-छोटे हिस्सों में बांटें। स्वीकृति मानदंड को स्प्रिंट के भीतर पूरा करने योग्य होना चाहिए। यदि मानदंड ऐसे काम को इंगित करते हैं जो स्प्रिंट के भीतर पूरा नहीं किया जा सकता, तो कहानी को विभाजित करने की आवश्यकता होगी।

एक मजबूत ‘काम पूरा’ परिभाषा कैसे बनाएं 🛠️

‘काम पूरा’ की परिभाषा एक स्थिर दस्तावेज नहीं है। टीम के परिपक्व होने और तकनीक में बदलाव के साथ यह विकसित होती रहती है। इसे सभी के लिए दिखाई देना चाहिए, ज्यादातर एक भौतिक या डिजिटल बोर्ड पर प्रदर्शित किया जाता है।

चरण 1: टीम से परामर्श करें

‘काम पूरा’ की परिभाषा काम करने वाली टीम की है। विकासकर्ता, परीक्षक और डिजाइनरों को सूची में योगदान देना चाहिए। यदि एक विकासकर्ता एक आवश्यकता जोड़ता है, तो वह उसका पालन करने की संभावना अधिक होती है।

चरण 2: आवश्यकताओं को वर्गीकृत करें

चेकलिस्ट को प्रबंधनीय बनाने के लिए ‘काम पूरा’ के आइटम को तार्किक श्रेणियों में विभाजित करें।

• कोड गुणवत्ता: लिंटिंग पास हुई, कोई चेतावनी नहीं, सहकर्मी समीक्षा पूरी हुई।
• परीक्षण: इकाई परीक्षण लिखे गए, एकीकरण परीक्षण पास हुए, हाथ से परीक्षण सत्यापित किया गया।
• डेप्लॉयमेंट: स्टेजिंग में डेप्लॉय किया गया, स्मोक परीक्षण पास हुए।
• दस्तावेज़ीकरण: रीडमी अद्यतन की गई, API दस्तावेज़ समन्वित किए गए।

चरण 3: इसे एक कठोर रुकावट बनाएं

अगर कोई कहानी DoD को पूरा नहीं करती है, तो उसे बंद नहीं किया जा सकता है। इसमें अनुशासन की आवश्यकता होती है। यह आकर्षक हो सकता है कि कहा जाए, “हम बाद में दस्तावेज़ीकरण ठीक करेंगे,” लेकिन ऐसा करने से तकनीकी ऋण बनता है। कहानी “प्रगति में” तब तक रहती है जब तक DoD पूरा नहीं हो जाता।

चरण 4: समीक्षा और सुधार करें

पुनरावलोकन के दौरान टीम से पूछें: “क्या हमारा DoD किसी समस्या को पकड़ा?” या “क्या एक आवश्यकता है जिसे हम लगातार नहीं पूरा कर रहे हैं?” इन दृष्टिकोणों के आधार पर DoD को अद्यतन करें।

बचने वाली सामान्य गलतियाँ ⚠️

यहां तक कि अनुभवी टीमें भी इन अभ्यासों को लागू करते समय गलतियां करती हैं। सामान्य जाल में रहने की जानकारी समय और निराशा को बचा सकती है।

1. अस्पष्ट स्वीकृति मानदंड

“सिस्टम सुरक्षित होना चाहिए” जैसे मानदंड लिखना बेकार है। इसे परीक्षण नहीं किया जा सकता है। इसके बजाय निर्दिष्ट करें कि “सिस्टम में प्रशासक खातों के लिए बहु-कारक प्रमाणीकरण की आवश्यकता होगी।”

2. DoD को एक बॉक्स चेक करने के अभ्यास के रूप में देखना

अगर टीम DoD के बॉक्स को चेक करती है लेकिन वास्तव में काम नहीं करती है (उदाहरण के लिए कोड समीक्षा छोड़ देना), तो DoD का अर्थ खो जाता है। DoD का सम्मान किया जाना चाहिए, बस पढ़ने के लिए नहीं।

3. DoD को अत्यधिक जटिल बनाना

50 आइटम वाला DoD भारी हो जाता है। महत्वपूर्ण गुणवत्ता के द्वारों पर ध्यान केंद्रित करें। अगर कोई आवश्यकता बहुत कम उल्लंघित होती है, तो वह एक दिशा-निर्देश हो सकता है, न कि कठोर DoD आइटम।

4. गैर-क्रियात्मक आवश्यकताओं को नजरअंदाज करना

टीमें अक्सर AC (क्रियात्मक) पर बहुत ध्यान देती हैं और DoD (गैर-क्रियात्मक) को नजरअंदाज करती हैं। प्रदर्शन, सुरक्षा और उपलब्धता DoD का हिस्सा हैं, AC का नहीं। इनकी उपेक्षा करने से ऐसे फीचर बनते हैं जो काम करते हैं लेकिन धीमे या असुरक्षित होते हैं।

5. टीम के सहमति के बिना DoD बनाना

अगर उत्पाद मालिक डेवलपर के निवेदन के बिना DoD तय करता है, तो टीम इसका विरोध कर सकती है। DoD एक साझा समझौता होना चाहिए।

कार्यप्रवाह में एकीकरण 🔄

स्वीकृति मानदंड और समाप्ति की परिभाषा को विकास चक्र के हर चरण में एकीकृत किया जाना चाहिए, केवल अंत में नहीं।

सुधार चरण

बैकलॉग सुधार के दौरान, उत्पाद मालिक स्वीकृति मानदंड तैयार करता है। टीम इनकी जांच करती है ताकि यह सुनिश्चित किया जा सके कि वे परीक्षण योग्य और लागू हों। यहां सवाल पूछे जाते हैं और उत्तर दिए जाते हैं, स्प्रिंट के दौरान नहीं।

स्प्रिंट योजना

कहानियों के प्रति प्रतिबद्ध होते समय, टीम सुनिश्चित करती है कि स्वीकृति मानदंड स्पष्ट हैं। अगर वे स्पष्ट नहीं हैं, तो कहानी स्प्रिंट के लिए तैयार नहीं है।

विकास चरण

डेवलपर कोड लिखते हैं जो AC को पूरा करे। साथ ही, वे सुनिश्चित करते हैं कि वे DoD का पालन करते हैं (उदाहरण के लिए परीक्षण लिखना, समीक्षा के लिए अनुरोध करना)।

परीक्षण चरण

QA � ingineers निर्मित फीचर के खिलाफ AC की जांच करते हैं। वे DoD की भी जांच करते हैं (उदाहरण के लिए कोड कवरेज रिपोर्ट्स चेक करना, उपलब्धता स्कैन)।

समीक्षा और बंद करना

कहानी को “पूरा” में ले जाने से पहले, टीम यह सुनिश्चित करती है कि AC और DoD दोनों पूरे हुए हैं। अगर नहीं, तो यह कतार में वापस आ जाती है।

सफलता का मापन 📊

आपको कैसे पता चलेगा कि आपके स्वीकृति मानदंड और समाप्ति की परिभाषा काम कर रहे हैं? समय के साथ मापदंडों को ट्रैक करें।

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

अक्सर पूछे जाने वाले प्रश्न ❓

यहां उन सामान्य प्रश्नों की सूची है जो टीमें इन मानकों को लागू करते समय पूछती हैं।

प्रश्न: क्या स्प्रिंट के दौरान स्वीकृति मानदंड में बदलाव किया जा सकता है?

उत्तर: आदर्श रूप से, नहीं। यदि AC में महत्वपूर्ण बदलाव होता है, तो इसका मतलब हो सकता है कि कहानी को रूपांतरण के दौरान अच्छी तरह से समझा नहीं गया था। नामांकित स्पष्टीकरण स्वीकार्य हैं, लेकिन महत्वपूर्ण दायरे के बदलाव के लिए नई कहानी बनानी या स्प्रिंट के दायरे में समायोजन करना चाहिए।

प्रश्न: क्या प्रत्येक कहानी के लिए एक अद्वितीय ‘कार्य पूर्णता की परिभाषा’ की आवश्यकता होती है?

उत्तर: नहीं। DoD सार्वभौमिक है। हालांकि, विशिष्ट तकनीकी कहानियों में उस विशिष्ट आइटम के लिए चेकलिस्ट में अतिरिक्त आवश्यकताएं जोड़ी जा सकती हैं, लेकिन मूल DoD सभी पर लागू होता है।

प्रश्न: यदि टीम DoD पर सहमत नहीं है तो क्या होगा?

उत्तर: चर्चा को बढ़ावा दें। लक्ष्य सहमति है। यदि एक डेवलपर किसी आवश्यकता पर जोर देता है जिसके बारे में टेस्टर सहमत नहीं है, तो जोखिम पर चर्चा करें। यदि जोखिम कम है, तो उसे हटा दें। यदि उच्च है, तो उसे रखें।

प्रश्न: स्वीकृति मानदंड कितने विस्तृत होने चाहिए?

उत्तर: पर्याप्त विस्तार से जिससे इसकी जांच की जा सके। यदि एक QA इंजीनियर AC से सीधे एक परीक्षण मामला लिख सकता है, तो यह पर्याप्त विस्तार में है। यदि उन्हें प्रश्न पूछने की आवश्यकता होती है, तो इसमें अधिक विस्तार की आवश्यकता है।

प्रश्न: क्या स्वचालित परीक्षण DoD में मैनुअल परीक्षण को प्रतिस्थापित कर सकता है?

उत्तर: यह निर्भर करता है। महत्वपूर्ण तर्क के लिए, हां। उपयोगकर्ता अनुभव या दृश्य तत्वों के लिए, मैनुअल प्रमाणीकरण अभी भी आवश्यक हो सकता है। DoD को गुणवत्ता आश्वासन के लिए सर्वोत्तम प्रथा को दर्शाना चाहिए।

गुणवत्ता और संरेखण पर अंतिम विचार 🌟

स्वीकृति मानदंड और कार्य पूर्णता की परिभाषा को लागू करना ब्यूरोक्रेसी के बारे में नहीं है; यह सम्मान के बारे में है। यह उपयोगकर्ता के प्रति सम्मान है जो एक कार्यकारी विशेषता की उम्मीद करता है, डेवलपर के प्रति सम्मान जो स्पष्ट आवश्यकताओं की इच्छा रखता है, और उत्पाद मालिक के प्रति सम्मान जो डिलीवरी में आत्मविश्वास की आवश्यकता महसूस करता है।

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

छोटे स्तर से शुरू करें। एक मूल DoD को परिभाषित करें। अगली कहानी के लिए स्पष्ट AC लिखें। अगली रिट्रोस्पेक्टिव में उनकी समीक्षा करें। समय के साथ, इन अभ्यासों को आपकी टीम की संस्कृति में एक दूसरी प्रकृति के रूप में बन जाएगा। परिणाम एक स्थिर धारा में उच्च गुणवत्ता वाले सॉफ्टवेयर का होगा जो उन लोगों की आवश्यकताओं को पूरा करता है जो इसका उपयोग करते हैं।