उपयोगकर्ता कहानी और स्वीकृति मानदंडों में क्या अंतर है?

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

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

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

कार्य पूर्णता की परिभाषा

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

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

कार्य पूर्णता के उद्देश्य

• टीम के भीतर गुणवत्ता और पूर्णता के बारे में एक सामान्य समझ बनाना
• उपयोग करें एक चेकलिस्ट के रूप में जिसके खिलाफ उपयोगकर्ता कहानियों (या PBIs) की जांच की जाती है
• सुनिश्चित करें कि बढ़त अंत में शिप की गई हैस्प्रिंटउच्च गुणवत्ता वाली है और गुणवत्ता सभी शामिल लोगों द्वारा अच्छी तरह से समझी जाती है।

उदाहरण — करने की परिभाषा

उदाहरण के लिए, सॉफ्टवेयर उद्योग में, टीमों को अपने डीओडी के लिए निम्नलिखित में से कुछ प्रश्नों को पूछने की आवश्यकता हो सकती है:

• कोड सहकर्मी द्वारा समीक्षित किया गया है?
• कोड पूरा किया गया है?
• कोड समीक्षित किया गया है?
• कोड चेक-इन किया गया है?
• यूनिट परीक्षण पास हुए?
• कार्यात्मक परीक्षण पास हुए?
• स्वीकृति परीक्षण पूरे हुए?
• उत्पाद मालिकसमीक्षा की गई और स्वीकृत की गई?

स्वीकृति मानदंड

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

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

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

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

स्वीकृति मानदंडों के लक्ष्य

• यह स्पष्ट करें कि टीम को काम शुरू करने से पहले क्या बनाना चाहिए
• सुनिश्चित करें कि सभी को समस्या के बारे में एक सामान्य समझ हो
• टीम के सदस्यों को बताएं कि कहानी कब पूरी हो गई है
• स्वचालित परीक्षणों के माध्यम से कहानी की पुष्टि करने में मदद करें।

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

• एक उपयोगकर्ता सभी अनिवार्य फील्ड भरे बिना फॉर्म जमा नहीं कर सकता है
• फॉर्म से प्राप्त जानकारी पंजीकरण डेटाबेस में संग्रहीत की जाती है
• भुगतान क्रेडिट कार्ड के माध्यम से किया जा सकता है
• फॉर्म जमा करने के बाद उपयोगकर्ता को एक स्वीकृति ईमेल भेजा जाता है

स्वीकृति मानदंड के साथ उपयोगकर्ता कहानी का उदाहरण

नीचे दिए गए चित्र में उपयोगकर्ता कहानी के स्वीकृति मानदंडों का एक उदाहरण दिखाया गया है।

संदर्भ

• करने की परिभाषा बनाम स्वीकृति मानदंड
• उपयोगकर्ता कहानी मैपिंग क्या है?
• एजाइल सॉफ्टवेयर विकास के लिए उपयोगकर्ता कहानी बनाम उपयोग केस