प्रयोक्ता कहानी

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

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

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

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

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

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

कहानियाँ जमा होकर ढेर लगा देती हैं, जिन्हें अगर समय रहते छाँटा न जाए तो संभालना मुश्किल हो जाता है। कई महीने पहले लिखी गई चीज़ें एक ऐसे उत्पाद और बाज़ार का वर्णन करती हैं जो तब से बदल चुके हैं, और सैकड़ों कहानियों का ढेर एक ऐसा दस्तावेज़ बन जाता है जिसे कोई पढ़ता नहीं, न कि कोई योजना। समय-समय पर उन कहानियों को हटाना जिन्हें असल में बनाया नहीं जा सकता, असुविधाजनक तो है, लेकिन उन्हें अनिश्चित काल तक बनाए रखने से कहीं ज़्यादा उपयोगी है।

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