2009-07-15 13 views
5

कल्पना कीजिए कि आप उपयोगकर्ता कहानी 1 जो एक विधि के क्रियान्वयन की आवश्यकता है है:Agile Scenario, जो सही है?

public static void MyMethod(string paramA); 

अनेक वर्गों का इस पद्धति का उपयोग किया जाएगा, और MyMethod उपयोगकर्ता कहानी 1 पूरा करने की आवश्यकता है सब कुछ है, लेकिन अधिक कुछ नहीं करता है।

आप यकीन है कि है कि एक और कहानी (उपयोगकर्ता कहानी 2) यात्रा एक भविष्य में आ जाएगा, जिसके साथ विधि की आवश्यकता बन जाएगा हैं:

public static void MyMethod(string paramA, int paramB); 

MyMethod करने के लिए पिछले कॉल पुनर्संशोधित करने की आवश्यकता होगी, और MyMethod को कुछ नई कॉल उपयोगकर्ता की कहानी 2 की आवश्यकताओं को पूरा करने के लिए जोड़नी होगी (कहानी 2 के बाद नोट यह केवल paramA के साथ MyMethod को कॉल करने के लिए कभी समझ में नहीं आता है)।

1) केवल लागू:

जब उपयोगकर्ता कहानी 1 पर काम करने के लिए चुस्त सोच है सार्वजनिक शून्य MyMethod (स्ट्रिंग Parama);

2) कार्यान्वयन: सार्वजनिक शून्य MyMethod (स्ट्रिंग paramA, int paramB); - लेकिन अब के लिए दूसरे पैरामीटर के साथ कुछ भी नहीं करें। कॉल इस बिंदु पर दूसरे पैरामीटर में 0 में गुजरता है।

3) कार्यान्वयन: सार्वजनिक शून्य MyMethod (स्ट्रिंग paramA, int paramB); - लेकिन अब के लिए दूसरे पैरामीटर के साथ कुछ भी नहीं करें। कॉल सही मूल्य में पास होते हैं (उपयोगकर्ता की कहानी 2 की अपेक्षा के अनुसार)

4) कार्यान्वयन: सार्वजनिक शून्य MyMethod (स्ट्रिंग paramA, int paramB); - और सभी कॉल पूरी तरह से उपयोगकर्ता की कहानी को कवर करने के लिए 1 और 2

उत्तर

2

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

आमतौर पर यदि एस 1 और एस 2 दोनों सेट-सेट में हैं तो वे बैकलॉग पर एक साथ बंद हो जाएंगे। यदि यह मामला नहीं है तो आपके पास या तो बड़ी मात्रा में जरूरी चीजें हैं और आपकी परियोजना को एग्इल तकनीक या एस 2 का उपयोग करके इतना लाभ नहीं मिलेगा, वास्तव में यह नहीं होना चाहिए। तो यदि आप S1 और S2 की प्रतिबद्धता के बीच पारित होने के लिए समय (महीनों?) की बड़ी चक उम्मीद कर रहे हैं, तो मैं 1 पैरामीटर इंटरफ़ेस के साथ जाऊंगा। समय अनिश्चितता के लिए हमेशा एक बड़ा contributer है।

+0

मुझे आपको बहुत पसंद है। एकमात्र चीज जो मैं कहूंगा वह यह है कि एस 1 इंटरैक्शन 1 में है और एस 2 पुनरावृत्ति में है 2. मुझे विश्वास है कि प्रत्येक पुनरावृत्ति के अंत में हमेशा एक शिप करने योग्य उत्पाद होना चाहिए। अब: एक पुनरावृत्ति के बाद यह संभावना नहीं है कि व्यवसाय गर्व को शिप करने में प्रसन्न होगा, लेकिन यह निश्चित रूप से क्यूए में जा सकता है और अच्छी तरह से परीक्षण किया जा सकता है।तो क्या आप दक्षता का लक्ष्य रखते हैं और इसे अभी करते हैं (लेकिन एक छोटा सा मौका है क्योंकि आपको यह गलत लगेगा क्योंकि आवश्यकताएं और/या डिज़ाइन बदल सकता है), या केवल पुनरावृत्ति 1 के लिए आवश्यक है? –

+0

यह भी ध्यान दें कि मैं पुनरावृत्ति के लिए कुछ भी गलत 'करने में विश्वास नहीं करता हूं। उदा। ऐसी चीज को लागू करने में कोई बात नहीं है जिसे कहानी 2 के साथ पूरी तरह से फिर से डिजाइन किया जाना होगा। यदि आप जानते हैं कि क्या हो रहा है जो पागल हो जाएगा। लेकिन क्या आपको एस 1 में अतिरिक्त मील जाना चाहिए ताकि एस 2 के साथ आने पर आप न्यूनतम काम कर सकें? या आप फोकस का पक्ष लेते हैं, यह भी जानते हुए: "भविष्यवाणी बहुत मुश्किल है, खासकर भविष्य के बारे में।" - नील्स बोहर (डेनिश भौतिक विज्ञानी)। –

+0

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

0

एक आधुनिक विकास उपकरण के साथ, दूसरा पैरामीटर रखने के लिए विधि को दोबारा करने के लिए बहुत कम लागत है। तो पहली कहानी को लागू करना सबसे अधिक समझ में आता है और फिर बाद की कहानी की बात करते समय विधि को फिर से देखता है।

हालांकि ... सभी अच्छे प्रश्नों की तरह उत्तर वास्तव में "यह निर्भर करता है"। कुछ मामलों में आपका उदाहरण चर्चा के लिए न्याय करने के लिए बहुत छोटा है। क्या होगा यदि कहानी ए "ग्राहक नाम अपडेट करें" और कहानी बी ने कुछ प्रकार की लेन-देन की सुविधा को जोड़ा (शायद paramB TX संदर्भ है)। इस मामले में शायद आपकी कहानियों को कुछ काम की ज़रूरत है। क्या बी के बिना कोई वास्तविक ज्ञान है? क्या आज सुबह ए और बी दोपहर लागू किया गया है, या बी अगले महीने के लिए काम करता है?

+0

या बी संभवतः एक डिफ़ॉल्ट मान के साथ एक वैकल्पिक param है। – amischiefr

+0

हां, मुझे समझ में नहीं आता कि यह एक विकल्प क्यों नहीं है। यह एक सही उदाहरण है कि फ़ंक्शन के अंत में डिफ़ॉल्ट पैरामीटर क्यों दिखाई देते हैं, बिना प्रभाव वाले एक्सटेंशन के। इसके बारे में जावा/सी # बनाम सी ++ तर्क को काटना नहीं चाहते हैं :) –

+0

यह निश्चित रूप से इस परिदृश्य के तहत एक वैकल्पिक पैरामीटर नहीं है। यह जरूरी है कि यह मान उपयोगकर्ता की कहानी को पूरा करने के लिए सही ढंग से लाया गया हो और सेट किया गया हो। 2. यह भी नहीं चाहते कि यह भाषा के उपयोग के बारे में चर्चा हो, अधिक उच्च स्तर की Agile सोच, लेकिन मैं आपके अंक लेता हूं। –

1

शुद्धवादी विकल्प 1 कहेंगे, लेकिन मैं सामान्य ज्ञान सुनूंगा और यदि आप पूरी तरह से 100% आश्वस्त हैं कि यह एक आवश्यकता है तो मैं इसे आपके डिजाइन में कारक बनाउंगा।

हाउवर एग्इल भी रिफैक्टरिंग के आसपास भारी रूप से आधारित है, इसलिए जब तक आप सार्वजनिक रूप से इस इंटरफ़ेस को जारी नहीं कर रहे हैं तो मैं वास्तव में विकल्प 1 के साथ जाऊंगा यदि यह बदलकर मेरे डिजाइन को प्रभावित नहीं होगा।

+0

तो इस मामले में जहां यह एक सार्वजनिक एपीआई था जिसे बदलना नहीं था, तो यह कहानी 2 (या 3, 4 ...) के लिए लागू करना होगा? –

+0

हाँ, व्यक्तिगत रूप से मैं ऐसा करूँगा। इसे जारी करने के बाद एक सार्वजनिक एपीआई अपडेट करना दर्द की दुनिया होगी। बेशक, आपको खुद से पूछना होगा कि आप जनता को एपीआई क्यों छोड़ देंगे क्योंकि यह अभी भी बदल रहा है ... – Duncan

12

बस 1.

पुनर्रचना आसान है करते हैं, भविष्य की भविष्यवाणी नहीं है।

प्रोजेक्ट डिब्बाबंद हो सकता है, नई और महत्वपूर्ण कहानियां प्रकट हो सकती हैं जिसका मतलब है कि कहानी 2 की आवश्यकता नहीं होती है, जब तक आप कहानी 2 तक पहुंच जाते हैं, तो आप समस्या को बेहतर समझ सकते हैं और सब कुछ रिफैक्टर करने की आवश्यकता है। अंतहीन कारण हैं जिनकी आपको आवश्यकता नहीं हो सकती है।

+0

YAGNI दृष्टिकोण – Jacob

+0

+1 के लिए +1। YAGNI। यह एक चरम उदाहरण है लेकिन सिद्धांत बिल्कुल सही है। क्या होगा यदि दस विधियां थीं जिन्हें कहानी 2 में दोबारा सुधारने की आवश्यकता हो सकती है? –

1

"यह निर्भर करता है।" आप कैसे जवाब देते हैं इस पर निर्भर करता है कि आपकी टीम कितनी अनुशासित है।

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

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

 संबंधित मुद्दे

  • कोई संबंधित समस्या नहीं^_^