दपूर्णता की परिभाषा (DoD) उन आवश्यकताओं की सूची है जिसका उपयोग उपयोगकर्ता कहानी को पूरा करने के लिए किया जाता है ताकि टीम इसे पूरा मान सके।
दस्वीकृति मानदंड उपयोगकर्ता कहानियों के लिए एक सेट टेस्ट स्थितियों को शामिल करते हैं जो आवश्यकताओं को पूरा करेंगे ताकि यह पुष्टि की जा सके कि सॉफ्टवेयर अपेक्षित तरीके से काम करता है।
उपयोगकर्ता कहानी कब पूरी होगी?
दूसरे शब्दों में, उपयोगकर्ता कहानियों को पूरा करने के लिए, DoD और स्वीकृति मानदंड को पूरा किया जाना चाहिए। उत्पाद अनुभाग को पूरा नहीं माना जाता है जब तक दोनों सूचियां पूरी नहीं हो जाती हैं। इसलिए, हमें DoD परिभाषा के दो पहलुओं को परिभाषित करने की आवश्यकता है — पूर्णता मानदंड और स्वीकृति मानदंड:
डन की परिभाषा
डन की परिभाषा आइटमों की सूची के रूप में संरचित है, जिसमें प्रत्येक आइटम का उपयोग कहानी या PBI की पुष्टि करने के लिए किया जाता है, जिसका उद्देश्य यह सुनिश्चित करना है कि विकास टीम उन गुणवत्ता के बारे में सहमत हों जो वे उत्पादन करने की कोशिश कर रहे हैं। यह एक चेकलिस्ट के रूप में कार्य करता है जिसका उपयोग जांच के लिए किया जाता हैप्रत्येक उत्पाद पीछे की सूची आइटम (जिसे PBI भी कहा जाता है) या उपयोगकर्ता कहानी के पूर्णता के लिए। “डन” की परिभाषा में शामिल आइटमों का उद्देश्य उत्पाद पीछे की सूची में सभी आइटमों के लिए लागू होना है, केवल एक उपयोगकर्ता कहानी के लिए नहीं।
इसे निम्नलिखित तरीके से सारांशित किया जा सकता है:
- इस शब्द का अर्थ अधिक उत्पाद अनुभाग के समग्र रूप से होता है
- अधिकांश मामलों में, इस शब्द का अर्थ है कि उत्पाद अनुभाग भेजने योग्य है
- इस शब्द को स्क्रम गाइड में परिभाषित किया गया है
- टीम सदस्यों के बीच संचार के तरीके के रूप में उपयोग किया जाता है
- समग्र सॉफ्टवेयर गुणवत्ता
- कि अनुभाग भेजने योग्य है या नहीं
उदाहरण — डन की परिभाषा
- कोड सहकर्मी द्वारा समीक्षित हुआ?
- कोड पूरा हुआ?
- कोड समीक्षित हुआ?
- कोड चेक-इन किया गया?
- यूनिट टेस्ट पास हुए?
- फंक्शनल टेस्ट पास हुए?
- स्वीकृति टेस्ट पूरे हुए?
- उत्पाद मालिक समीक्षा और स्वीकृति की गई है?
स्वीकृति मानदंड
उपयोगकर्ता कथाएँ विकास के प्राथमिक तत्वों में से एक हैंकलाकृतियाँ के लिए एजाइल विकास, लेकिन स्क्रम स्पष्ट रूप से उपयोग करने के लिए उपयोगकर्ता कथाओं या स्वीकृति मानदंडों की आवश्यकता नहीं है। यदि एक उत्पाद पीबीआई को स्प्रिंट में डालने के लिए बहुत बड़ा माना जाता है, तो आमतौर पर उपयोगकर्ता कथा में तोड़ दिया जाता है और बाद में चित्र में दिखाए गए अनुसार कार्यों के सेट में बदल दिया जाता है:
उपयोगकर्ता कथाएँ स्वीकृति मानदंडों को समेटती हैं, इसलिए हम अक्सर डिफ़ाइन ऑफ डन और स्वीकृति मानदंडों को हमारे स्क्रम विकास प्रक्रिया में एक साथ देखते हैं। उपयोगकर्ता कथा टीम द्वारा डिलीवर करने वाले कार्यक्षमता के संदर्भ को प्रदान करती है। स्वीकृति मानदंड उस कार्यक्षमता के विवरण और ग्राहक द्वारा उन्हें कैसे स्वीकार करने के बारे में दिशा-निर्देश प्रदान करते हैं। दोनों मिलकर पूरी डिलीवरेबल प्रदान करते हैं।
कुछ स्वीकृति मानदंडों की खोज स्प्रिंट शुरू होने से पहले निरंतर बैकलॉग रिफाइनमेंट घटनाओं में की जाएगी, और अन्य घटनाओं के तुरंत बाद खोजे जाएंगे स्प्रिंट योजना जब छोटी टीम में उपयोगकर्ता कथा के बारे में बातचीत करने के लिए बैठते हैं। इसलिए स्वीकृति मानदंड उपयोगकर्ता कथा या उत्पाद बैकलॉग आइटम के लिए विशिष्ट लक्षण हैं।
- इस शब्द का प्रयोग एक व्यक्तिगत पीबीआई/कथा पर लागू होता है
- प्रत्येक पीबीआई/कथा के लिए स्वीकृति मानदंड अलग-अलग होते हैं
- शब्द स्क्रम गाइड में परिभाषित नहीं है
- किसी विशिष्ट पीबीआई/कथा के लिए आवश्यकताओं को पूरा कर लिया गया है, इसकी सभी लिंक वालों को सूचित करने के लिए उपयोग किया जाता है
- एके स्वीकृति परीक्षण, संतुष्टि की शर्तें, कुछ मामलों में “परीक्षण मामले,” आदि
स्वीकृति मानदंडों के साथ उपयोगकर्ता कथा का उदाहरण
नीचे दिए गए चित्र में उपयोगकर्ता कथा के स्वीकृति मानदंडों का एक उदाहरण दिखाया गया है।
यह पोस्ट Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 और 繁體中文 में भी उपलब्ध है।