सॉफ्टवेयर विकास में अनुमान अक्सर उत्पाद मालिकों और इंजीनियरिंग टीमों के बीच घर्षण का कारण बनता है। जब कोई स्टोरी अस्पष्ट होती है, तो डेवलपर्स सटीक प्रयास का अनुमान नहीं दे पाते। इससे अविश्वसनीय स्प्रिंट प्लानिंग, समय की पाबंदियों का उल्लंघन और टीम में निराशा होती है। मूल कारण कभी-कभी तकनीकी कौशल की कमी नहीं होता; यह आमतौर पर आवश्यकताओं में स्पष्टता की कमी होती है।
इस अंतर को पाटने के लिए, यूजर स्टोरी को सटीकता से लिखा जाना चाहिए। उन्हें डेवलपर को यह समझने के लिए पर्याप्त संदर्भ प्रदान करना चाहिए किक्या, औरक्यों, और कार्य की सीमाएं। यह गाइड यह समझाती है कि स्क्रम ढांचे के भीतर सटीक अनुमान को सुविधाजनक बनाने वाले यूजर स्टोरी कैसे तैयार किए जाएं, बिना बाहरी टूल्स या अतिरंजना पर निर्भर किए।
🤔 अनुमान क्यों विफल होते हैं
डेवलपर्स समय का अनुमान नहीं लगाते; वे प्रयास, जटिलता और जोखिम का अनुमान लगाते हैं। जब कोई यूजर स्टोरी अस्पष्ट होती है, तो अज्ञात चर जोखिम को बढ़ा देते हैं, जिससे अनुमान भी बढ़ जाता है। यहाँ कुछ सामान्य कारण दिए गए हैं कि स्टोरी को अनुमानित करना कठिन क्यों होता है:
- स्वीकृति मानदंडों की कमी:स्पष्ट सीमाओं के बिना, डेवलपर्स सबसे खराब स्थिति का अनुमान लगाते हैं।
- तकनीकी निर्भरता:वे स्टोरी जो अन्य टीमों के अधूरे कार्य पर निर्भर करती हैं, अनिश्चितता पैदा करती हैं।
- अस्पष्ट क्रियापद:“अप्टिमाइज़”, “बेहतर बनाएं”, या “सुधार” जैसे पदों में मापने योग्य परिणाम नहीं होते।
- अनुमानित ज्ञान:दस्तावेज़ीकृत संदर्भ के बजाय समुदायिक ज्ञान पर निर्भर रहना।
- बहुत सारी स्टोरी:बड़ी, एकरूप स्टोरी जो एक साथ बहुत अधिक क्षेत्र को कवर करती हैं।
जब कोई डेवलपर पूछता है, “लेकिन यह ठीक से कैसे काम करता है?”, तो वह स्टोरी अनुमान के लिए तैयार नहीं होती। लक्ष्य स्प्रिंट प्लानिंग चरण में स्पष्टीकरण प्रश्नों की आवश्यकता को कम करना है।
📐 अनुमानित स्टोरी के लिए INVEST मॉडल
INVEST मॉडल एक स्मृति सहायक है जो अच्छी यूजर स्टोरी को परिभाषित करने के लिए उपयोग किया जाता है। हालांकि इसे अक्सर उद्धृत किया जाता है, कई टीमेंछोटीऔरपरीक्षण योग्यपहलुओं को नजरअंदाज कर देती हैं, जो अनुमान के लिए महत्वपूर्ण हैं।
1. स्वतंत्र
स्टोरी को आदर्श रूप से स्वतंत्र होना चाहिए। यदि कोई स्टोरी किसी अन्य स्टोरी के पहले पूरा होने पर निर्भर करती है, तो टीम उसे अलग से अनुमानित नहीं कर सकती। निर्भरताएं अवरोध पैदा करती हैं। यदि कोई स्टोरी वास्तव में निर्भर है, तो उसे तब तक तोड़ा जाना चाहिए जब तक कि निर्भरता हल न हो जाए या स्टोरी इतनी छोटी न हो जाए कि उसे स्पाइक किया जा सके।
2. वार्तात्मक
स्टोरी अनुबंध नहीं हैं; वे एक संवाद के लिए स्थान हैं। हालांकि, संवाद को होना चाहिएपहले अनुमान। यदि किसी कहानी को बिना किसी तकनीकी चर्चा के स्थिर विनिर्देश के रूप में लिखा जाता है, तो यह डेवलपर को बेहतर समाधान प्रस्तावित करने की क्षमता को सीमित कर देता है, जो अनुमान को प्रभावित कर सकता है।
3. मूल्यवान
हर कहानी को अंतिम उपयोगकर्ता को मूल्य प्रदान करनी चाहिए। यदि कोई कहानी केवल तकनीकी बुनियादी ढांचे के लिए है और उपयोगकर्ता-मुख्य मूल्य नहीं है, तो यह एक तकनीकी कार्य है, उपयोगकर्ता कहानी नहीं। तकनीकी कार्यों के लिए अनुमान लगाने का अलग दृष्टिकोण आवश्यक है और स्प्रिंट को बढ़ने से बचाने के लिए सावधानी से संभाला जाना चाहिए।
4. अनुमानित योग्य
यह इस गाइड के लिए मुख्य आवश्यकता है। एक कहानी अनुमानित योग्य होती है यदि टीम को प्रयास निर्धारित करने के लिए पर्याप्त जानकारी है। इसका अर्थ है:
- उपयोगकर्ता प्रवाह स्पष्ट है।
- डेटा आवश्यकताओं को परिभाषित किया गया है।
- किनारे के मामलों पर विचार किया गया है।
- प्रदर्शन आवश्यकताओं को स्पष्ट किया गया है (उदाहरण के लिए, लोड समय)।
5. छोटा
आकार बढ़ने के साथ अनुमान की सटीकता कम हो जाती है। दो सप्ताह में पूरा होने वाली कहानी बहुत बड़ी है। इसे एक से तीन दिनों में पूरा होने वाली कहानियों में विभाजित किया जाना चाहिए। छोटी कहानियाँ जोखिम को कम करती हैं और अनुमान की बारीकियों को बेहतर बनाती हैं।
6. परीक्षण योग्य
यदि आप कहानी के लिए परीक्षण नहीं लिख सकते, तो आप स्वीकृति मानदंड परिभाषित नहीं कर सकते। यदि आप स्वीकृति मानदंड परिभाषित नहीं कर सकते, तो डेवलपर नहीं जान पाएगा कि कहानी कब पूरी हुई है। यह अनुमान को सीधे प्रभावित करता है क्योंकि ‘पूरा’ अंतिम रेखा है।
🛠 एक उच्च-गुणवत्ता वाली उपयोगकर्ता कहानी की संरचना
एक उपयोगकर्ता कहानी केवल एक शीर्षक से अधिक है। यह जानकारी का एक पैकेज है। यह सुनिश्चित करने के लिए कि डेवलपर प्रभावी ढंग से अनुमान लगा सकें, हर कहानी में निम्नलिखित तत्व होने चाहिए।
1. शीर्षक
शीर्षक वर्णनात्मक लेकिन संक्षिप्त होना चाहिए। इसमें मुख्य कार्यक्षमता का सारांश होना चाहिए।
- खराब: लॉगिन ठीक करें
- अच्छा:उपयोगकर्ताओं को ईमेल लिंक के माध्यम से पासवर्ड रीसेट करने की अनुमति दें
2. उपयोगकर्ता कथन
मानक प्रारूप है: “एक [भूमिका] के रूप में, मैं [विशेषता] चाहता हूँ, ताकि [लाभ] हो।” यह सुनिश्चित करता है कि टीम संदर्भ को समझ सके।
3. संदर्भ और पृष्ठभूमि
डेवलपर्स को व्यावसायिक संदर्भ जानना चाहिए। इस विशेषता को अब क्यों बनाया जा रहा है? क्या कोई नियामक आवश्यकता है? क्या यह किसी गंभीर बग के लिए ठीक है? संदर्भ डेवलपर्स को तकनीकी निर्णयों को प्राथमिकता देने में मदद करता है।
4. स्वीकृति मानदंड
यह अनुमान के लिए सबसे महत्वपूर्ण अनुभाग है। स्वीकृति मानदंड कार्य की सीमाओं को परिभाषित करते हैं। इन्हें ऐसे लिखा जाना चाहिए जो स्वचालित परीक्षण की अनुमति दे।
- दिया गया-जब-तब का उपयोग करें:यह संरचना अस्पष्टता को कम करती है।
- सीमांत स्थितियों को परिभाषित करें:यदि इंटरनेट बंद हो जाए तो क्या होगा? यदि इनपुट खाली है तो क्या होगा?
- डेटा निर्दिष्ट करें:क्या हम किसी मौजूदा डेटाबेस से डेटा खींच रहे हैं? क्या हम नए रिकॉर्ड बना रहे हैं?
📋 तुलना: अस्पष्ट बनाम स्पष्ट कहानियाँ
एक ऐसी कहानी और एक ऐसी कहानी के बीच का अंतर समझना महत्वपूर्ण है जो अनुमान में त्रुटि का कारण बनती है और जो स्पष्टता को सुविधाजनक बनाती है। नीचे दी गई तालिका इस अंतर को उजागर करती है।
| सुविधा | अस्पष्ट कहानी (अनुमान करना कठिन) | स्पष्ट कहानी (अनुमान करना आसान) |
|---|---|---|
| लक्ष्य | डैशबोर्ड की प्रदर्शन क्षमता में सुधार करें। | 1000 रिकॉर्ड के लिए डैशबोड लोड समय को 2 सेकंड से कम करने के लिए। |
| परिसर | बैकएंड को अनुकूलित करें। | खोज तालिका में ‘user_id’ कॉलम को इंडेक्स करें और शीर्ष 50 परिणामों को कैश करें। |
| स्वीकृति मानदंड | यह तेज होना चाहिए। | 1. लोड समय < 2 सेकंड। 2. 1000 रिकॉर्ड पर कोई त्रुटि नहीं। 3. मोबाइल दृश्य काम करता है। |
| निर्भरताएँ | कोई उल्लेख नहीं किया गया। | वर्तमान में बीटा में चल रहे एनालिटिक्स API तक पहुंच की आवश्यकता है। |
🧩 निर्भरताओं और जोखिमों का प्रबंधन
निर्भरताएँ अनुमान की दुश्मन हैं। यदि एक कहानी किसी अन्य टीम के API पर निर्भर है, तो अनुमान एक अनुमान है। इसे कम करने के लिए:
- शुरुआत में पहचानें:योजना के दौरान नहीं, बल्कि बैकलॉग परिष्करण के दौरान निर्भरताओं पर चर्चा करें।
- स्पाइक कहानियाँ बनाएं:यदि निर्भरता अज्ञात है, तो उसकी जांच के लिए एक कहानी बनाएं। स्पाइक एक समय-सीमित अनुसंधान कार्य है। यह कोड नहीं बनाता, लेकिन यह ज्ञान उत्पन्न करता है जो जोखिम को कम करता है।
- मॉक डेटा:यदि कोई बाहरी सेवा उपलब्ध नहीं है, तो एक मॉक प्रतिक्रिया संरचना पर सहमत हों। इससे विकास बिना रुकावट के आगे बढ़ सकता है।
- बाहरी निर्भरताएँ:यदि कोई कहानी किसी तीसरे पक्ष की सेवा पर निर्भर है, तो विवरण में लागत और विलंबता के प्रभावों को नोट करें।
🗣 संवाद की भूमिका
कहानी लिखना केवल आधा काम है। संवाद दूसरा आधा है। लिखित कहानी संवाद की याद दिलाती है, स्वयं संवाद नहीं।
पूर्व-योजना परिष्करण
स्प्रिंट योजना से पहले, टीम को बैकलॉग की समीक्षा करनी चाहिए। यह प्रश्न पूछने का समय है। यदि कोई डेवलपर कहानी में कोई अंतराल देखता है, तो उसे तुरंत चिह्नित करना चाहिए। परिष्करण के दौरान चिह्नित की गई कहानी अनुमान के लिए तैयार कहानी होती है।
स्पष्टीकरण प्रश्न
परिष्करण के दौरान विशिष्ट प्रश्नों के उत्तर दिए जाने चाहिए। उदाहरण के लिए:
- क्या इस विशेषता को सुलभ होना चाहिए?
- क्या कोई विशिष्ट सुरक्षा प्रोटोकॉल आवश्यक हैं?
- अधिकतम कितने उपयोगकर्ताओं की उम्मीद है?
- क्या हमें पुराने ब्राउज़रों का समर्थन करना होगा?
यदि इन उत्तरों को कहानी में दस्तावेज़ीकृत किया जाता है, तो अनुमान अधिक विश्वसनीय हो जाता है।
📊 अनुमान तकनीकों को समझना
एक बार कहानी स्पष्ट हो जाने के बाद, टीम को अनुमान लगाने के लिए एक विधि की आवश्यकता होती है। विधि स्वयं उस सहमति से कम महत्वपूर्ण है जो वह बनाती है।
कहानी बिंदु
कहानी बिंदु सापेक्ष प्रयास, जटिलता और जोखिम को मापते हैं। वे घंटे नहीं हैं। कहानी बिंदुओं का उपयोग करने से टीमों को व्यक्ति की गति के बजाय कार्य के आकार पर ध्यान केंद्रित करने की अनुमति मिलती है।
- जटिलता:तर्क कितना कठिन है?
- जोखिम:गलत होने की कितनी संभावना है?
- प्रयास:कितना कार्य शामिल है?
योजना पोकर
यह सहमति-आधारित तकनीक है। प्रत्येक डेवलबर एक कार्ड उठाता है जिस पर एक संख्या होती है। यदि संख्याएँ भिन्न होती हैं, तो उच्चतम और न्यूनतम अनुमानकर्ता अपने तर्क की व्याख्या करते हैं। यह छिपी हुई धारणाओं को उजागर करता है। उदाहरण के लिए, एक डेवलबर एकीकरण आवश्यकता के बारे में भूल गया हो सकता है, जबकि दूसरे ने माना कि यह पहले से ही बना दिया गया है।
🚫 टालने योग्य सामान्य गलतियाँ
अच्छे इरादों के साथ भी, टीम अक्सर ऐसे फंदों में फंस जाती है जो अनुमान की सटीकता को नष्ट कर देते हैं।
1. केवल ‘सुखद पथ’
केवल आदर्श परिदृश्य का वर्णन करने वाली कहानियाँ लिखना खतरनाक है। डेवलपर सुखद पथ के लिए अनुमान लगाएंगे, लेकिन वास्तविक कार्य में त्रुटि प्रबंधन शामिल है। स्वीकृति मानदंडों में हमेशा त्रुटि अवस्थाओं को शामिल करें।
2. गैर-कार्यात्मक आवश्यकताओं को अनदेखा करना
प्रदर्शन, सुरक्षा और स्केलेबिलिटी अक्सर अनदेखी कर दी जाती है। एक कहानी जो कहती है ‘एक उपयोगकर्ता बनाएं’ में 1 बिंदु लग सकता है। लेकिन एक कहानी जो कहती है ‘10,000 समवर्ती लॉगिन का समर्थन करने वाला एक उपयोगकर्ता बनाएं’ में 10 बिंदु लगेंगे। गैर-कार्यात्मक आवश्यकताओं को स्पष्ट रूप से बताएं।
3. विवरण को अत्यधिक जटिल बनाना
उपयोगकर्ता कहानी में तकनीकी विनिर्देश न लिखें। डेवलपर को यह जानने की आवश्यकता है किक्या बनाना है, न किकैसे बनाना है। यदि आप कहानी में डेटाबेस स्कीमा निर्दिष्ट करते हैं, तो आप डेवलपर को सर्वोत्तम समाधान चुनने की क्षमता सीमित कर देते हैं।
4. ‘पूर्ण’ की परिभाषा को छोड़ देना
‘पूर्ण’ की परिभाषा (DoD) हर कहानी पर लागू होती है। इसमें परीक्षण, कोड समीक्षा और दस्तावेज़ीकरण शामिल है। यदि DoD स्पष्ट नहीं है, तो अनुमान गलत होगा। अनुमान लगाने से पहले सुनिश्चित करें कि टीम यह सहमत हो कि ‘पूर्ण’ का क्या अर्थ है।
🔄 परिष्करण प्रक्रिया प्रवाह
अनुमानित कहानियों के निरंतर प्रवाह को बनाए रखने के लिए, इस प्रवाह का पालन करें।
- प्रारंभिक मसौदा: उत्पाद मालिक मूल विवरण के साथ कहानी लिखता है।
- तकनीकी समीक्षा: डेवलपर संभावना और छिपी जटिलता के लिए समीक्षा करते हैं।
- स्वीकृति मानदंडों का विस्तार: किनारे के मामलों और प्रतिबंध जोड़ें।
- निर्भरता जांच: सुनिश्चित करें कि कोई अवरोधक नहीं हैं।
- अंतिम अनुमान: टीम परिष्करण या योजना के दौरान कहानी बिंदु आवंटित करती है।
- सत्यापन: सुनिश्चित करें कि कहानी INVEST मानदंडों को पूरा करती है।
📈 अनुमान की सटीकता को मापना
समय के साथ, टीमों को अपने अनुमान की सटीकता पर नज़र रखनी चाहिए। यह किसी को दंडित करने के लिए नहीं है, बल्कि प्रक्रिया को बेहतर बनाने के लिए है।
- वेग ट्रैकिंग:कई स्प्रिंट्स के दौरान टीम के वेग पर नज़र रखें। यदि वेग बहुत अधिक उतार-चढ़ाव करता है, तो कहानियां संभवतः असंगत हैं।
- पूर्णता दर:क्या टीम ने सभी अनुमानित कहानियां पूरी कीं? यदि नहीं, तो क्या वे अवरोधित थे या कम अनुमानित थे?
- पुनः अनुमान की आवृत्ति:यदि स्प्रिंट के दौरान कहानियों को बार-बार पुनः अनुमानित किया जाता है, तो प्रारंभिक अनुमान में दोष था।
🛡 सुरक्षा और अनुपालन
नियामक उद्योगों के लिए, सुरक्षा और अनुपालन अनुमान का हिस्सा होते हैं। एक कहानी जो उपयोगकर्ता डेटा संभालती है, उसमें सार्वजनिक जानकारी प्रदर्शित करने वाली कहानी की तुलना में अलग प्रयास की आवश्यकता होती है। स्वीकार्यता मानदंडों में अनुपालन जांच शामिल करें।
- डेटा गोपनीयता:क्या कहानी में PII (व्यक्तिगत रूप से पहचान योग्य जानकारी) शामिल है?
- ऑडिट ट्रेल:क्या सिस्टम को यह लॉग करने की आवश्यकता है कि किसने परिवर्तन किए?
- एन्क्रिप्शन:क्या डेटा विश्राम अवस्था या संचरण अवस्था में एन्क्रिप्टेड है?
यदि इन आवश्यकताओं का उल्लेख नहीं किया जाता है, तो डेवलपर ऐसा समाधान बना सकता है जिसके बाद में बड़े पैमाने पर पुनर्लेखन की आवश्यकता होगी, जिससे प्रारंभिक अनुमान व्यर्थ हो जाएगा।
🧪 स्पाइक्स का महत्व
कभी-कभी, एक कहानी अनुमानित करने के लिए बहुत जोखिम भरी होती है। ऐसे मामलों में, स्पाइक का उपयोग करें। स्पाइक एक समय-सीमित जांच है। यह एक वितरणीय सुविधा नहीं है। यह एक सीखने वाली कार्य है।
उदाहरण:
- कहानी:पुराने पेमेंट गेटवे के साथ एकीकरण की संभावना की जांच करें।
- लक्ष्य:निर्धारित करें कि क्या गेटवे हमारी आवश्यक API संस्करण का समर्थन करता है।
- आउटपुट:निष्कर्ष और सिफारिशों के साथ एक दस्तावेज।
एक बार स्पाइक पूरा होने के बाद, वास्तविक सुविधा कहानी को निष्कर्षों के आधार पर अनुमानित किया जा सकता है। इससे जोखिम काफी कम हो जाता है।
🤝 QA के साथ सहयोग
गुणवत्ता सुनिश्चित करने (QA) को परिष्करण प्रक्रिया में शामिल होना चाहिए। डेवलपर ऐसे किनारे के मामलों को छूट सकते हैं जिन्हें टेस्टर पकड़ते हैं। QA परीक्षण के दृष्टिकोण से स्वीकार्यता मानदंड लिखने में मदद कर सकता है। यह सुनिश्चित करता है कि कहानी वास्तव में परीक्षण योग्य है, जो अनुमान का एक प्रमुख घटक है।
📉 स्कोप क्रिप प्रबंधन
स्कोप क्रिप तब होता है जब अनुमान के बाद आवश्यकताएं बदल जाती हैं। इसे रोकने के लिए:
- फ्रीज मानदंड:एक बार अनुमानित होने के बाद, पुनः अनुमान के बिना स्वीकार्यता मानदंड नहीं बदले जाने चाहिए।
- परिवर्तन अनुरोध:यदि किसी परिवर्तन की आवश्यकता है, तो उसे लॉग किया जाना चाहिए और बैकलॉग में जोड़ा जाना चाहिए, वर्तमान स्प्रिंट में जबरदस्ती नहीं किया जाना चाहिए।
- पारदर्शिता:यदि कोई परिवर्तन अपरिहार्य है, तो तुरंत स्प्रिंट लक्ष्य पर प्रभाव को संचारित करें।
🧠 ज्ञान साझा करना
अनुमान एक टीम का खेल है। जूनियर डेवलपर सीनियरों की तुलना में अलग तरह से अनुमान लगा सकते हैं। टीम को एलाइन करने के लिए:
- कैलिब्रेशन सत्र:नियमित रूप से पिछली कहानियों की समीक्षा करें ताकि यह कैलिब्रेट किया जा सके कि एक ‘5’ कैसा दिखता है बनाम एक ’13’।
- पेयर प्रोग्रामिंग:ज्ञान साझा करने और अनुमान में भिन्नता कम करने के लिए जटिल कहानियों के लिए पेयर प्रोग्रामिंग का उपयोग करें।
- दस्तावेज़ीकरण:भविष्य के अनुमानों के लिए संदर्भ बिंदु के रूप में पिछली कहानियों की एक लाइब्रेरी बनाए रखें।
🌟 स्पष्टता पर अंतिम विचार
वे उपयोगकर्ता कहानियाँ लिखना जिन्हें डेवलपर आसानी से अनुमान लगा सकें, सहानुभूति का अभ्यास है। इसमें उत्पाद मालिक को इंजीनियर के कदमों में कदम रखने और उनके प्रश्नों की पूर्वानुमान करने की आवश्यकता होती है। इसमें इंजीनियर को तब बोलने की आवश्यकता होती है जब जानकारी अनुपलब्ध होती है। जब दोनों पक्ष मिलकर अस्पष्टता को दूर करने के लिए सहयोग करते हैं, तो अनुमान योजना के लिए एक विश्वसनीय उपकरण बन जाता है।
परिणाम केवल सटीक संख्याएँ नहीं हैं। यह विश्वास है। जब टीम स्पष्ट मानदंडों के आधार पर कहानियों के सेट के लिए प्रतिबद्ध होती है, तो वे आत्मविश्वास के साथ वितरण कर सकती हैं। ध्यान अनुमान लगाने से निर्माण करने की ओर बदल जाता है।
🔑 मुख्य निष्कर्ष
- स्पष्टता राजा है:एक स्पष्ट कहानी एक अनुमानित कहानी है।
- स्वीकृति मानदंड:सीमाओं और किनारे के मामलों को स्पष्ट रूप से परिभाषित करें।
- निर्भरताएँ:योजना से पहले जोखिमों की पहचान करें और उन्हें कम करें।
- संवाद:अनुमान लगाने से पहले विवरण पर चर्चा करने के लिए परिष्करण का उपयोग करें।
- छोटी कहानियाँ:सटीकता बढ़ाने के लिए बड़े काम को तोड़ें।
- निरंतर सुधार:वेग को ट्रैक करें और समय के साथ प्रक्रिया को समायोजित करें।
इन सिद्धांतों का पालन करके, टीमें अपनी स्प्रिंट योजना को एक अनुमान खेल से एक संरचित, पूर्वानुमान योग्य प्रक्रिया में बदल सकती हैं। अच्छी कहानियाँ लिखने में निवेश किया गया प्रयास उसके बाद आने वाली हर स्प्रिंट में मुनाफा देता है।