सॉफ्टवेयर विकास की तेजी से बदलती दुनिया में, स्पष्टता मुद्रा है। जो टीमें प्रभावी तरीके से संचार करती हैं, वे बेहतर उत्पाद जल्दी लॉन्च करती हैं। इस संचार के केंद्र में उपयोगकर्ता कहानी है। यह केवल बैकलॉग में एक टिकट नहीं है; यह एक बातचीत का वादा है, मूल्य का वाहन है, और समन्वय का एक उपकरण है।
यह गाइड आपको उच्च गुणवत्ता वाली उपयोगकर्ता कहानियां बनाने के तकनीकी पहलुओं के माध्यम से ले जाएगी। हम बुनियादी परिभाषाओं से लेकर मानचित्रण और सुधार जैसी उन्नत तकनीकों तक जाएंगे। अंत तक, आपके पास विकासकर्ताओं द्वारा समझे जाने वाली, परीक्षकों द्वारा मान्यता प्राप्त की जा सकने वाली और हितधारकों द्वारा प्राथमिकता दी जा सकने वाली कहानियां लिखने के लिए एक व्यावहारिक ढांचा होगा। चलिए शुरू करते हैं।
एक उपयोगकर्ता कहानी क्या है? 🤔
एक उपयोगकर्ता कहानी एक नई क्षमता की आवश्यकता वाले व्यक्ति के दृष्टिकोण से एक फीचर का संक्षिप्त और सरल वर्णन है, जो आमतौर पर सिस्टम का उपयोगकर्ता या ग्राहक होता है। यह एक विवरणात्मक दस्तावेज नहीं है। यह एक बातचीत के लिए एक स्थान रखता है।
पारंपरिक आवश्यकता दस्तावेजों के विपरीत, जो कठोर और लंबे हो सकते हैं, उपयोगकर्ता कहानियां हल्की बनाई गई हैं। वे कौन, वह क्या, और क्यों.
मानक प्रारूप
अधिकांश एजाइल टीमें निरंतरता सुनिश्चित करने के लिए एक मानक टेम्पलेट का उपयोग करती हैं। इस टेम्पलेट में उपयोगकर्ता मूल्य पर ध्यान केंद्रित रहने में मदद मिलती है, तकनीकी कार्यान्वयन विवरणों के बजाय।
- एक रूप में:मैं चाहता हूँ: ताकि:
- एक रूप में: [उपयोगकर्ता की भूमिका]
- मैं चाहता हूँ: [क्रिया या फीचर]
- ताकि: [लाभ या मूल्य]
एक ऐसे परिदृश्य पर विचार करें जहां उपयोगकर्ता अपना पासवर्ड रीसेट करना चाहता है। एक खराब तरीके से लिखा गया आवश्यकता कह सकता है, ‘सिस्टम ईमेल के माध्यम से पासवर्ड रीसेट की अनुमति देगा।’ एक उपयोगकर्ता कहानी इस तरह पढ़ी जाएगी:
- एक रूप मेंपंजीकृत उपयोगकर्ता
- मैं चाहता हूँईमेल के माध्यम से अपना पासवर्ड रीसेट करना
- ताकिमैं बिना सपोर्ट से संपर्क किए अपने खाते तक पहुंच वापस प्राप्त कर सकूं
इस प्रारूप के कारण टीम को मूल मूल्य पर विचार करने के लिए मजबूर किया जाता है। यह बातचीत को ‘हम इस बटन को कैसे बनाएंगे’ से ‘उपयोगकर्ता को इस बटन तक पहुंच की आवश्यकता क्यों है’ में स्थानांतरित करता है।
INVEST मॉडल: गुणवत्तापूर्ण कहानियों के लिए मानदंड 🌟
सभी उपयोगकर्ता कहानियाँ समान नहीं होती हैं। कुछ अस्पष्ट होती हैं, कुछ बहुत बड़ी होती हैं, और कुछ तकनीकी रूप से परीक्षण करना असंभव होता है। निम्न गुणवत्ता वाले आइटम को फ़िल्टर करने के लिए, टीमें अक्सर INVEST मॉडल का उपयोग करती हैं। इस अक्षराक्षर का अर्थ है स्वतंत्र, बातचीत के योग्य, मूल्यवान, आकलन योग्य, छोटा, और परीक्षण योग्य।
स्वतंत्र
एक कहानी को जितना संभव हो उतना स्वतंत्र होना चाहिए। यदि एक कहानी दूसरी कहानी के पूरा होने पर निर्भर है, तो इससे बाधाएँ उत्पन्न होती हैं। यद्यपि सॉफ्टवेयर में निर्भरताएँ मौजूद होती हैं, उन्हें स्पष्ट रूप से प्रबंधित किया जाना चाहिए। आदर्श रूप से, एक टीम को किसी कहानी को लेने और उसे बिना किसी विशिष्ट ऊपरी तरफ के कार्य के पूरा करने में सक्षम होना चाहिए।
बातचीत के योग्य
कहानी का विवरण एक अनुबंध नहीं है। यह एक बातचीत की याददाश्त है। विवरण को विकास टीम और उत्पाद मालिक के बीच बातचीत के माध्यम से तय किया जाना चाहिए। इस लचीलापन के कारण टीम को तकनीकी समाधान सुझाने की अनुमति मिलती है, जो प्रारंभिक अनुरोध से बेहतर हो सकते हैं।
मूल्यवान
प्रत्येक कहानी मूल्य प्रदान करनी चाहिए। यदि कोई कहानी उपयोगकर्ता या व्यवसाय को मूल्य नहीं देती है, तो उसका अस्तित्व नहीं होना चाहिए। मूल्य कार्यात्मक, तकनीकी (जैसे देनदारी कम करना), या संपादन संबंधी हो सकता है। यदि आप मूल्य को स्पष्ट नहीं कर सकते हैं, तो कहानी शायद अनावश्यक है।
आकलन योग्य
टीम को कहानी पूरी करने के लिए आवश्यक प्रयास का आकलन करने में सक्षम होना चाहिए। यदि कहानी बहुत अस्पष्ट है या अज्ञात तकनीक पर निर्भर है, तो इसका आकलन नहीं किया जा सकता है। इन मामलों में, कहानी को और छोटे हिस्सों में बाँटने या एक स्पाइक के माध्यम से अनुसंधान करने की आवश्यकता होती है।
छोटा
कहानियाँ इतनी छोटी होनी चाहिए कि एक ही स्प्रिंट के भीतर पूरी की जा सके। यदि कहानी बहुत बड़ी है, तो वह प्रोजेक्ट बन जाती है। बड़ी कहानियाँ परीक्षण करने में कठिन, आकलन करने में कठिन और प्राथमिकता देने में कठिन होती हैं। उन्हें छोटे-छोटे भागों में बाँटने से तेजी से प्रतिक्रिया मिलती है।
परीक्षण योग्य
एक कहानी के संतोष की स्पष्ट शर्तें होनी चाहिए। यदि आप इसके लिए एक परीक्षण मामला नहीं लिख सकते हैं, तो आप यह जांच नहीं कर सकते कि यह पूरा हुआ है। यह सीधे बनाए जाने की परिभाषा से जुड़ा है।
| मानदंड | पूछने योग्य प्रश्न | उदाहरण समस्या |
|---|---|---|
| स्वतंत्र | क्या हम दूसरी कहानी के बिना इसे बना सकते हैं? | “लॉगिन” के लिए “उपयोगकर्ता प्रोफ़ाइल” की आवश्यकता है |
| बातचीत के योग्य | क्या हम समाधान में बदलाव करने के लिए खुले हैं? | “फीचर Y” के बजाय “API X” का उपयोग करें |
| मूल्यवान | क्या यह उपयोगकर्ता की मदद करता है? | “ब्रांड के अनुरूप फ़ॉन्ट रंग बदलें” |
| आकलन योग्य | क्या हमें इसके लिए कितना समय लगेगा, इसका पता है? | “अज्ञात तीसरे पक्ष के साथ एकीकृत करें” |
| छोटा | क्या इसे एक स्प्रिंट में फिट किया जा सकता है? | “पूरे डैशबोर्ड का निर्माण करें” |
| परीक्षण योग्य | क्या हम इसके लिए एक परीक्षण लिख सकते हैं? | “एप्लिकेशन को तेज करें” |
चरण दर चरण: उपयोगकर्ता कहानी लिखना 🛠️
उपयोगकर्ता कहानी लिखना एक आवर्ती प्रक्रिया है। यह एक ही बार में बहुत कम होता है। यहां एक व्यवस्थित दृष्टिकोण है जिससे एक कहानी को लिखा जा सकता है जो समीक्षा के लिए ठीक रहती है।
चरण 1: उपयोगकर्ता पर्सना की पहचान करें
एक शब्द भी लिखने से पहले यह पहचानें कि आप किसके लिए लिख रहे हैं। एक प्रशासक के लिए कहानी एक सामान्य ब्राउज़र के लिए कहानी से अलग होती है। उनके लक्ष्यों और सीमाओं को समझने के लिए पर्सना कार्ड या मौजूदा प्रोफाइल का उपयोग करें।
चरण 2: क्रिया को परिभाषित करें
उपयोगकर्ता के द्वारा क्या करने की इच्छा है, उसके बारे में स्पष्ट हों। “प्रबंधित करें” या “संभालें” जैसे अस्पष्ट क्रिया शब्दों से बचें। “क्लिक करें”, “सहेजें”, “हटाएं” या “निर्यात करें” जैसे क्रिया शब्दों का उपयोग करें। इस स्पष्टता से डेवलपर्स को आवश्यक विशिष्ट अंतरक्रिया को समझने में मदद मिलती है।
चरण 3: मूल्य को स्पष्ट करें
यह सबसे महत्वपूर्ण हिस्सा है। उपयोगकर्ता को इसकी क्या चिंता है? यदि आप “ताकि” भाग को छोड़ देते हैं, तो आप ऐसे फीचर बनाने के जोखिम में हैं जिनका कोई उपयोग नहीं करता है। नियमित रूप से टीम को लाभ को समझाने के लिए चुनौती दें।
चरण 4: संदर्भ और सीमाओं को जोड़ें
कभी-कभी एक कहानी को अतिरिक्त संदर्भ की आवश्यकता होती है। इसमें तकनीकी सीमाएं, नियामक आवश्यकताएं या अंतिम मामले शामिल हो सकते हैं। इस जानकारी को विवरण क्षेत्र या कहानी से जुड़े टिप्पणियों में रखें, शीर्षक में नहीं।
चरण 5: INVEST के अनुसार समीक्षा करें
कहानी को बैकलॉग में जोड़ने से पहले, इसे INVEST चेकलिस्ट के माध्यम से चलाएं। क्या यह फिट होता है? यदि नहीं, तो इसे सुधारें। अब पांच मिनट लगाकर कहानी को सुधारना बेहतर है बजाय विकास के दौरान पांच घंटे लगाकर गलतफहमी को ठीक करने के।
स्वीकृति मानदंड: पूरा होने की सीमा ✅
स्वीकृति मानदंड कहानी की सीमाओं को परिभाषित करते हैं। वे वे शर्तें हैं जिन्हें पूरा करना आवश्यक है ताकि कहानी को पूरा माना जा सके। इनके बिना, “पूरा” व्यक्तिगत राय होता है।
स्वीकृति मानदंड के प्रकार
स्वीकृति मानदंडों को संरचित करने के कई तरीके हैं। सबसे प्रभावी दृष्टिकोण अक्सर टीम के कार्य प्रवाह पर निर्भर करता है।
- परिदृश्य-आधारित:Given/When/Then सिंटैक्स का उपयोग तर्क प्रवाह को स्पष्ट करने में मदद करता है।
- चेकलिस्ट:सरल बुलेट बिंदु जो विशिष्ट परिणामों की पुष्टि करते हैं।
- नियम:गणितीय या तार्किक नियम जो पूरे किए जाने चाहिए।
- उपयोगकर्ता प्रवाह:फीचर के माध्यम से उपयोगकर्ता के लेने वाले यात्रा का वर्णन करना।
स्वीकृति मानदंडों के उदाहरण
कहानी के प्रकार के आधार पर मानदंडों में कैसे अंतर होता है, उस पर नजर डालते हैं।
| कहानी का फोकस | स्वीकृति मानदंड उदाहरण |
|---|---|
| कार्यक्षमता | |
| सुरक्षा | |
| प्रदर्शन | |
| उपयोगकर्यता |
प्रभावी मानदंड लिखना
इन मानदंडों को लिखते समय उन्हें परमाणु रखें। एक वाक्य में कई शर्तों को न जोड़ें। प्रत्येक मानदंड एक समान परीक्षण योग्य शर्त होनी चाहिए। इससे परीक्षकों के लिए काम की पुष्टि करना आसान होता है और डेवलपर्स को यह जानने में मदद मिलती है कि क्या आवश्यक है।
“तेज़”, “आसान” या “आधुनिक” जैसे व्यक्तिगत शब्दों से बचें। उनके स्थान पर मापने योग्य शब्दों का उपयोग करें, जैसे “200ms से कम”, “3 क्लिक से कम” या “WCAG 2.1 के अनुरूप”।
उपयोगकर्ता कहानी मैपिंग: यात्रा को दृश्यमान बनाना 🗺️
कभी-कभी कहानियों की सूची पर्याप्त नहीं होती है। आपको बड़ी तस्वीर देखने की आवश्यकता होती है। उपयोगकर्ता कहानी मैपिंग एक तकनीक है जिसका उपयोग उपयोगकर्ता अनुभव को दृश्यमान करने और कहानियों को एक सुसंगत रिलीज योजना में व्यवस्थित करने के लिए किया जाता है।
बैकबोन का निर्माण करना
पहले उपयोगकर्ता द्वारा किए जाने वाले मुख्य क्रियाकलापों की पहचान करें। ये आपकी क्षैतिज बैकबोन हैं। ई-कॉमर्स साइट के लिए, ये हो सकते हैं: ब्राउज़, सर्च, कार्ट में जोड़ें, चेकआउट और खाता प्रबंधित करें।
चरणों को जोड़ना
प्रत्येक क्रियाकलाप के नीचे आवश्यक विशिष्ट चरणों की सूची बनाएं। ये आपकी उपयोगकर्ता कहानियाँ हैं। उन्हें उस क्रम में क्षैतिज रूप से व्यवस्थित करें जैसे उन्हें किया जाता है। इससे उपयोगकर्ता यात्रा की रीढ़ बनती है।
रिलीज के लिए प्राथमिकता देना
जब मानचित्र बन जाता है, तो आप उसे क्षैतिज रूप से काट सकते हैं। शीर्ष पंक्ति न्यूनतम विश्वसनीय उत्पाद (MVP) का प्रतिनिधित्व करती है। अगली पंक्ति अधिक मूल्य जोड़ती है। इससे टीमों को उपयोगकर्ता मूल्य के आधार पर बनाने के लिए प्राथमिकता देने में मदद मिलती है, तकनीकी सुविधा के आधार पर नहीं।
मैपिंग के लाभ
- उत्पाद के एक समग्र दृश्य को प्रदान करता है।
- उपयोगकर्ता प्रवाह में अंतराल की पहचान करता है।
- बेहतर योजना निर्माण और रिलीज समय सारणीकरण में सहायता करता है।
- डिजाइनरों और डेवलपर्स के बीच सहयोग को प्रोत्साहित करता है।
सुधार और अनुमान 📏
कहानी लिखना केवल आधा युद्ध है। टीम को शामिल विस्तार और प्रयास को समझना होगा। यह सुधार सत्रों के दौरान होता है।
अस्पष्टता को स्पष्ट करना
सुधारणा के दौरान, टीम प्रश्न पूछती है। “अगर उपयोगकर्ता को इंटरनेट नहीं है तो क्या होता है?” “हम डुप्लीकेट ईमेल्स को कैसे संभालेंगे?” ये प्रश्न छिपी हुई जटिलता को उजागर करते हैं। स्प्रिंट शुरू होने के बाद इन प्रश्नों को पूछने का इंतजार न करें।
कहानियों का आकार निर्धारण
टीमें अक्सर घंटों के बजाय सापेक्ष आकार निर्धारण का उपयोग करती हैं। इससे यह स्वीकार किया जाता है कि समय का अनुमान लगाना मुश्किल है और व्यक्ति-दर-व्यक्ति भिन्न होता है। आम तरीके इस प्रकार हैं:
- प्लानिंग पोकर:टीम सदस्य कार्डों का उपयोग करके आकार पर मतदान करते हैं।
- कहानी अंक:जटिलता, प्रयास और जोखिम का नामांकित मूल्य।
- T-शर्ट के आकार:उच्च स्तरीय योजना के लिए छोटा, मध्यम, बड़ा, एक्स-बड़ा।
किसी भी तरीके के बावजूद, लक्ष्य सहमति है। यदि टीम में मतभेद बहुत अधिक हैं, तो कहानी को और अधिक विभाजित करना या गहन अनुसंधान करना आवश्यक है।
बचने के लिए सामान्य त्रुटियाँ ⚠️
यहां तक कि अनुभवी टीमें भी उपयोगकर्ता कहानियों के प्रबंधन में गलतियां करती हैं। इन सामान्य त्रुटियों के बारे में जागरूकता समय और निराशा को बचा सकती है।
1. तकनीकी कहानियों को उपयोगकर्ता कहानियों के रूप में लिखना
“डेटाबेस स्कीमा को पुनर्गठित करना” या “लाइब्रेरी संस्करण को अपग्रेड करना” जैसे कार्य महत्वपूर्ण हैं, लेकिन वे उपयोगकर्ता कहानियाँ नहीं हैं। वे तकनीकी कार्य हैं। जब तक वे बैकलॉग में रहें, उन्हें तकनीकी देनदारी या इंफ्रास्ट्रक्चर कार्य के रूप में प्रस्तुत किया जाना चाहिए, न कि सीधे उपयोगकर्ता मूल्य के रूप में। यदि आपको इसके लिए कहानी लिखनी है, तो इसे इस तरह रूपांतरित करें: “एक विकासकर्ता के रूप में, मैं लाइब्रेरी अपडेट करना चाहता हूँ ताकि हम सुरक्षा लेखांकन से बच सकें।”
2. “ताकि” को नजरअंदाज करना
लाभ क्लॉज को छोड़ने से फीचर क्रीप होता है। टीमें ऐसी चीजें बनाती हैं जो अच्छी लगती हैं लेकिन कोई समस्या हल नहीं करती हैं। हमेशा टीम को मूल्य की व्याख्या करने के लिए मजबूर करें।
3. विवरण को अत्यधिक भारित करना
एक कहानी का विवरण एक उपन्यास नहीं होना चाहिए। यदि कहानी के लिए 10 पृष्ठों का दस्तावेज़ आवश्यक है, तो वह बहुत बड़ी है। इसे छोटे-छोटे हिस्सों में बांटें। विवरण एक सारांश होना चाहिए, आवश्यकता पड़ने पर विस्तृत विवरण के लिंक के साथ।
4. कहानियों को निश्चित अनुबंध के रूप में लेना
निर्दिष्ट अंश को याद रखें। यदि टीम समस्या को हल करने के लिए बेहतर तरीका ढूंढती है, तो उसे प्रस्तावित करना चाहिए। प्रारंभिक अनुरोध के सख्त पालन से नवाचार को रोका जा सकता है।
5. किनारे के मामलों को नजरअंदाज करना
कहानियाँ अक्सर खुशहाल रास्ते पर ध्यान केंद्रित करती हैं। परीक्षक और विकासकर्ता को स्पष्ट रूप से किनारे के मामलों को उजागर करना चाहिए। यदि इनपुट खाली है तो क्या होता है? यदि नेटवर्क विफल हो जाता है तो क्या होता है? इन्हें स्वीकृति मानदंडों का हिस्सा होना चाहिए।
सहयोग और संचार 🗣️
उपयोगकर्ता कहानी सहयोग का एक उपकरण है। यह उत्पाद मालिक, विकास टीम और परीक्षकों को एक साथ लाती है। संचार के बिना, कहानी सिर्फ स्क्रीन पर लिखा गया टेक्स्ट है।
तीन दोस्त
एक सामान्य अभ्यास “तीन दोस्त” बैठक है। इसमें उत्पाद मालिक, एक विकासकर्ता और एक परीक्षक एक कहानी के बारे में स्प्रिंट में प्रवेश करने से पहले चर्चा करते हैं। वे कहानी की समझ और कवरेज सुनिश्चित करने के लिए एक साथ इसकी समीक्षा करते हैं।
- उत्पाद मालिक:मूल्य और प्राथमिकता की पुष्टि करता है।
- विकासकर्ता:तकनीकी लागूता और जटिलता की पुष्टि करता है।
- परीक्षक: परीक्षण योग्यता और किनारे के मामलों की पुष्टि करता है।
निरंतर प्रतिक्रिया
स्प्रिंट समीक्षा के लिए प्रतिक्रिया प्राप्त करने के लिए इंतजार न करें। कहानियों के ड्राफ्ट को जल्दी ही हितधारकों के साथ साझा करें। शब्दावली और मूल्य प्रस्ताव पर उनकी राय प्राप्त करें। इससे गलत चीज बनाने के जोखिम को कम किया जा सकता है।
दृश्य सहायता
पाठ बहुत कम है। कहानी को समृद्ध बनाने के लिए वायरफ्रेम, मॉकअप या आरेखों का उपयोग करें। एक तस्वीर एक पैराग्राफ पाठ की तुलना में जटिल प्रवाह को तेजी से समझा सकती है। इन कलाकृतियों को सीधे कहानी रिकॉर्ड में जोड़ें।
कहानी के निर्माण पर अंतिम विचार 🎯
उपयोगकर्ता कहानियों के कला को समझने में अभ्यास की आवश्यकता होती है। यह आवश्यकताओं को लिखने से बातचीत को सुविधाजनक बनाने की दृष्टिकोण में बदलाव की आवश्यकता होती है। लक्ष्य पूर्ण दस्तावेज़ बनाना नहीं है, बल्कि स्पष्ट समझ बनाना है।
छोटे से शुरू करें। INVEST मॉडल पर ध्यान केंद्रित करें। सुनिश्चित करें कि प्रत्येक कहानी मूल्य प्रदान करे। यदि वे बहुत बड़े लगते हैं, तो उन्हें और भी छोटे-छोटे हिस्सों में बांटने के लिए तैयार रहें। अपनी टीम को लेखन प्रक्रिया में शामिल करें।
जब अच्छी तरह से किया जाता है, तो उपयोगकर्ता कहानियां आपके डिलीवरी की रीढ़ बन जाती हैं। वे टीम को एक साथ लाती हैं, दृष्टि को स्पष्ट करती हैं, और यह सुनिश्चित करती हैं कि प्रत्येक कोड की लाइन का कोई उद्देश्य हो। अपने दृष्टिकोण को निरंतर सुधारते रहें, और कहानियों को अपने काम का मार्गदर्शन करने दें।