क्या प्रलेखन एक उपयोगकर्ता कहानी है? [बन्द है]

Question

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

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

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

Comments

क्या आप सिस्टम प्रलेखन बनाने के लिए एक उपयोगकर्ता कहानी बनाने के बारे में सोच रहे हैं, या सिस्टम के प्रलेखन के रूप में एक उपयोगकर्ता कहानी का उपयोग कर रहे हैं?

— रायथल

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

— DXM

यदि आप किसी भी कोड को लिखे बिना उपयोगकर्ता कहानी के लिए पूरा कर सकते हैं और भुगतान कर सकते हैं, तो उस पर कूदें।

— जेएफओ

@ जेफ़ो - मैं बहुत कुछ कोड धन्यवाद लिखूँगा। शायद मैं प्रलेखन लिखने के लिए कोड लिख सकता हूं ... एक लाइट वॉन न्यूमैन मशीन की तरह: पी

— सोयलेंटग्रे

Answer 1

"एक्स के उपयोगकर्ता के रूप में, मुझे यह जानना होगा कि एक्स कैसे काम करता है" मुझे एक वैध उपयोगकर्ता कहानी की तरह लगता है। इसके परिणामस्वरूप लिखित दस्तावेज या ऑनलाइन मदद मिल सकती है।

बिंदु सिर्फ कोड नहीं है - यह उपयोगकर्ताओं की आवश्यकताओं को पूरा कर रहा है।

Comments

ऑपरेटर, प्रशासक और अन्य तकनीकी लोग प्रथम श्रेणी के उपयोगकर्ता हैं। उन्हें हर दूसरे यूजर की तरह ही यूजर स्टोरी मिलती है।

— एस.लॉट

Answer 2

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

आप सही हैं, यह किसी भी कोड का उत्पादन नहीं करता है। लेकिन यह एक उपयोगकर्ता की आवश्यकता को पूरा करता है और अन्य उपयोगकर्ता आवश्यकताओं के खिलाफ प्राथमिकता दी जानी चाहिए।

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

Comments

यदि दस्तावेज़ीकरण की आवश्यकता है, तो अंततः यह काम की परिभाषा का हिस्सा बन सकता है।

— ह्यूगो

Answer 3

मैं पीडीआर के प्रलेखन मूल्यांकन से सहमत हूं यदि इसकी आवश्यकता, तकनीकी या परियोजना प्रलेखन के बारे में है। आदर्श रूप से इसे स्प्रिंट कार्य में शामिल किया जाना चाहिए।

उत्पाद का दस्तावेज़ीकरण मुझे लगता है कि यह एक बहुत ही भिन्न है क्योंकि यह एक वास्तविक उपयोगकर्ता है जो अनुरोधित है और उपयोगकर्ता को सीधे मूल्य प्रदान करता है। यह निश्चित रूप से समझा जाना चाहिए कि उत्पाद दस्तावेज़ीकरण अनिवार्य रूप से तकनीकी कार्य नहीं है, लेकिन एक कार्यात्मक कार्य है, और परियोजना पर तकनीकी संसाधन के लिए एक उपयुक्त गतिविधि हो सकती है या नहीं भी हो सकती है।

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

Answer 4

हमारे संगठन में, टूलींग टीम, हमारे निरंतर एकीकरण प्रणाली को बनाए रखने और बढ़ाने के प्रभारी, उन्हें अपने काम का प्रबंधन करने में मदद करने के लिए स्क्रम का उपयोग कर रहा है। वे कोड नहीं लिख रहे हैं, लेकिन वे फिर भी स्क्रम का अभ्यास कर रहे हैं।

विशेष रूप से आपके प्रश्न का उत्तर देने के लिए, मैं पूछूंगा कि क्या टीम यह मानती है कि प्रलेखन "डेऑन की परिभाषा" का हिस्सा है या नहीं।

यदि टीम मानती है कि प्रलेखन "की गई परिभाषा" का हिस्सा है, तो अतिरिक्त कहानी की कोई आवश्यकता नहीं है और कहानी को तब तक स्वीकार नहीं किया जा सकता जब तक कि दस्तावेज लिखा और मान्य नहीं किया जाता है।

यदि टीम का मानना ​​है कि प्रलेखन "की गई परिभाषा" का हिस्सा नहीं है, तो मैं एक अलग कहानी बनाऊंगा ताकि उत्पाद स्वामी अपने काम का प्रबंधन कर सकें।