किसी परियोजना के प्रारंभिक चरणों में किस प्रकार की उपयोगकर्ता कहानियां लिखी जानी चाहिए?

11

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

यह "कार्य" की मेरी अवधारणा के साथ फिट नहीं है: मेरे लिए, मेरे पास निम्नलिखित "कार्यों" जैसा कुछ होगा:

जावास्क्रिप्ट ऑब्जेक्ट से व्युत्पन्न HTML में उपयोगकर्ता के फ़ॉस् के लिए डमी डेटा दिखाएं।
एक प्रेजेंटेशन लॉजिक लेयर सेट करें और जावास्क्रिप्ट ऑब्जेक्ट्स को इससे कनेक्ट करें।
एक डोमेन लॉजिक लेयर सेट करें, और प्रेजेंटेशन लॉजिक लेयर को इससे कनेक्ट करें।
डेटा एक्सेस लेयर सेट करें, और डोमेन लॉजिक लेयर को उससे कनेक्ट करें।

क्या ये सभी उपरोक्त "एकल" कहानी के अंतर्गत आते हैं? यदि हां, तो मुझे ऐसा लगता है कि परियोजना के शुरुआती चरणों में कहानियां बहुत उपयोगी रूपरेखा नहीं हैं। यदि हां, तो यह ठीक है --- मैं सिर्फ यह सुनिश्चित करना चाहता हूं कि मैं कुछ याद नहीं कर रहा हूं, क्योंकि मैं वास्तव में इस चुस्त कार्यप्रणाली को सीखने की कोशिश कर रहा हूं जितना कि मैं कर सकता हूं।

project-management agile

— Domenic
स्रोत

6

यह एक अच्छा सवाल है और शायद इसके कई अच्छे जवाब हैं। मेरा लेना यह है:

एक कहानी एक उपयोगकर्ता कहानी है इसलिए इसे ऐसे शब्दों में परिभाषित किया जाना चाहिए जो यह बताता है कि यह उपयोगकर्ता को कैसे लाभ पहुंचाता है।

अगर चुस्त और कहानियाँ आपके लिए काम करने वाली हैं, तो उन्हें शुरुआती चरणों में भी काम करना चाहिए। पहली बुलेट बिंदु एक एकल उपयोगकर्ता कहानी है (हालांकि थोड़ा सा टेक-वाई शब्द), लेकिन अन्य तीन तकनीकी कार्य विवरण हैं।

एक परियोजना के शुरुआती चरणों में, जब आपके पास CRUD ( C reate, R ead, U pdate, D elete ) विकास को त्वरित और आसान बनाने के लिए उपयुक्त रूपरेखाएँ नहीं हैं , तो आपकी कहानियों को बहुत छोटा, असंगत होने की आवश्यकता है टुकड़े।

"उपयोगकर्ता को अपने फू को देखने में सक्षम होना चाहिए" के बजाय , कुछ इस तरह से:

उपयोगकर्ता को नमूना डेटा वाले पृष्ठ को देखने में सक्षम होना चाहिए
उपयोगकर्ता को इंटरैक्टिव नमूना डेटा वाले पृष्ठ को देखने में सक्षम होना चाहिए
उपयोगकर्ता को लाइव इंटरेक्टिव नमूना डेटा वाले पृष्ठ को देखने में सक्षम होना चाहिए

याद रखें कि अधिकांश उपयोगकर्ता कहानियां जो एक ही स्प्रिंट में विकसित होने के लिए बहुत बड़ी लगती हैं (मैंने पाया है कि लगभग 8 स्टोरी पॉइंट्स या विकास के दिनों में से कुछ भी बड़ा, बहुत बड़ा था) शायद उन टुकड़ों में टूट सकता है जो अभी भी सार्थक हैं उपभोक्ता।

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

— निकोल
स्रोत

यह मेरे लिए सबसे अधिक उपयोगी उत्तर था, क्योंकि इसने अधिक दानेदार उपयोगकर्ता कहानियों का उदाहरण दिया। मुझे लगता है कि मैंने अपने प्रश्न का गलत विवरण दिया है; मुझे पता है कि मेरे "कार्य" उपयोगकर्ता कहानियां नहीं हैं, लेकिन मैं उम्मीद कर रहा था कि उनकी समान ग्रैन्युलैरिटी के साथ कुछ ऐसा होगा जो अभी भी योग्य होगा। आपने जो कहानियां दीं, वे वही थीं, जिनकी मुझे तलाश थी।

— डोमिनिक

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

— indyK1ng

@ indyK1ng मैंने दोहरे अर्थ के बारे में नहीं सोचा। मेरा मतलब था कि हर कहानी को एक बाजारू विशेषता नहीं होना चाहिए । बेशक, किसी भी कोड को पूरा करने के लिए जारी-तैयार गुणवत्ता का होना चाहिए । (संपादित उत्तर)

— निकोल

3

आप जो पूछ रहे हैं वह आवश्यक है "आप समस्या स्थान के बारे में कैसे सोचते हैं" ताकि इसे समझदार टुकड़ों में विभाजित किया जा सके, जिससे आप एक डिज़ाइन कर सकते हैं।

चाहे आप इसे उपयोगकर्ता की कहानी कहें, या विश्लेषण, या विघटन, या विनिर्देश, या आवश्यकताओं को इकट्ठा करना ... अंत में यह कई चीजों के लिए नीचे आता है जो सामान्य रूप से कुछ पुनरावृत्ति होगा।

आपको उपयोगकर्ताओं के प्रमुखों से प्राप्त करने की आवश्यकता है जो वे चाहते हैं। (वे शायद कुछ जानते हैं कि वे क्या चाहते हैं, और ऐसी चीजें चाहते हैं जो असंगत हैं लेकिन अभी तक नहीं देख सकते हैं।)

आपको इसे किसी रूप में पकड़ने की आवश्यकता है - आपके पास वास्तव में केवल 2 विकल्प हैं: शब्द या चित्र। दोनों में शक्ति है, यदि आप कर सकते हैं तो उन दोनों का उपयोग करें। बाद में अनुबंध संबंधी विवाद के दृष्टिकोण से शब्द अंततः अधिक शक्तिशाली होते हैं।

आपको इस पीठ को प्रस्तुत करने और समझौते की आवश्यकता है।

कुछ लोग बिना किसी व्यवसाय या अन्य तर्क के शुरुआती दृश्य प्रोटोटाइप करते हैं। यह एक शक्तिशाली तकनीक हो सकती है - एक बिंदु तक क्योंकि इसमें अभी भी एक निश्चित मात्रा में हाथ लहराते हैं।

कुछ स्टोरी-बोर्ड - और फिर पेश करेंगे और समझाएंगे।

कुछ कठोर और सावधानीपूर्वक विश्लेषण किए गए दस्तावेज़ लिखेंगे।

प्रत्येक तकनीक के अपने फायदे और नुकसान हैं।

एकमात्र सलाह जो मैं देता हूं, वह है: किसी समाधान को जल्द से जल्द कोड करना आमतौर पर एक बुरा कदम है। डब्ल्यूएचओ, और डब्ल्यूएचवाई के लिए क्या करना है, इससे पहले कि आप आम तौर पर इसे करते हैं, कम पुनरावृत्ति और तेजी से विकास होता है।

जब आप "कार्यों" के बारे में बात करते हैं, तो यह मुझे लगता है कि काम के कुछ प्रकार के टूटने के बाद, ऊपर क्या, कौन और क्यों पता लगा। जब तक आप उपयोगकर्ता द्वारा समझे गए दस्तावेज़ में, ग्राहक द्वारा अनुमोदित किए गए कार्य के दायरे के रूप में स्वीकृत किए गए कार्यों को नहीं हटा सकते, तब तक आप WELL का पता नहीं लगा सकते। यह जानना कि आपको क्या हासिल करना है (आउटपुट) आपको कार्यों का पता लगाने की अनुमति देता है (वहां पहुंचने में शामिल कदम)।

सामने अंत विश्लेषण और प्रलेखन पर कंजूसी मत करो।

— quickly_now
स्रोत

अधिक अग्रिम सोच की वकालत करने के लिए +1

— गैरी रोवे

1

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

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

— दान मैकग्राथ
स्रोत

1

+1 - मैंने जो लिखा है, वह केवल अधिक रसीला है।

— जल्दी_नौज 15'11