मुझे लगता है कि एक सुविधा "क्रेडिट कार्ड प्रमाणीकरण" जैसी कुछ हो सकती है, जबकि उपयोगकर्ता की कहानी "पेपैल के लिए क्रेडिट कार्ड अधिकृत" हो सकती है।उपयोगकर्ता स्टोरी और एग्इल टर्मिनोलॉजी में एक फ़ीचर के बीच क्या अंतर है?
तो, क्या उपयोगकर्ता की सुविधा किसी सुविधा का सबसेट है?
हां, सबसेट की तरह कुछ। यह लेख एक अच्छा पढ़ा है:
Features vs Stories
अंश:
मैं आज एहसास हुआ कि मैं मेरे मन सुविधाओं और कहानियों के बीच में स्पष्ट अंतर नहीं किया था और यह एक महत्वपूर्ण है अंतर। अनिवार्य रूप से, एक विशेषता कहानियों का एक समूह है जो संबंधित हैं और कार्यक्षमता का एक पैकेज प्रदान करते हैं जो उपयोगकर्ताओं को आमतौर पर एक बार में प्राप्त करने की उम्मीद करता है। उदाहरण के लिए, इनलाइन तालिका का आकार एक सुविधा है (नोट: यह तालिका, पंक्तियों और कॉलम का आकार बदलने के लिए खींचने के लिए क्षमता है - इसे Word में आज़माएं)। में पहले पास, टेबल के इनलाइन आकार बदलने के लिए आपके पास शायद एकल कहानी होगी, लेकिन यह अनुमान के लिए बहुत बड़ी होगी। तो आप इसे में तीन कहानियों में विभाजित करते हैं, कॉलम का आकार बदलते हैं, पंक्तियों का आकार बदलते हैं और तालिका का आकार बदलते हैं।
इस पृष्ठ पर 'डिएगो' पोस्ट पर एक नज़र डालें, एक ताज़ा परिप्रेक्ष्य। –
धन्यवाद ... आपके द्वारा पोस्ट किया गया एक अच्छा लिंक भी है। हर बार जब मैं किसी ऐसे व्यक्ति का अनुभव पढ़ता हूं जो उसके बारे में फिर से सोच रहा है कि वह क्या कर रहा है, तो मुझे इस विषय को अलग तरीके से सोचने में मदद मिलती है। मुझे लगता है कि यह साइट आश्चर्यजनक कारणों में से एक है .. आप हमेशा –
सीखते रहें सटीक भावनाएं :) –
बिल्कुल नहीं ..
एक उपयोगकर्ता कहानी व्यापार मूल्य के छोटे हिस्सों का प्रतिनिधित्व करता है। तो यह कहना मुश्किल है कि जब कोई उपयोगकर्ता कहानी किसी सुविधा का एक उप-समूह होता है या सुविधा किसी उपयोगकर्ता की कहानी का सबसेट होता है (यह भी ध्यान रखें कि उपयोगकर्ता कहानियां आमतौर पर हितधारकों द्वारा लिखी जाती हैं, जो बिल्कुल नहीं जानती हैं वे क्या चाहते हैं ... :))
तो, यदि आप कहानियों को कम रखने के लिए चुस्त की सिफारिश का पालन करते हैं तो आप "सर्वश्रेष्ठ" परिदृश्य पर पड़ेंगे जो उपयोगकर्ता की कहानी सुविधा का सबसेट है।
हालांकि यदि आपका हितधारक लंबी कहानियां लिखता है, तो प्रत्येक कहानी में कुछ विशेषताएं होंगी (यदि टीम और हितधारकों के बीच अच्छा संचार होता है तो यह नहीं होगा क्योंकि टीम छोटी कहानियों में कहानियों को तोड़ देगी)
Kent Beck and Martin Fowlerकहानियों के अनुसार और सुविधाओं समानार्थक शब्द हैं:
एक उपयोगकर्ता कहानी कार्यक्षमता का एक हिस्सा (कुछ लोगों शब्द का प्रयोग है फीचर) यह ग्राहक के के मूल्य का है।
आप एक सुविधा क्या कहते आमतौर पर विषय या महाकाव्य के रूप में जाना जाता है। थीम्स और महाकाव्य का उपयोग उपयोगकर्ता कहानियों को बड़े फीचर सेट में समूहित करने के लिए किया जाता है, जो स्वयं को समझ में आता है।
अधिक अर्थपूर्ण दृष्टिकोण से: सुविधा उस प्रणाली का एक हिस्सा है जिसे आप बनाने की कोशिश कर रहे हैं, उपयोगकर्ता कहानी उस भाग का वर्णन करने का एक तरीका है।
सुधार:
के रूप में पास्कल ने कहा है - मैं शायद कि प्रशस्ति पत्र इस के अलावा ("सुविधा" स्पष्ट रूप से कार्यक्षमता को संदर्भित करता है) में "सुविधा" का असली अर्थ याद किया, मैं अभी भी है कि लगता है कि एक इन शब्दों (फीचर और यूजर स्टोरी) को कई संदर्भों में समानार्थी के रूप में उपयोग कर सकते हैं ("मैं इस कहानी पर काम कर रहा हूं" बनाम "मैं इस सुविधा पर काम कर रहा हूं"), चूंकि पास्कल ने कहा, एक उपयोगकर्ता की कहानी है एक सुविधा कैप्चर करने का एक तरीका। जिसका मतलब है कि उन दोनों के बीच 1: 1 संबंध है। और, जैसा कि अर्थशास्त्र के बारे में मेरी टिप्पणी से देखा जा सकता है, इस तरह मैं इसे वास्तव में समझता हूं।
"जिसे आप एक सुविधा कहते हैं उसे आमतौर पर थीम या महाकाव्य के रूप में जाना जाता है", मुझे यह समानता पसंद है। :) –
मैंने दुर्घटना से मेरी टिप्पणी हटा दी है, इसलिए मैं इसे स्पष्टता के लिए वापस रख रहा हूं: क्या आप सुनिश्चित हैं कि कुछ लोग शब्द सुविधा का उपयोग कार्यक्षमता पर लागू नहीं होते हैं? –
बीटीडब्लू, मुझे वास्तव में परिशिष्ट पसंद है भले ही मेरे पास एक और दृष्टिकोण है (व्यक्तिगत रूप से, मैं * उपयोगकर्ता कहानी => सुविधा * के रूप में संबंध को सख्त समकक्षता के बिना देखता हूं)। –
विशेषताएं एक सिस्टम क्या कर रही हैं। उपयोगकर्ता कहानियां दूसरों को सुविधाओं को कैप्चर करने के लिए एक ही रास्ता हैं।
मेरा बिंदु, पास्कल;) –
मैं इस विषय पर आया था जब मैं "समान आवश्यकताओं के लिए कई भूमिकाओं का उपयोग करके" विभिन्न विचारों की खोज कर रहा था।
मुझे लगता है कि, संबंधित कहानियों के लिए एक कंटेनर के रूप में एक सुविधा आवश्यकताओं को प्राथमिकता देने में मदद करती है क्योंकि हितधारकों आमतौर पर निर्भर कहानियों के रूप में अपनी आवश्यकताओं को बताते हैं। हाल ही में एक परियोजना में, ग्राहक ने मुझे बताया के रूप में
इस प्रकारएक सदस्य व्यवस्थापक व्यवस्थापक को संदेश भेजने के सभी सदस्यों के लिए संदेश भेज सकते हैं सदस्य एक दूसरे को
को संदेश भेज सकते हैं जब मैं इन आवश्यकताओं को देख सकते हैं, मैं जानते हैं कि, हमें लोगों को एक संदेश भेजने में सक्षम बनाने के लिए एक प्रणाली को लागू करना चाहिए और हमें यह जांचने के लिए चेक जोड़ना चाहिए कि किसके लिए क्या करना है।
और यह भी मुझे पता है इन आवश्यकताओं को इस तरह के संदेशों कि आया पढ़ना, उन्हें व्यवस्था करने, के रूप में कुछ अन्य अंतर्निहित आवश्यकताओं स्पैम के रूप में स्थापित करने के किया जा सकता है और आदि
हो सकता है तो मैं
के रूप में इन आवश्यकताओं को अलग तरीके से व्यक्त करने की कोशिशसदस्य या व्यवस्थापक के रूप में, मैं अन्य लोगों को संदेश भेज सकता हूं। सदस्य या व्यवस्थापक के रूप में, मैं उन संदेशों को पढ़ सकता हूं जो मुझे भेजे गए थे।
और स्वीकृति मानदंड के रूप में, मैं विस्तार से बताता हूं कि कौन भेज सकता है।
फिर मैं इन सभी चीजों को "निजी संदेश" सुविधा के रूप में बुलाता हूं, ताकि कुछ समय बाद, यदि ग्राहक निर्णय लेता है कि यह एक अतिरिक्त लागत है, तो वह कह सकता है "बस निजी संदेश वस्तु को छोड़ दें" और मैं कर सकता हूं बैकलॉग से उन सभी को हटा दें।
एक चुस्त उपयोगकर्ता स्टोर व्यक्ति केंद्रित होना चाहिए। उदाहरण के लिए: "खाता स्वामी के रूप में, मैं पेपैल के लिए अपने क्रेडिट कार्ड को अधिकृत कर सकता हूं।" इसके बाद, आप विस्तृत सफलता मानदंड प्राप्त करना चाहेंगे। – Jay
http://scalingsoftwareagility.files.wordpress.com/2007/03/a-lean-and-scalable-requirements-Information-model-for-agile- में कहानियों, बैकलॉग इत्यादि के संबंधों को समझाने के लिए यूएमएल मॉडल हैं। उद्यम-पीडीएफ.pdf – Fuhrmanator