फ़ीचर बनाम फ़ंक्शन [बंद]


16

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

मेरा सवाल यह है कि हम कार्य को कैसे अलग कर सकते हैं?


9
मैं इसके बारे में इतना नहीं देखूंगा। वे दोनों का अर्थ है 'कार्यक्रम इस या उस चीज को करने में सक्षम होना चाहिए'; यदि कोई प्रोजेक्ट मैनेजर एक अंतर करता है, तो यह संभवतः व्यक्तिगत है और आपको इरादा निकालने के लिए लाइनों के बीच में पढ़ना चाहिए।
tdammers

8
या बस प्रत्येक की अपनी परिभाषा के लिए पूछें। संभवतः वे दोनों को समानार्थी शब्द के रूप में उपयोग करते हैं।
पेटर तोर्क

बुलेट के अंक बनाम मूल्य
एरिक रेपेन

जवाबों:


35

विशेषताएं वे हैं जो लोग बिक्री करते हैं।
फ़ंक्शंस क्या प्रोग्रामर विकसित होते हैं।


4
अच्छा, यादगार, अलग जवाब।
सईद नेमाटी

@RobertHarvey क्या आपके पास इस उत्तर के खिलाफ एक विशिष्ट तर्क है?
ज़िबोबोज़

@Zibbobz: इसका मतलब है कि आप आम तौर पर सूचित नहीं करते हैं? प्रश्न पर लागू करीबी मतों पर भी ध्यान दें।
रॉबर्ट हार्वे

8

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

दूसरी ओर कार्य व्यक्तिगत इकाइयाँ हैं जिन्हें किसी विशेषता या कार्य को पूरा करने के लिए पूरा किया जाना चाहिए।

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

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

जब तक स्प्रिंट के अंत तक मेरे पास अभी भी काम करने वाला सॉफ्टवेयर है तब तक मेरा प्रोजेक्ट एजाइल है।


6

सुविधाएँ वही हैं जो आपका कार्यक्रम कर सकता है। सुविधाएँ उपयोगकर्ता की आवश्यकताओं, और व्यावसायिक उद्देश्यों का प्रत्यक्ष परिणाम हैं। इस प्रकार एक कार्यक्रम की विशेषताएं मुख्य रूप से उपयोगकर्ता की मांगों को पूरा करने के लिए मौजूद हैं

दूसरी ओर, कार्यक्षमता यह है कि उपरोक्त सुविधाओं को वास्तव में कैसे लागू किया जाता है


2

एक PM के लिए, "फ़ंक्शन" उद्देश्य है और "फ़ीचर" एक उत्पाद व्यवहार है जो एक उपयोगकर्ता के साथ बातचीत कर सकता है। हालाँकि लोग अक्सर दोनों को पीछे की ओर ले जाते हैं (जो मुझे लगता है कि आपके प्रश्न में मामला है)।

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

यहां "फ़ंक्शन" को एक प्रोग्रामिंग भाषा फ़ंक्शन (विधि) के साथ भ्रमित नहीं किया जाना चाहिए जो एक फीचर सॉफ़्टवेयर के कार्यान्वयन के बारे में बात करता है। जब पीएम "फीचर्स और फंक्शन्स" का जिक्र करते हैं, तो यह संभव नहीं है।

फ़ंक्शन और सुविधाओं के लिए एक अच्छी पदानुक्रम नहीं है, क्योंकि एक उत्पाद का उपयोग कई उत्पाद कार्यों का समर्थन करने के लिए किया जा सकता है।


0

मेरा मानना ​​है कि एक विशिष्ट पद्धति या एक विशिष्ट आवश्यकताओं की संस्कृति के लिए एक सही अंतर तैयार करना होगा। निम्नलिखित मेरी अपनी व्याख्या है।

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

फ़ीचर: सॉफ़्टवेयर की क्षमता के लिए एक अच्छा, जो सॉफ़्टवेयर में मूल्य जोड़ता है, लेकिन सॉफ़्टवेयर के ठीक से कार्य करने और अपने कार्यों को करने के लिए एक निरपेक्ष नहीं होना चाहिए। उदाहरण के लिए, डेटा एंट्री फॉर्म पर एक पूर्ववत सुविधा है या टेक्स्ट एडिटर (वायर्ड!) के लिए gif फ़ाइल के रूप में एक दस्तावेज़ सहेजें।


1
मुझे नहीं पता कि आपको ये कहां से मिले, लेकिन IMHO कार्यों और विशेषताओं की सबसे सामान्य परिभाषाएं महत्व पर कोई अंतर नहीं करती हैं ।
डॉक ब्राउन

मैंने आपकी टिप्पणी के लिए aser, thnx को योग्य बना दिया।
NoChance

-1

प्रत्येक सुविधा के पीछे उपयोगकर्ता की सुविधा के उद्देश्य से प्रदान करने के लिए आवश्यक कार्यक्षमता है।

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

प्रोग्रामर कोड के लिए कार्यों की तलाश कर रहे हैं। उपयोगकर्ता के साथ सॉफ़्टवेयर के इंटरैक्शन के डिज़ाइन के माध्यम से इंटरएक्शन डिजाइनर इस आवश्यक कार्यक्षमता को वितरित करने का सबसे अच्छा तरीका ढूंढ रहे हैं। यह समझना कि उपयोगकर्ता अपने उद्देश्य को सबसे पहले कैसे प्राप्त कर सकता है। आवश्यक कार्यक्षमता की पहचान इस प्रकार है।

उपरोक्त वैज्ञानिक नहीं है, यह केवल मेरी राय है।


2
स्टैक एक्सचेंज प्रोग्रामर्स में अपनी पहली पोस्ट जोड़ने के लिए धन्यवाद। कृपया प्रश्न और उत्तर लिखने के बारे में विचारों के लिए FAQ प्रोग्रामर्स .stackexchange.com/faq पर एक नज़र डालें जो वोट प्राप्त करेंगे और आपकी प्रतिष्ठा में सुधार करेंगे।
DeveloperDon

-1

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


-2

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


यह पोस्ट पढ़ना मुश्किल है (पाठ की दीवार)। क्या आप बेहतर आकार में आईएनजी को संपादित करेंगे ?
गनट
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.