उपयोगकर्ता कहानियाँ लिखना किसी भी सॉफ्टवेयर इंजीनियर के लिए एक मूलभूत कौशल है जो एजाइल परिवेश में प्रवेश कर रहा है। जबकि बहुत से टीमें कार्यों के प्रबंधन के लिए डिजिटल प्लेटफॉर्म पर निर्भर होती हैं, बिना सॉफ्टवेयर निर्भरता के उपयोगकर्ता कहानी के मूल तत्वों को समझना एक मजबूत आधार बनाता है। यह गाइड मैन्युअल प्रक्रिया पर केंद्रित है, जिसमें स्टिकी नोट्स, व्हाइटबोर्ड और इंडेक्स कार्ड जैसे भौतिक सामग्री का उपयोग करके स्पष्ट, कार्यान्वयन योग्य आवश्यकताओं का निर्माण किया जाता है। लक्ष्य स्क्रीन की सुविधा के बजाय विचार की स्पष्टता है।
जब आप सॉफ्टवेयर को हटा देते हैं, तो आपको सामग्री के साथ गहराई से जुड़ने के लिए मजबूर किया जाता है। कोई ऑटो-कंप्लीट फीचर या पूर्व-निर्धारित टेम्पलेट नहीं है जिसके पीछे छुपा जा सके। आपको मूल्य, क्रियाकलाप करने वाला व्यक्ति और आवश्यकता को स्पष्ट रूप से व्यक्त करना होगा। यह मैन्युअल अनुशासन सुनिश्चित करता है कि टीम को कोड की एक भी पंक्ति लिखने से पहले समस्या के क्षेत्र को समझने की आवश्यकता हो। नीचे, हम कहानी के अनातम, स्वीकृति के मापदंडों और डिजिटल सहायता के बिना विचारों को बेहतर बनाने के तरीकों का अध्ययन करते हैं।
📖 मूल अवधारणा को समझना
एक उपयोगकर्ता कहानी एक ऐसी हल्की विवरण है जो नई क्षमता की आवश्यकता वाले व्यक्ति के दृष्टिकोण से बताई जाती है, जो आमतौर पर सिस्टम का उपयोगकर्ता या ग्राहक होता है। यह एक विवरणात्मक दस्तावेज नहीं है। यह एक बातचीत के लिए एक स्थान रखने वाला है। कार्ड या कागज पर कहानी लिखने की भौतिक क्रिया इस इरादे को मजबूत करती है। इसे हटाया, संपादित किया, छोड़ा या जोड़ा जा सकता है। डिजिटल प्रणालियाँ अक्सर बहुत जल्दी आपको एक कठोर संरचना में फंसा देती हैं। मैन्युअल तरीके कहानी को लचीला रखते हैं।
मैन्युअल क्यों करें?
कहानियाँ लिखने के लिए मैन्युअल तरीके का अभ्यास करने के कई प्रभावशाली कारण हैं, खासकर नए इंजीनियरों के लिए:
- मूल्य पर ध्यान केंद्रित करें: भरने के लिए क्षेत्रों के बिना, आप वास्तविक मूल्य प्रस्ताव पर ध्यान केंद्रित करते हैं।
- मनोवैज्ञानिक भार: हाथ से लिखने से आप धीमे हो जाते हैं, जिससे आप टेक्स्ट में जुड़ने से पहले सोचने का समय मिलता है।
- सहयोग: भौतिक कार्ड टीमों को कार्य को भौतिक रूप से फिर से व्यवस्थित करने की अनुमति देते हैं, जिससे प्रवाह और प्राथमिकता को दृश्यमान बनाया जा सकता है।
- स्वतंत्रता: आप इस फॉर्मेट को इतना अच्छी तरह सीखते हैं कि यदि उपकरण उपलब्ध नहीं हैं तो भी आप वैध आवश्यकताएं लिख सकते हैं।
📋 मैन्युअल कहानी का अनातम
प्रत्येक उपयोगकर्ता कहानी एक विशिष्ट संरचना का पालन करती है। जब मैन्युअल रूप से लिखते हैं, तो अपने इंडेक्स कार्ड या स्टिकी नोट्स पर एक स्थिर फॉर्मेट का उपयोग करें। इस स्थिरता से टीम को योजना बनाने के सत्रों के दौरान जानकारी को तेजी से स्कैन करने में मदद मिलती है। मानक फॉर्मेट में तीन अलग-अलग भाग होते हैं। इनमें से किसी को भी छोड़ें नहीं।
1. पर्सना (कौन)
विशिष्ट भूमिका या उपयोगकर्ता के प्रकार की पहचान करें। सामान्य शब्दों जैसे ‘उपयोगकर्ता’ का उपयोग न करें। सटीक रहें। क्या यह ‘प्रशासक’, ‘अतिथि दर्शक’ या ‘प्रीमियम सदस्य’ है? पर्सना विशेषता के अधिकारों और संदर्भ को निर्धारित करती है।
2. क्रिया (क्या)
उपयोगकर्ता द्वारा किए जाने वाले क्षमता या क्रिया का वर्णन करें। यह क्रिया शब्द है। यह एक उच्च स्तरीय लक्ष्य होना चाहिए, तकनीकी कार्यान्वयन विवरण नहीं। उदाहरण के लिए, ‘आइटम खोजें’ का अर्थ ‘SQL डेटाबेस में प्रश्न इनपुट करना’ से बेहतर है। क्रिया उपयोगकर्ता के इरादे का प्रतिनिधित्व करती है।
3. लाभ (ताकि)
यह सबसे महत्वपूर्ण भाग है जो अक्सर नए लोग छोड़ देते हैं। उपयोगकर्ता को इसकी आवश्यकता क्यों है? इससे क्या मूल्य मिलता है? यदि आप इसका उत्तर नहीं दे सकते हैं, तो कहानी मूल्यहीन हो सकती है। ‘ताकि’ वाक्य विशेषता को व्यावसायिक या उपयोगकर्ता परिणाम से जोड़ता है।
उदाहरण संरचना
इसे एक या दो पंक्तियों में लिखें। संक्षिप्त रखें।
- एक रूप में [पर्सना],
- मैं चाहता हूँ [क्रिया],
- ताकि [लाभ].
📝 स्वीकृति मानदंड को परिभाषित करना
एक कहानी के बिना स्वीकृति मानदंड के पूरी नहीं होती है। ये वे शर्तें हैं जिन्हें पूरा करने की आवश्यकता होती है ताकि कहानी को पूरा माना जा सके। जब हाथ से लिखा जाता है, तो इन्हें कहानी कार्ड के ठीक नीचे या उससे जुड़े अलग शीट पर सूचीबद्ध किया जाना चाहिए। ये इंजीनियरिंग कार्य के लिए परीक्षण मामलों के रूप में कार्य करते हैं।
स्वीकृति मानदंड अस्पष्टता को दूर करते हैं। वे फीचर की सीमाओं को परिभाषित करते हैं। उनके बिना, दो इंजीनियर एक ही कहानी के लिए अलग-अलग समाधान बना सकते हैं। हाथ से लिखने से आपको विकास शुरू होने से पहले किन्हीं भी सीमा मामलों पर विचार करने के लिए मजबूर किया जाता है।
दिया गया/जब/तब प्रारूप
सटीक मानदंड के लिए, दिया गया/जब/तब संरचना का उपयोग करें। यह व्यवहार-आधारित विकास (BDD) का हाथ से अनुवाद है। यह तर्क को स्पष्ट रूप से संरचित करता है।
- दिया गया: प्रारंभिक संदर्भ या स्थिति।
- जब: घटना या किया गया क्रियान्वयन।
- तब: अपेक्षित परिणाम।
उदाहरण मानदंड
- दिया गया कि उपयोगकर्ता लॉग इन है,
- जब वे लॉग आउट बटन पर क्लिक करते हैं,
- तब उन्हें लैंडिंग पेज पर पुनर्निर्देशित किया जाता है।
- जब वे लॉग आउट बटन पर क्लिक करते हैं,
मानदंड प्रकारों की सारणी
विभिन्न प्रकार के मानदंड मौजूद हैं। एक सारणी इन्हें हाथ से लिखने के प्रक्रिया के दौरान वर्गीकृत करने में मदद करती है।
| प्रकार | विवरण | उदाहरण |
|---|---|---|
| कार्यात्मक | प्रणाली का विशिष्ट व्यवहार | “प्रणाली फॉर्म सबमिशन के बाद ईमेल भेजती है” |
| गैर-कार्यात्मक | प्रदर्शन या सुरक्षा सीमाएं | “पृष्ठ 2 सेकंड से कम में लोड होता है” |
| व्यावसायिक तर्क | डेटा के नियम | “छूट केवल $50 से अधिक के आदेशों पर लागू होती है” |
| उपयोगिता | उपयोग में आसानी की आवश्यकताएं | “बटन को स्क्रॉल किए बिना दिखाई देना चाहिए” |
🌐 INVEST मॉडल के साथ प्रमाणीकरण
जब आप एक कहानी को हाथ से लिख लेते हैं, तो आपको इसकी गुणवत्ता की पुष्टि करनी होगी। INVEST मॉडल इसके लिए मानक ढांचा है। आप एक अलग कागज के शीट पर एक चेकलिस्ट का उपयोग कर सकते हैं ताकि प्रत्येक कहानी का मूल्यांकन बैकलॉग में जोड़ने से पहले किया जा सके। इससे यह सुनिश्चित होता है कि काम प्रबंधनीय और मूल्यवान हो।
स्वतंत्र
कहानी स्वतंत्र होनी चाहिए। इसके लिए दूसरी कहानी के पहले पूरा होने पर निर्भर नहीं होना चाहिए। तकनीकी निर्भरता हो सकती है, लेकिन मूल्य स्वतंत्र रूप से खड़ा होना चाहिए। यदि आपको कहानी A के बनने का इंतजार करना है कहानी B बनाने के लिए, तो विचार करें कि कहानी B को छोटे-छोटे हिस्सों में बांटा जा सकता है या नहीं।
चर्चा योग्य
कहानी चर्चा करने का वादा है, न कि एक अनुबंध। इससे इंजीनियर और हितधारक के बीच बातचीत की अनुमति मिलती है। यदि पाठ बहुत विस्तृत है, तो यह एक विवरण बन जाता है, कहानी नहीं। तकनीकी खोज के लिए जगह छोड़ें।
मूल्यवान
प्रत्येक कहानी को उपयोगकर्ता या व्यवसाय को मूल्य प्रदान करना चाहिए। यदि कोई कहानी “ताकि” आवश्यकता को प्रभावी ढंग से पूरा नहीं करती है, तो उसे छोड़ देना या फिर दोबारा काम करना चाहिए। मूल्य बैकलॉग के प्राथमिक इंजन है।
आकलन योग्य
टीम को आवश्यक प्रयास का आकलन करने में सक्षम होना चाहिए। यदि कहानी बहुत अस्पष्ट है, तो इसका आकलन नहीं किया जा सकता है। यदि यह बहुत जटिल है, तो इसे छोटे-छोटे हिस्सों में बांटें। हाथ से लिखना अस्पष्टता को पहचानने में मदद करता है क्योंकि आपको विवरणों को शारीरिक रूप से लिखना होता है।
छोटी
एक कहानी को इतनी छोटी होना चाहिए कि एक ही इटरेशन या स्प्रिंट के भीतर पूरा किया जा सके। बड़ी कहानियां जोखिम भरी होती हैं। वे अक्सर अपूर्ण काम की ओर ले जाती हैं। यदि कहानी को प्रोजेक्ट की तरह महसूस होता है, तो उसे छोटी, क्रमिक कहानियों में बांटें।
परीक्षण योग्य
आपको यह सत्यापित करने में सक्षम होना चाहिए कि कहानी पूरी हो गई है। यदि स्वीकृति मानदंड नहीं हैं, तो कहानी परीक्षण योग्य नहीं है। हाथ से लिखना आपको स्पष्ट रूप से यह परिभाषित करने के लिए मजबूर करता है कि “पूरा” कैसा दिखता है।
INVEST चेकलिस्ट
योजना बनाते समय अपनी कहानियों की समीक्षा करने के लिए इस तालिका का उपयोग करें।
| अक्षर | पूछने के लिए प्रश्न | स्थिति |
|---|---|---|
| आई | क्या इसे दूसरों के बिना विकसित किया जा सकता है? | [ ] |
| एन | क्या सीमा चर्चा के लिए खुली है? | [ ] |
| वी | क्या यह स्पष्ट मूल्य प्रदान करता है? | [ ] |
| ई | क्या हम प्रयास का अनुमान लगा सकते हैं? | [ ] |
| एस | क्या इसे एक स्प्रिंट में फिट किया जा सकता है? | [ ] |
| टी | क्या स्पष्ट पास/फेल की शर्तें हैं? | [ ] |
🔍 रिफाइनमेंट प्रक्रिया
रिफाइनमेंट, जिसे ग्रूमिंग भी कहा जाता है, भविष्य के विकास के लिए कहानियों को तैयार करने की गतिविधि है। रिफाइन करने के लिए आपको सॉफ्टवेयर की आवश्यकता नहीं है। वास्तव में, टेबल पर कार्डों को हल्के से घुमाने की भौतिक क्रिया प्रवाह की समझ में सुधार कर सकती है। एक रिफाइनमेंट सत्र में कहानियों की समीक्षा करना, विवरण स्पष्ट करना और बड़े आइटम को छोटे आइटम में बांटना शामिल होता है।
चरण 1: समीक्षा
एक बड़ी मेज के चारों ओर टीम को इकट्ठा करें। कार्ड बिछाएं। प्रत्येक कहानी को आवाज में पढ़ें। यह सरल क्रिया उन त्रुटियों को पकड़ती है जो चुपचाप पढ़ने पर अदृश्य होती हैं। ‘ताकि’ खंड में अस्पष्टता के लिए ध्यान दें।
चरण 2: विभाजन
अगर कोई कार्ड बहुत भारी लगता है, तो उसे काट दें। नई, छोटी कहानी को एक नए कार्ड पर लिखें। नए कार्ड को मूल कार्ड के ऊपर या एक ओर रखें। सुनिश्चित करें कि मूल कार्ड को विभाजन को दर्शाते हुए अपडेट किया गया हो। इस दृश्य अलगाव स्कोप को प्रबंधित करने में मदद करता है।
चरण 3: प्रश्न
समीक्षा के दौरान, टीम प्रश्न पूछती है। इन प्रश्नों को अलग शीट पर लिखें। तुरंत उनके उत्तर न दें। प्रश्न ज्ञान की कमी को दर्शाते हैं। वे अगले सत्र के लिए कार्य बिंदु बन जाते हैं। इससे योजना बनाने और उत्तर देने में अंतर बनता है।
चरण 4: क्रमबद्धता
कार्डों को निर्भरता या मूल्य के क्रम में व्यवस्थित करें। जोड़ाव को दर्शाने के लिए मेज पर धागा या टेप का उपयोग करें। यदि कार्ड ए को कार्ड बी से पहले होना चाहिए, तो उनके बीच एक रेखा खींचें। इस दृश्य प्रवाह विकास शुरू होने से पहले बाधाओं को पहचानने में मदद करता है।
📈 प्राथमिकता निर्धारण तकनीकें
जब आपके पास कहानियों की सूची हो जाती है, तो आपको यह तय करना होता है कि सबसे पहले क्या बनाना है। हाथ से प्राथमिकता निर्धारण विधियां आमतौर पर डिजिटल व्यवस्था से अधिक प्रभावी होती हैं क्योंकि इनमें काम के साथ भौतिक बातचीत शामिल होती है।
मोस्को विधि
अपने कार्डों को रंगीन करें या अलग-अलग आकृतियों का उपयोग करके प्राथमिकता को दर्शाएं। यह एक प्राचीन हाथ से तकनीक है।
- एम – अनिवार्य होना चाहिए:रिलीज के लिए महत्वपूर्ण। कोई भी छूट नहीं।
- एस – अच्छा होगा:महत्वपूर्ण लेकिन आवश्यक नहीं। आवश्यकता पड़ने पर टाला जा सकता है।
- सी – अगर संभव हो तो:इच्छनीय लेकिन आवश्यक नहीं।
- W – नहीं करने वाले: वर्तमान दायरे से बाहर रहने के लिए सहमति व्यक्त की।
भारित सबसे छोटे कार्य पहले (WSJF)
एक अधिक गणितीय दृष्टिकोण के लिए, मूल्य और समय के लिए संख्याएँ निर्धारित करें। संख्याएँ कार्ड पर लिखें। अनुपात की गणना हाथ से करें। इससे टीम को मूल्य को मापने के लिए मजबूर किया जाता है, बजाय अनुभव पर भरोसा करने के। यह नए इंजीनियरों के लिए व्यापारिक विकल्पों को समझने के लिए एक मूल्यवान अभ्यास है।
⚠️ बचने के लिए सामान्य गलतियाँ
हाथ से लिखने के तरीके के साथ भी, गलतियाँ होती हैं। नए इंजीनियर अक्सर सॉफ्टवेयर सत्यापन के निर्देश के बिना कहानियाँ लिखते समय विशिष्ट जाल में फंस जाते हैं।
1. तकनीकी भाषा
कहानियाँ प्रणाली के दृष्टिकोण से न लिखें। “डेटाबेस,” “एपीआई,” या “बैकएंड” जैसे शब्दों से बचें। उपयोगकर्ता के दृष्टिकोण से लिखें। प्रणाली उपयोगकर्ता के लिए अदृश्य है। यदि आप लिखते हैं कि “प्रणाली कैश को अपडेट करती है,” तो उपयोगकर्ता को इसकी चिंता नहीं होती है। उन्हें पृष्ठ की गति की चिंता होती है।
2. स्वीकृति मानदंड की कमी
“मैं एक… के रूप में” भाग लिखना आसान है और “ताकि…” या मानदंड को भूल जाना। मानदंडों के बिना कहानी एक टो-डू लिस्ट आइटम है, उपयोगकर्ता कहानी नहीं। इससे अस्पष्टता उत्पन्न होती है। कार्ड को पूरा माने जाने से पहले हमेशा मानदंडों की आवश्यकता होती है।
3. अत्यधिक विवरण
कहानी लिखना विवरण लिखने के बराबर नहीं है। यदि आप एक कार्ड पर पांच पैराग्राफ लिखते हैं, तो आपने शायद अत्यधिक विवरण दे दिया है। कार्ड को छोटा रखें। विवरण बुनियादी बातचीत में होने चाहिए, कार्ड पर नहीं।
4. किनारे के मामलों को नजरअंदाज करना
हाथ से लिखने में अक्सर खुशहाल रास्ते पर ध्यान केंद्रित किया जाता है। आपको स्पष्ट रूप से लिखना होगा कि जब चीजें गलत हो जाएँ तो क्या होता है। त्रुटि स्थितियों के लिए मानदंड जोड़ें। “दिया गया नेटवर्क बंद है, जब उपयोगकर्ता जमा करता है, तो वे एक पुनर्प्रयास संदेश देखते हैं।”
5. सहयोग की कमी
अकेले कहानी लिखना समय की बर्बादी है। कहानियाँ बातचीत की शुरुआत करने वाली होती हैं। यदि आप किसी सहकर्मी के साथ चर्चा किए बिना कहानी लिखते हैं, तो यह गलत तरीके से समझी जाने की संभावना है। हमेशा सहकर्मी के साथ हाथ से समीक्षा करें।
👩💻 बाद में डिजिटल में संक्रमण
जब तक यह मार्गदर्शिका हाथ से तरीकों पर केंद्रित है, टीम अंततः ट्रैकिंग और रिपोर्टिंग के लिए डिजिटल प्रणालियों में स्थानांतरित हो जाती है। आप यहाँ सीखी गई कौशल सीधे स्थानांतरित होते हैं। जब आप अंततः एक डिजिटल प्लेटफॉर्म का उपयोग करेंगे, तो आप बेहतर कहानियाँ लिखेंगे क्योंकि आप मूल संरचना को समझते हैं। आप सॉफ्टवेयर पर निर्भर नहीं रहेंगे जो आपके लिए मूल्य निर्धारित करे।
यदि आधार ठोस है, तो संक्रमण आसान होता है। डिजिटल उपकरण उस हाथ से काम के भंडार के रूप में बन जाता है जिसे आप पहले सोच चुके हैं। आप बस कार्ड की सामग्री को प्रणाली में कॉपी कर देते हैं। तर्क वही रहता है।
📝 नए इंजीनियरों के लिए व्यावहारिक अभ्यास
इन अवधारणाओं को मजबूत करने के लिए निम्नलिखित अभ्यास करें। इसमें कोई सॉफ्टवेयर की आवश्यकता नहीं है, केवल कागज और पेन की आवश्यकता है।
- चरण 1: एक ऐसी सुविधा चुनें जिसका आप दैनिक उपयोग करते हैं (उदाहरण के लिए, वेबसाइट पर एक खोज बार)।
- चरण 2: मानक प्रारूप का उपयोग करके उपयोगकर्ता कहानी एक इंडेक्स कार्ड पर लिखें।
- चरण 3: दिया गया/जब/तो के उपयोग से तीन स्वीकृति मानदंड लिखें।
- चरण 4: कार्ड पर INVEST मॉडल चेकलिस्ट का उपयोग करें।
- चरण 5: कहानी के बारे में दो प्रश्न लिखें जो एक डेवलपर पूछ सकता है।
- चरण 6: सहकर्मी के साथ कार्ड की समीक्षा करें। उनसे ‘ताकि’ खंड का मूल्यांकन करने के लिए कहें।
💬 मैनुअल अनुशासन पर अंतिम विचार
उपयोगकर्ता कहानी के कला को समझना सटीकता और सहानुभूति के बारे में है। इसमें आपको उपयोगकर्ता के जूतों में खड़े होने की आवश्यकता होती है। इसमें स्पष्ट और संक्षिप्त होने की आवश्यकता होती है। मैनुअल प्रक्रिया सॉफ्टवेयर इंटरफेस की आवाज़ को दूर कर देती है और केवल संदेश छोड़ देती है। यह अनुशासन आपको बेहतर इंजीनियर बनाता है। यह आपको बेहतर संचारक बनाता है।
जब आप उपकरणों को हटा देते हैं, तो आपके पास केवल तर्क बचता है। यही तर्क सॉफ्टवेयर को आगे बढ़ाता है। मैनुअल रूप से अभ्यास करके आप यह सुनिश्चित करते हैं कि आपका तर्क कंप्यूटर को इसे क्रियान्वित करने के पहले सही है। इस दृष्टिकोण से पुनरावृत्ति कम होती है और गुणवत्ता बढ़ती है। यह आपके मूल्य को परिभाषित करने की क्षमता पर एक शांत आत्मविश्वास है।
याद रखें, लक्ष्य डिजिटल बैकलॉग भरना नहीं है। लक्ष्य किसी व्यक्ति की समस्या का समाधान करना है। मानव को लूप में रखें। कहानी को सरल रखें। मापदंड स्पष्ट रखें। ये सिद्धांत आपके लिए अच्छे काम करेंगे, चाहे आप अंततः किसी भी उपकरण का उपयोग करें।
📊 मुख्य बातों का सारांश
- रूपरेखा: हमेशा ‘एक रूप में / मैं चाहता हूँ / ताकि’ का उपयोग करें।
- मापदंड: स्पष्टता के लिए दिए गए/जब/तब को परिभाषित करें।
- सत्यापन: अंतिम रूप देने से पहले INVEST के विरुद्ध जांच करें।
- सहयोग: टीम के साथ भौतिक रूप से कार्डों की समीक्षा करें।
- फोकस: तकनीकी कार्यान्वयन की तुलना में उपयोगकर्ता मूल्य को प्राथमिकता दें।