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

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

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

3C की अवधारणा

3C का तात्पर्य अच्छी यूजर स्टोरी के तीन महत्वपूर्ण पहलुओं से है। इस अवधारणा का प्रस्ताव रॉन जेफ्रीज ने किया था, जो यूजर स्टोरी प्रथा के सह-आविष्कारक हैं। आजकल, जब हम यूजर स्टोरी के बारे में बात करते हैं, तो हम आमतौर पर उन यूजर स्टोरी के बारे में बात कर रहे होते हैं जो इन तीन पहलुओं से बनी होती हैं।

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

यूजर स्टोरी की पहचान कैसे करें?

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

यूजर स्टोरी के साथ व्यावसायिक प्रक्रिया का मैपिंग

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

1. सरलतम तरीके से यूजर के वर्कफ्लो को BPMN व्यावसायिक प्रक्रिया आरेख के साथ मॉडल करें।
2. उपयोगकर्ताओं के साथ प्रक्रिया मॉडल के माध्यम से चलें।
3. और, समस्या की व्यावसायिक गतिविधियों का विश्लेषण करें, और फिर स्वचालित किए जाने वाली प्रक्रिया से संबंधित यूजर स्टोरी की पहचान करें, जिसे व्यावसायिक प्रक्रिया से यूजर स्टोरी मैपिंग के रूप में भी जाना जाता है।

यूजर स्टोरी कैसे लिखें?

जब यूजर स्टोरी लिखते हैं, तो नीचे दिए गए रूप में उपयोगकर्ता की आवाज़ में लिखने की कोशिश करें (या कम से कम, यह सुनिश्चित करें कि आपके द्वारा लिखा गया वाक्य निम्नलिखित कथन को पूरा करता है):

<भूमिका> के रूप में, मैं <व्यावसायिक लक्ष्य> चाहता हूँ ताकि <व्यावसायिक मूल्य/कारण>।

उदाहरण के लिए, एक ग्राहक, मैं चाहता हूँ कि जब वस्तु पहुंच जाए तो एसएमएस प्राप्त करूं ताकि मैं कर सकूं जाकर उसे उठा लें.

कहाँ:

1. <भूमिका> उस व्यक्ति, प्रणाली, उप-प्रणाली या किसी अन्य एजेंसी का प्रतिनिधित्व करता है जो लक्ष्य प्राप्त करने के लिए लागू की जाने वाली प्रणाली के साथ अंतरक्रिया करेगा। वह प्रणाली के साथ अंतरक्रिया करके मूल्य प्राप्त करेगा।
2. <व्यापार लक्ष्य> उपयोगकर्ता की उम्मीद का प्रतिनिधित्व करता है जिसे प्रणाली के साथ अंतरक्रिया करके प्राप्त किया जा सकता है।
3. <व्यापार मूल्य> प्रणाली के साथ अंतरक्रिया के पीछे के मूल्य का प्रतिनिधित्व करता है।

यह एक नियम नहीं है, बल्कि एक मार्गदर्शिका है जो आपको निम्नलिखित बातों को ध्यान में रखकर उपयोगकर्ता कहानी के बारे में सोचने में मदद करती है:

1. उपयोगकर्ता कहानी किसी व्यक्ति या निश्चित पक्ष (जैसे ग्राहकों) को मूल्य लाएगी।
2. उपयोगकर्ता कहानी उपयोगकर्ता की आवश्यकता को पूरा कर रही है (जैसे वस्तु पहुंचने पर एसएमएस प्राप्त करना)
3. इस उपयोगकर्ता कहानी को लागू करने के लिए कारण है (जैसे ग्राहक अपनी खरीदी वस्तु को लेने जा सकती है)

प्रत्येक उपयोगकर्ता कहानी किसी को मूल्य लानी चाहिए। लेकिन कभी-कभी मूल्य व्यापार लक्ष्य पढ़ने से ही पर्याप्त स्पष्ट हो जाता है। कथन के हिस्से के रूप में मूल्य लिखना जटिल हो सकता है। ऐसे मामलों में हम इसे छोड़ देंगे। यहां कुछ उदाहरण हैं:

ग्राहक के रूप में, मैं क्रेडिट कार्ड का उपयोग करके भुगतान करना चाहता हूंताकि मैं ऑनलाइन खरीदारी में अपना क्रेडिट कार्ड उपयोग कर सकूं.

उपयोगकर्ता के रूप में, मैं अपने दोस्त के नाम दर्ज करके खोज करना चाहता हूंताकि मैं उसके नाम के साथ अपने दोस्त को ढूंढ सकूं.

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

उपयोगकर्ता कहानी का जीवनचक्र

एक व्यापक दृष्टिकोण से, सॉफ्टवेयर प्रोजेक्ट के दौरान प्रत्येक उपयोगकर्ता कहानी के लिए छह मुख्य अवस्थाएं होती हैं:

1. र men – उपयोगकर्ता और प्रोजेक्ट टीम के बीच संचार के माध्यम से उपयोगकर्ता कहानियां खोजी जाती हैं। इस अवस्था में, उपयोगकर्ता कहानियां उपयोगकर्ता की आवश्यकता के एक संक्षिप्त विवरण से अधिक कुछ नहीं हैं। अभी तक आवश्यकताओं के बारे में विस्तृत चर्चा नहीं हुई है, कोई सिस्टम तर्क नहीं है और कोई स्क्रीन डिजाइन नहीं है। वास्तव में, अभी के लिए उपयोगकर्ता कहानी का एकमात्र उद्देश्य यह है कि भविष्य में इस उपयोगकर्ता कहानी (कार्ड) में लिखित उपयोगकर्ता की अनुरोध के बारे में चर्चा करने के लिए सभी पक्षों को याद दिलाना। भविष्य में उपयोगकर्ता कहानी को छोड़ दिया जा सकता है।
2. करने योग्य – विभिन्न हितधारकों के बीच चर्चा के माध्यम से अगले कुछ हफ्तों में संबोधित की जाने वाली उपयोगकर्ता कहानियों का निर्णय लिया जाता है, और उन्हें एक समय-बॉक्स जिसे स्प्रिंट कहा जाता है, में रखा जाता है। ऐसी उपयोगकर्ता कहानियों को टूडो अवस्था में कहा जाता है। इस अवस्था में अभी तक कोई विस्तृत चर्चा नहीं की गई है।
3. चर्चा कर रहा है – जब उपयोगकर्ता कहानी चर्चा कर रहा अवस्था में होती है, तो अंतिम उपयोगकर्ता विकास टीम को आवश्यकताओं की पुष्टि करने और स्वीकृति मानदंड निर्धारित करने के लिए संचार करता है। विकास टीम आवश्यकताओं या किसी भी निर्णय को चर्चा नोट्स के रूप में लिख देगी। यूएक्स विशेषज्ञ विज़ुअल मॉकअप में प्रस्तावित विशेषताओं के पूर्वावलोकन के लिए वायरफ्रेम या स्टोरीबोर्ड बना सकता है, और उपयोगकर्ता को इसे महसूस करने दे सकता है। इस प्रक्रिया को उपयोगकर्ता अनुभव डिजाइन (यूएक्स डिजाइन) कहा जाता है।
   
4. विकास कर रहा है – आवश्यकताओं को स्पष्ट करने के बाद, विकास टीम उपयोगकर्ता की मांगों को पूरा करने के लिए विशेषताओं को डिज़ाइन और कार्यान्वित करेगी।
5. पुष्टि करना – जब विकास टीम ने उपयोगकर्ता कहानी कार्यान्वित कर ली है, तो उपयोगकर्ता कहानी की पुष्टि अंतिम उपयोगकर्ता द्वारा की जाएगी। उसे टेस्टिंग वातावरण या आंशिक रूप से पूर्ण सॉफ्टवेयर उत्पाद (कभी-कभी एल्फा संस्करण के रूप में जाना जाता है) की सुविधा दी जाएगी ताकि विशेषता की पुष्टि की जा सके। पुष्टि उपयोगकर्ता कहानी के विवरण के समय लिखे गए पुष्टि आइटम के आधार पर की जाएगी। पुष्टि के बाद तक, उपयोगकर्ता कहानी को पुष्टि की स्थिति में माना जाता है।
6. समाप्त – अंत में, विशेषता को पूरा होने की पुष्टि कर ली गई है, तो उपयोगकर्ता कहानी को समाप्त स्थिति में माना जाता है। आमतौर पर, यह उपयोगकर्ता कहानी का अंत है। यदि उपयोगकर्ता को नई आवश्यकता है, चाहे वह एक नई विशेषता के बारे में हो या समाप्त उपयोगकर्ता कहानी के सुधार के बारे में हो, तो टीम अगले इटरेशन के लिए एक नई उपयोगकर्ता कहानी बनाएगी।

उपयोगकर्ता कहानी का विवरण – कब और क्यों?

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

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

उपयोगकर्ता कहानी का प्रभावी ढंग से उपयोग कैसे करें?

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

1. उपयोगकर्ता कहानी के विवरण को संक्षिप्त रखें।
2. उपयोगकर्ता कहानी लिखते समय अंतिम उपयोगकर्ता के दृष्टिकोण से सोचें।
3. एक (UML) उपयोग केस एक व्यापार लक्ष्य का प्रतिनिधित्व करता है। उपयोग केस के तहत उपयोगकर्ता कहानियों के समूहीकरण की क्षमता आपको यह सुनिश्चित करने में मदद करती है कि उपयोगकर्ता कहानी एक व्यापार लक्ष्य को पूरा कर रही है, दूसरे शब्दों में, वे एक ही सिस्टम लक्ष्य को साझा कर रहे हैं। यह आपके लिए उपयोगकर्ता कहानियों को प्रबंधित, योजना बनाने और प्राथमिकता देने के लिए एक स्थान बनाता है, जिससे यह अधिक प्रबंधन योग्य हो जाता है।
4. पुष्टि आइटम को विकास शुरू करने से पहले परिभाषित किया जाना चाहिए
5. अपनी टीम के कार्यभार को नियंत्रण में रखने के लिए विकास से पहले उपयोगकर्ता कहानी का अनुमान लगाएं।
6. आवश्यकताएं अंतिम उपयोगकर्ताओं के साथ खोजी जाती हैं, न कि अंतिम उपयोगकर्ता या केवल विकास टीम द्वारा। अंतिम उपयोगकर्ताओं के साथ अच्छा संबंध बनाए रखना दोनों पक्षों के लिए एक विजय-विजय स्थिति होगी।
7. अंतिम उपयोगकर्ता को क्या चाहिए, इसे समझने में संचार हमेशा महत्वपूर्ण होता है।

विजुअल पैराडाइम आपको आवश्यक सभी उपकरण प्रदान करता है एजिल सॉफ्टवेयर विकास, जिसमें शामिल है UML उपयोग केस आरेख उपकरण, (एजिल) उपयोगकर्ता कहानी, स्प्रिंट, स्टोरीबोर्ड और वायरफ्रेम्स यूएक्स डिज़ाइन के लिए, टास्क प्रबंधन टूल, आदि