उपयोगकर्ता कहानियों का उपयोग करके जटिल व्यावसायिक नियमों को कैसे परिभाषित किया जाए?

Question

उपयोगकर्ता कहानी की एक त्वरित और गंदी परिभाषा :

"As a <role>, I want <goal/desire> so that <benefit>"

आमतौर पर स्वीकृत इस परिभाषा में व्यावसायिक नियमों, बाधाओं या उपयोगकर्ता इनपुट को परिभाषित करने के लिए बहुत कम जगह है।

केवल उदाहरण के लिए तुच्छ उदाहरण:

"As a <librarian>, I want to <register new books> so that
<students can find their availability online>"

इस मूर्खतापूर्ण उदाहरण में, पुस्तक को पंजीकृत करते समय आवश्यक क्षेत्रों को कहां परिभाषित किया जाएगा? क्या इसे कहीं लिखा जाना चाहिए? या उत्पाद स्वामी द्वारा आवश्यक व्यावसायिक नियमों को मुंह के शब्द के रूप में पारित किया जाना चाहिए?

Answer 1

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

उपयोगकर्ता की कहानी - बातचीत करने का वादा इस बारे में एक ब्लॉग प्रविष्टि होगी।

आपके तुच्छ उदाहरण में कुछ बिंदु हैं जो मुझे नहीं पता कि आप इसे कितनी अच्छी तरह नोटिस करेंगे। "नई पुस्तकें पंजीकृत करने" का क्या अर्थ है? "उनकी उपलब्धता ऑनलाइन क्या है?" वे हैं जहां बातचीत शुरू होती है और एक बार कहानी हो जाने के बाद नई कहानियां हो सकती हैं क्योंकि शायद उन पंजीकरणों को फाइल पर रखना होगा या रिपोर्ट समय-समय पर उत्पन्न करनी होगी।

Answer 2

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

1. अगर कहानी बहुत जटिल है, तो शायद यह एक महाकाव्य है । आप महाकाव्यों को छोटी कहानियों में विभाजित कर सकते हैं या एक बार उत्पाद बैकलॉग पर प्राथमिकता प्राप्त कर सकते हैं

2. विवरण कि परीक्षण के मामलों को कहानी से ही अलग किया जाता है। [ माइक कोहन ]

   आप कहानी कार्ड के पीछे जोड़ सकते हैं, छोटे नोट बना सकते हैं यदि वे वास्तव में महत्वपूर्ण हैं या उन्हें स्वीकृति परीक्षण दस्तावेज में डाल दिया है ।

मूल्यांकन करने के लिए एक दिशानिर्देश के रूप में यदि आपकी उपयोगकर्ता कहानियां अच्छी हैं, तो आप बिल वेक के सुझाव का पालन ​​कर सकते हैं :

• मैं अन्योन्याश्रित (अन्य कहानियों की)
• एन अहंकारी
• V aluable (उपयोगकर्ता या ग्राहक के लिए)
• ई उत्तेजक (एक अच्छा सन्निकटन के लिए)
• एस मॉल (अनुमान लगाने के लिए पर्याप्त)
• टी इस्टेबल

आप माइक कोहेन की पुस्तक एप्स स्टोरीज एप्स के अध्याय 2 "राइटिंग स्टोरीज" को पढ़ना चाह सकते हैं ।

Comments

महाकाव्यों के

— रिकार्डो

Answer 3

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

नई पुस्तकों का पंजीकरण करना व्यापक है, इसलिए शायद 10 अन्य बाल उपयोगकर्ता कहानियां हैं कि कैसे <role>पुस्तकों को पंजीकृत किया जाना है।

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

यह सिर्फ इस तरह है कि मैं समस्या का सामना कर रहा हूं, लेकिन मुझे यकीन है कि कई तरीके हैं।

Answer 4

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

केवल उदाहरण के लिए तुच्छ उदाहरण:

लाइब्रेरियन के रूप में, मैं नई पुस्तकों को पंजीकृत करना चाहता हूं, ताकि छात्र अपनी उपलब्धता ऑनलाइन जान सकें

मैं संतुष्ट हो जाऊंगा जब: * मैं निम्नलिखित क्षेत्रों को पंजीकृत कर सकता हूं: - ISDN - लेखक - डेवी दशमलव ब्लाह ब्लाह * मैं पुष्टि कर सकता हूं कि पुस्तक प्रणाली द्वारा पंजीकृत की गई है * मैं पुस्तक को प्रणाली में देख सकता हूं

Answer 5

उपयोगकर्ता कहानियों का उपयोग करके जटिल व्यावसायिक नियमों को कैसे परिभाषित किया जाए?

यह उपयोगकर्ता की कहानियों के लिए नहीं है। वे सॉफ़्टवेयर आवश्यकताएँ नहीं हैं जो कार्यान्वयन को लिखने के लिए आवश्यक सभी विवरणों या व्यावसायिक नियमों को कैप्चर करते हैं। वे केवल एक विवरण हैं कि उपयोगकर्ता के दृष्टिकोण से आवेदन क्या करना चाहिए।

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

विवरण मानदंड, उप-कहानियां, उपयोगकर्ता कहानी से जुड़े तकनीकी कार्यों, विनिर्देश दस्तावेज़ या जो कुछ भी है, के रूप में विवरण होने से आगे क्या उपयोगकर्ता कहानी आपकी मदद करती है। सॉफ्टवेयर का निर्माण कैसे करें, यह तय करते समय उपयोगकर्ता का स्टॉयफ सिर्फ "विषय" होता है।

Comments

इस! एक बड़ी तस्वीर के छोटे हिस्सों का वर्णन करने के लिए उपयोगकर्ता कहानियां एक शानदार उपकरण हैं। वे विकास और दूसरी दुनिया (उत्पाद प्रबंधन, उपयोगकर्ता अनुसंधान, बिक्री, ...) के बीच चौराहे को संभालने का आदर्श तरीका हैं

— uxfelix

Answer 6

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

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

Comments

जबकि ये वैध बिंदु हैं, वे ओपी के मुख्य प्रश्न "उपयोगकर्ता कहानियों का उपयोग करके जटिल व्यावसायिक नियमों को कैसे परिभाषित करें" को संबोधित नहीं करते हैं?

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

— log