उपयोगकर्ता की कहानी का एक अभिनेता इंसान होना चाहिए?

Question

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

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

Answer 1

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

Answer 2

मैं नहीं दिख रहा है यही कारण है कि एक अभिनेता के एक मानव होने का होना चाहिए - अपने उदाहरण यह होने के लिए नहीं के लिए एक पूरी तरह से अच्छा कारण है।

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

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

Answer 3

यहां रहस्य है। वे उपयोगकर्ता कहानियां नहीं हैं, लेकिन वे उपयोगकर्ता परिदृश्य हैं।

उपयोगकर्ता बातचीत करने वाली चीज है - मशीन, या एक व्यक्ति।

स्टेकहोल्डर व्यक्ति या निगम को बातचीत से लाभ प्राप्त होता है (यह कभी मशीन नहीं है, वैसे भी एआई विकास में इस चरण में नहीं)। आमतौर पर किसी भी परियोजना के लिए प्रतिस्पर्धी जरूरतों के साथ कई हितधारकों हैं। प्रोजेक्ट के लिए भुगतान करने वाले और क्यों नहीं, यह काम करके प्राथमिक हितधारक को ट्रैक किया जा सकता है।

उपयोगकर्ता शायद ही कभी प्राथमिक हितधारक है। आम तौर पर एक हितधारक चाहता है कि उपयोगकर्ता कुछ ऐसा करे ताकि वे, हितधारक लाभ प्राप्त कर सकें।

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

Here's a blog post मैं विषय पर लिखा था जो आपको उपयोगकर्ता और हितधारक की चिंताओं को अलग करने के लिए उपयोग कर सकते हैं एक टेम्पलेट भी शामिल है।मैं इसे कल्पना करने के लिए एक अभ्यास के रूप में छोड़ देता हूं कि जब आप पोस्ट के उपयोगकर्ता, इसे पढ़ते हैं तो कौन लाभान्वित होता है।