उपयोगकर्ता कहानियों में आवश्यकताएं नहीं हो सकती हैं (जब एक कार्ड पर लिखा गया हो) और अभी भी लागू हो

18

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

अगर कोई निचली आवश्यकताएं नहीं हैं, तो डेवलपर्स कहानी से कैसे विकसित हो सकते हैं? उपयोगकर्ता कहानी के आधार पर परीक्षक परीक्षण के मामले (विस्तृत विवरण) कैसे लिख सकते हैं? जहां उपयोगकर्ता की कहानी के बाहर डीबी बाधाएं, क्षेत्र सत्यापन आदि की आवश्यकताएं होती हैं?

agile scrum requirements

— user144171
स्रोत

6

उपयोगकर्ता कहानियां बस यही हैं - उपयोगकर्ता स्तर की आवश्यकताएं। निचले स्तर की 'सॉफ़्टवेयर आवश्यकताएं' (अक्सर क्या सीमाएं स्वीकार्य मानी जाती हैं) को हमेशा अलग-अलग काटा जाना चाहिए और एक उपयुक्त संदर्भ के साथ अलग से प्रलेखित किया जाना चाहिए।

— गुस्सोर

7

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

— जोंशरशेप

2

gnat: वास्तव में नहीं। मैंने पूछा क्योंकि मैं वास्तव में दिलचस्पी रखता हूं कि यह कैसे सही ढंग से किया जा सकता है जैसा कि मुझे यकीन है, एससीआरयूएम के व्यापक उपयोग को देखते हुए, यह कई टीमों के लिए एक मुद्दा होना चाहिए।

— user144171

4

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

— gnat

2

यहाँ एक अच्छा सवाल है, लेकिन यह एक शेख़ी के रूप में लिखा गया है। मैंने एक संपादन में एक प्रयास किया।

— DA01

28

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

यह उत्तर मानता है कि आप स्क्रैम के साथ बोर्ड पर हैं, लेकिन अभी तक इसे आपके लिए काम करने का कोई तरीका नहीं मिला है।

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

हालांकि, इसका मतलब यह नहीं है कि इन विवरणों को कहीं भी दर्ज नहीं किया जाना चाहिए।

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

क्या इसका मतलब उपयोगकर्ता कहानियों में निम्न स्तर का विवरण दर्ज किया जाना चाहिए? हाँ और न)।

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

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

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

— MetaFight
स्रोत

3

+1 स्वीकृति मानदंड अधिक विस्तार से जोड़ता है

— भिन्नात्मक

3

हाँ, इसके बी.एस. और स्क्रैम एजाइल नहीं है।

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

फुर्तीले होने के बारे में चुस्त है।

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

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

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

— gbjbaanb
स्रोत

4

क्या आप इसे कम (यानी, गैर-) अपमानजनक तरीके से वाक्यांश देने की कृपा करेंगे? मैं इस विषय पर आपसे सहमत हूं, लेकिन लोगों की अलग-अलग राय है और उस तरह से अपने शिष्टाचार को खोने का कोई औचित्य नहीं है।

— फ्रैंक

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

— user144171

3

क्लाइंट 8 बिट पूर्णांक के लिए सहमत हुआ, इसलिए यह मेरी गलती नहीं है।

— जेएफओ

2

@ जीबीजैनब: एजाइल "सामान्य ज्ञान का उपयोग करने के लिए" एक नया फैंसी शब्द है, यानी अपफ्रंट एनालिसिस / डिज़ाइन के बीच सही संतुलन का पता लगाना और तुरंत फीडबैक इकट्ठा करने के लिए आंशिक समाधान पहुँचाना। मुझे यह शब्द काफी चुभता हुआ लगता है क्योंकि इन विचारों में नाम के अलावा बहुत कुछ नया है। इससे भी बदतर तब होता है जब एससीआरयूएम जैसे बल्कि अनम्य रूपरेखा को चुस्त के रूप में लगाया जाता है । IMO वास्तव में चुस्त होने का मतलब होगा चुस्त और SCRUM शब्द को छोड़ना और अपनी प्रक्रिया को अपनी आवश्यकताओं के अनुसार अपनाना, जैसा कि हम हमेशा चुस्त लहर शुरू होने से पहले करते रहे हैं।

— जियोर्जियो

1

@ Alex वह SCRUM और चुस्त प्रक्रियाओं के संदर्भ में बहुत पूछ रहा है।

— gbjbaanb 15

3

बस इसे एक उपयोगकर्ता कहानी मत कहो और हर कोई खुश होगा।

मुझे लगता है कि जवाब है, आप इसे नीचे लिख सकते हैं जहाँ आप चाहते हैं।

सामान्य तौर पर, विशिष्ट कार्यान्वयन कुछ कारणों से उपयोगकर्ता कहानी में शामिल नहीं होते हैं:

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

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

— JeffO
स्रोत

1

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

— user144171

4

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

— 13

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

— जेफ़ो

2

@ user144171 किसी प्रोजेक्ट के लिए सभी आवश्यकताओं को लिखने की कोशिश करना, या एक विशेषता, आगे की ओर, और सबसे विस्तृत तरीके से संभव है, पिछले बिट तक, बस उतना ही बुरा है जितना कोई आवश्यकता नहीं है। एक ही बात डिजाइन के लिए चला जाता है।

— AK_

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

— मेपल_शफ्ट

2

मुझे लगता है कि अगर आपके स्क्रम सलाहकार आपको बता रहे हैं कि स्क्रम की आवश्यकताओं की आवश्यकता नहीं है तो आपके पास कुछ बहुत खराब सलाहकार हैं। वे आपको यह बताने में भी गलत हैं कि एक उपयोगकर्ता कहानी वास्तव में एक आवश्यकता नहीं है, वे सिर्फ एक प्रकार की आवश्यकता होती है।

सॉफ़्टवेयर आवश्यकताओं के विभिन्न प्रकार क्या हैं?

व्यापार की आवश्यकताओं

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

प्रयोगकर्ता की आवश्यकताएं

ये उपयोगकर्ता कहानी की आवश्यकताएं हैं जिनसे आप परिचित हैं। वे आम तौर पर एक चिपचिपा नोट पर फिट हो सकते हैं।

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

कार्यात्मक या सिस्टम आवश्यकताएँ

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

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

कार्यात्मक आवश्यकताएं आपके समाधान को परिभाषित करती हैं जो आपको लगता है कि आप अपनी प्रक्रिया में अंतर के रूप में क्या वर्णन कर रहे हैं।

उल्लेखनीय आवश्यकता प्रकार जिनका उल्लेख किया गया है, लेकिन आपके प्रश्न के लिए अपरिहार्य हैं: गैर-कार्यात्मक आवश्यकताएं, तकनीकी आवश्यकताएं, आदि ...

— मेपल_शाफ्ट
स्रोत

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

— एलेक्स

@ एलेक्स: उपयोगकर्ता की कहानी / आवश्यकता => एटीएम से पैसे निकालना चाहते हैं, कार्यात्मक आवश्यकता => बिल निकालने के लिए कुल समय 30 सेकंड से अधिक नहीं हो सकता है। उपयोगकर्ता की आवश्यकता कार्यात्मक आवश्यकता को शामिल नहीं करती है।

— 18

@jmoreno आपके उदाहरण में "उपयोगकर्ता कहानी" एक उपयोगकर्ता कहानी नहीं है, यह एक उपयोगकर्ता कहानी में शुरुआती बिंदु है। और निष्पादन समय के बारे में "कार्यात्मक आवश्यकता" एक ग्रे ज़ोन में है, मुख्य कार्यात्मक आवश्यकता बिलों को निकालने के लिए है, समय की कमी के कारण कई मूल हो सकते हैं।

— एलेक्स

2

@jmoreno वास्तव में एक प्रदर्शन मीट्रिक जैसा कि एक गैर-कार्यात्मक आवश्यकता माना जाता है

a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors

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

— maple_shaft

@ एलेक्स ऊपर मेरी टिप्पणी देखें। मुझे लगता है कि आप दोनों एक उलझन में हैं कि एक कार्यात्मक आवश्यकता क्या है।

— maple_shaft

1

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

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

आपका प्रश्न कुछ ऐसा ही लगता है

मेरे पास यह CarFactory है और मुझे इसे साइकिलें भी बनाने की आवश्यकता है, लेकिन हमारे OOD "गुरु" का कहना है कि मुझे ऐसा करने की अनुमति नहीं है। यह बीएस क्या है ?!

चिंताओं और आपके कलाकृतियों के सामंजस्य, आपके कोड के लोगों और आपकी प्रक्रियाओं में दोनों के अलगाव का सम्मान करें।

— एलेक्स
स्रोत

1

मुझे लगता है कि इस दृष्टिकोण का उद्देश्य उपयोगकर्ता की कहानियों को रोकना नहीं है, बल्कि बुरी आवश्यकताओं को रोकना है।

मेरे अनुभव में, उपयोगकर्ता आमतौर पर लेखन आवश्यकताओं के लिए असमर्थ होते हैं। डेवलपर्स आमतौर पर लेखन आवश्यकताओं के लिए असमर्थ हैं। बिल्ली, चलो इसे सीधे स्वीकार करते हैं: आवश्यकताओं को लिखना मुश्किल है!

मुझे लगता है कि यह उपयोगकर्ता के लिए उपयोग की कहानी के हिस्से के रूप में आवश्यकताओं में कुछ लिखने के लिए मान्य होगा। हालाँकि, ऐसा करने से स्वतः इसकी आवश्यकता नहीं होनी चाहिए। दो परस्पर विरोधी उपयोग वाली कहानियाँ एक मामूली समस्या है; दो परस्पर विरोधी आवश्यकताएं एक प्रमुख अनुबंध-विराम मुद्दा है। अपने समय से पहले एक को बढ़ावा देने में कोई समझदारी नहीं है।

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

— कॉर्ट अमोन - मोनिका को बहाल करें
स्रोत

1

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

— मेपल_शफ्ट

1

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

— Cort Ammon - मोनिका

1

अपने फैसले खुद करें

'तो वास्तव में कैसे डेवलपर्स कभी भी एक कहानी विकसित कर सकते हैं अगर कोई कम आवश्यकताएं नहीं हैं?' बहुत सरल है - विस्तृत आवश्यकताएं जो अंतिम उपयोगकर्ता की आवश्यकताओं के लिए रूढ़िवादी हैं (जैसे DB विवशता, फ़ील्ड सत्यापन, आदि) वास्तव में उपयोगकर्ता के लिए मायने नहीं रखती हैं। यदि उपयोगकर्ता की ज़रूरतों को बहुत अलग-अलग क्षेत्रों के सत्यापन, बहुत भिन्न DB संरचनाओं या शायद किसी भी पारंपरिक DB द्वारा पूरा नहीं किया जा सकता है, तो उपयोगकर्ताओं को एक विशेष कार्यान्वयन को ध्यान में रखते हुए ऐसी जानकारी प्राप्त करना प्रतिशोधात्मक होगा, जो बहुत हो सकता है सिस्टम अंत में कैसे लागू किया जाता है, उससे अलग।

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

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

एक मानक कार सादृश्य - अगर कोई ग्राहक कार को लाल रंग में रंगना चाहता है, तो उपयोगकर्ता कहानी के लिए एक उपयुक्त स्पष्टीकरण यह पूछना होगा कि लाल रंग की कौन सी छाया बेहतर होगी, लेकिन पेंट की रासायनिक संरचना नहीं; फिर भी, यह उम्मीद की जाएगी कि वे कार को पानी के रंग से पेंट करने का विकल्प नहीं चुनेंगे जो बारिश में धोएंगे, क्योंकि ऐसा नहीं करना सबसे अच्छा अभ्यास है।

— पीटर है
स्रोत

1

टी एल; डॉ

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

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

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

मूल पोस्टर (ओपी) ने निम्नलिखित प्रश्न पूछा :

[ए] ग्राहक अलग-अलग क्रेडिट कार्ड के लिए एक अलग प्रसंस्करण चाहता है, सख्त आवश्यकताएं हैं जिन्हें लागू किया जाना चाहिए और ज्ञात होना चाहिए ताकि परीक्षण के मामलों को लिखा जा सके ... जहां मैं इसे स्टोर नहीं करता है?

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

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

एक काम का उदाहरण

एक नमूना उपयोगकर्ता कहानी

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

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

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

विश्लेषण और कार्यान्वयन

वास्तविक कार्यान्वयन टीम के लिए है। टीम को निर्धारित करने के लिए कुछ विश्लेषण करना होगा:

नई सुविधा को लागू करने का सबसे आसान तरीका।
विभिन्न कार्यान्वयन विकल्पों में से कौन सा तकनीकी ऋण को प्राप्त किए बिना, आगे बढ़ने का समर्थन करना सबसे आसान होगा।
खुले-बंद और YAGNI सिद्धांतों को कैसे लागू किया जाए, यह सुनिश्चित करने के लिए कि आपकी नई सुविधा बिना इंजीनियर के मजबूत हो।

एजाइल मैनिफेस्टो के मुख्य सिद्धांतों में से एक ग्राहक सहयोग है। एक क्रॉस-फंक्शनल, सेल्फ-ऑर्गेनाइजिंग टीम से उम्मीद की जाती है कि वह ग्राहक के साथ सहयोग करके यूजर स्टोरी द्वारा दिए गए दिशा-निर्देशों के कार्यान्वयन के विवरणों को तैयार करेगी।

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

टेस्ट-चालित और व्यवहार-प्रेरित डिजाइन

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

खीरे में परीक्षण योग्य परिदृश्य होते हैं।

यह स्वीकृति परीक्षणों के विकास को चलाने के लिए, और अनुप्रयोग व्यवहार की उपयोगकर्ता की अपेक्षाओं के दस्तावेजीकरण के लिए सबसे उपयोगी है। उदाहरण के लिए, उपयोगकर्ता की कहानी में एक या एक से अधिक संबंधित ककड़ी विशेषताएं होनी चाहिए, जो बताती है कि उपयोगकर्ता एक खोज कार्ड के साथ कैसे जांच कर सकता है, और यह प्रक्रिया उपयोगकर्ता के लिए कैसा दिखता है।
RSpec परीक्षण जो नए कोड सुविधाओं के व्यवहार (आंतरिक कार्यान्वयन विवरण नहीं) को मान्य करता है।

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

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

— CodeGnome
स्रोत

0

यहाँ बहुत अच्छे जवाब। उम्मीद है कि मैं एक और के साथ कुछ मूल्य जोड़ सकते हैं ...

मुझे लगता है कि आपकी टीम को एक हैंग हो सकता है जो एक गैर-चुस्त कार्यप्रणाली से पलायन कर रहा है।

यह आमतौर पर कुछ रूप में झरना पद्धति है और व्यवहार में, आमतौर पर कोड की एक पंक्ति लिखे जाने से पहले सभी तकनीकी आवश्यकताओं को दस्तावेज करने की कोशिश करना शामिल है।

लेकिन वह हमेशा काम नहीं करता है। अक्सर यह काम नहीं करता है। कारण? क्योंकि आवश्यकताओं को शायद ही कभी वास्तविकता के साथ संरेखित किया जाता है। चीज़ें बदल जाती हैं। इसलिए चंचल की ओर कदम।

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

यह महसूस हो सकता है कि यह आपकी टीम के लिए बोझ है, लेकिन इसे एक लक्जरी समझें। आपकी टीम के पास अब समाधान में बहुत कुछ है - जो जरूरी नहीं कि जलप्रपात मॉडल में था।

— DA01
स्रोत