वेब पर खोज करने पर, एजाइल साधु मानते हैं कि उपयोग केस और यूजर स्टोरी दो अलग-अलग चीजें हैं:

• माइक कॉहन: यूजर स्टोरी उपयोग केस नहीं हैं
• एलिस्टेयर कॉकबर्न: एक यूजर स्टोरी उपयोग केस के लिए एक गजेल के लिए गेज़बो की तरह है
• एक्सट्रीम प्रोग्रामिंग.org: यूजर स्टोरी उपयोग केस के समान उद्देश्य को प्राप्त करती हैं लेकिन वे एक जैसी नहीं हैं।

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

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

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

दिलचस्प बात यह है कि कुछ लोग चीजों को द्विआधारी पैटर्न में देखना पसंद करते हैं और उनके साथ प्रतीकात्मक रूप से जुड़कर ट्रेंडी चीजों का पीछा करते हैं, वास्तविक रूप से उनका वास्तविक रूप से अभ्यास नहीं करते हैं। कुछ लोग यह भी नहीं चाहते कि दूसरे लोग जान लें कि वे अभी भी उपयोग केस का उपयोग कर रहे हैं, वरना उन्हें पुराने और अप्रचलित माना जा सकता है।

अब कुछ लोग यूजर स्टोरी और उपयोग केस के बीच बराबर का चिह्न लगाते हैं:

• एजाइल = यूजर स्टोरी या एजाइल = यूजर स्टोरी + स्क्रम
• यूजर स्टोरी = बस पर्याप्त और बस समय पर
• यूजर स्टोरी = उपयोगकर्ता की अपेक्षा को पूरा करना और संतोषजनक
• उपयोग केस = पहले से विस्तृत आवश्यकता एकत्र करना
• उपयोग केस = <<शामिल>> + <<विस्तार>> = कार्यात्मक विभाजन
• उपयोग केस केवल “उपयोगकर्ता इनपुट” -> “प्रणाली प्रतिक्रिया” के शैली है
• उपयोग केस = पुरानी शैली और अप्रचलित

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

• आवश्यकता खोज आवश्यकता वितरण के बजाय
• ऊपर दिए गए सिद्धांत के तहत एजाइल विकास प्रक्रिया में दो महत्वपूर्ण गुण प्राप्त होते हैं
  • बस समय पर
  • बस पर्याप्त

(मैं ऊपर दिए गए सिद्धांतों से संबंधित अपने व्यक्तिगत विचारों के साथ अधिक पोस्ट लिखूंगा, जो 1992-1995 के मेरे पीएचडी अनुसंधान क्षेत्र – मेटामॉडल और स्कीमा रूपांतरण से निकटता से संबंधित है)

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

आइए मैं आपको एक उदाहरण दिखाता हूं ताकि स्पष्ट हो कि यूजर स्टोरी उपयोग केस से “इतनी अलग” है या नहीं:

उदाहरण

अच्छी उपयोगकर्ता कहानियाँ केवल बयानों से बहुत अधिक हैं। एक मानक उपयोगकर्ता कहानी में तीन भाग होते हैं, जिन्हें सामान्य रूप से तीन सी के रूप में जाना जाता है।

प्रत्येक उपयोगकर्ता कहानी के पहले “C” को मानकृत फॉर्मेट का पालन करना चाहिए:

[भूमिका] के रूप में, मैं [कुछ करना चाहता हूँ], ताकि [लाभ]

जो उपयोगकर्ता कहानी के कार्ड में डाले जाने वाले न्यूनतम सामग्री के रूप में है।

चर्चा उपयोगकर्ता कहानी के दूसरे “C” की सामग्री है, जो अंतिम उपयोगकर्ता, प्रोजेक्ट मालिक और विकास टीम के बीच होने वाली चर्चा का प्रतिनिधित्व करती है। इन चर्चाओं में मौखिक चर्चा या ईमेल, वायरफ्रेम या प्रोजेक्ट के लिए किसी भी अन्य संबंधित सामग्री जैसी बहुत सी उपयोगी जानकारी दर्ज की जाती है।

उपयोगकर्ता कहानी का अंतिम “C” पुष्टि है, जो स्वीकृति मानदंड है जिसका उपयोग यह सत्यापित करने के लिए किया जाता है कि उपयोगकर्ता कहानी सही ढंग से लागू की गई है और सफलतापूर्वक डिलीवर की गई है।

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

• (दिया गया… और) कुछ संदर्भ
• (जब… और) कुछ क्रिया की जाती है
• (तब… और) कुछ क्रियाएँ करें

Cucumber और Jbehave परीक्षण फ्रेमवर्क जैसे उपकरण ऑटोमेटेड परीक्षण के लिए दिया-जब-तब टेम्पलेट के उपयोग को प्रोत्साहित करते हैं, हालांकि इसका उपयोग उपकरण के उपयोग के बिना भी एक तर्कसंगत तरीके के रूप में किया जा सकता है।

आइए “कोर्स रजिस्टर” उपयोगकर्ता कहानी के लिए सभी जानकारी एकत्र करें और इसे 3Cs फॉर्मेट में रखें:

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

सामान्य रूप से समतुल्य लेकिन अलग अर्थ के साथ?

आइए यह जांचें कि मॉडलिंग क्षेत्र में ऐसा कोई समान मामला है या नहीं, ताकि इस स्थिति की तुलना कर सकें, या यह हमें “उपयोगकर्ता कहानी बनाम उपयोगकर्ता मामले” के बारे में अपना मत देने में मदद कर सके, लेकिन बिना भीड़ के अंधेरे अनुसरण किए या बंदर की तरह गुरुओं के कहे गए बातों को दोहराए बिना।

उदाहरण: सामान्य रूप से समतुल्य

UML में हम एक उपयोगकर्ता मामले के प्रतिरूप को अनुक्रम आरेख के साथ वर्णित कर सकते हैं, लेकिन हम आमतौर पर उसी उद्देश्य के लिए सहयोग आरेख का उपयोग नहीं करते हैं; भले ही दोनों आरेख सामान्य रूप से समतुल्य हैं। दूसरे शब्दों में, अनुक्रम आरेख और सहयोग आरेख दोनों में एक ही संख्या में वस्तुएँ एक प्रतिरूप में भाग ले रही हैं और उसी सेट की वस्तुओं के चारों ओर एक ही संख्या में संदेश भेजे जा रहे हैं जो प्रतिरूप के एक कार्य को करने के लिए हैं। हालांकि, पहला आरेख समय-केंद्रित है और दूसरा आरेख स्थान-केंद्रित है। अनुक्रम आरेख का उपयोग प्रतिरूप मॉडलिंग के साथ करने पर अधिक स्पष्ट होता है, जबकि सहयोग आरेख वस्तुओं के बीच संरचनात्मक संबंधों के मॉडलिंग के लिए उपयुक्त है। उदाहरण के लिए, आप भाग लेने वाली वस्तुओं के प्रतिरूप को MVC फ्रेमवर्क (मॉडल/दृश्य और नियंत्रण परतें) में संरचनात्मक रूप से प्रस्तुत करना चाहते हैं।

व्यक्तिगत रूप से, मुझे नहीं लगता कि उपयोगकर्ता कहानी के उपयोग से मेरी टीम एजिल बन जाएगी, और उपयोगकर्ता मामले से मेरी टीम “आगे बढ़ जाएगी।” सबसे महत्वपूर्ण बात यह है कि हम उन उपकरणों का उपयोग कैसे करते हैं और उनके पीछे किस तरह के मानसिकता और सर्वोत्तम व्यवहार हैं। मुझे लोगों के मुझे “पुराने शैली” या अप्रचलित मानने की चिंता नहीं है, जबकि मैं वास्तव में एजिल व्यवहार कर रहा हूँ।

मैं अभी भी संरचित विश्लेषण और डिजाइन के दिनों को याद करता हूँ, शायद हम ADA में एब्स्ट्रैक्ट डेटा प्रकार का उपयोग करके ऑब्जेक्ट-ओरिएंटेड विश्लेषण और डिजाइन सिद्धांतों को लागू कर सकते थे, बिना OOP के समर्थन के 198x में, है ना? दुर्भाग्य से, आप एब्स्ट्रैक्ट डेटा प्रकार की अवधारणाओं तक भी नहीं पहुँच सकते हैं! ओह! मेरे भगवान, मैंने बिना जाने ही खुलासा कर दिया – मैं बुढ़ा हो गया हूँ? या, मैं धनात्मक सोचूँ – अनुभवी?

आपका क्या विचार है? इस पर आपका मत क्या है? मुझे बताएं या यदि मैं गलत हूँ तो मुझे सुधारें।

यह पोस्ट Deutsche, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 और 繁體中文 में भी उपलब्ध है।