एक टीम में विभिन्न विकास शैलियों (टॉप-डाउन बनाम बॉटम-अप) का सामना कैसे करें?

Question

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

तरीके

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

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

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

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

समस्या

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

टॉप-डाउन डेवलपर समय बर्बाद कर रहा है क्योंकि काम को समानांतर करने के बजाय, टॉप-डाउन डेवलपर अब अक्सर नीचे-ऊपर डेवलपर के साथ सही डिजाइन को काम करने के लिए नीचे बैठता है, दोनों को उस बिंदु पर क्रमबद्ध करता है जहां यह और भी तेज हो सकता है। 1 व्यक्ति को 2 से काम करने के लिए।

दोनों डेवलपर्स एक साथ काम करते रहना चाहते हैं, लेकिन ऐसा नहीं लगता कि संयोजन वास्तव में अभ्यास में दोनों की मदद कर रहा है।

लक्ष्य

सामान्य लक्ष्य स्पष्ट रूप से कोडिंग प्रभावशीलता को अधिकतम करना है (यानी समय की बर्बादी को कम करना) और उपयोगी सॉफ़्टवेयर लिखना।

प्रश्न

सीधे शब्दों में कहें, आप इस समस्या को कैसे हल करते हैं और इस स्थिति का सामना करते हैं?

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

क्या कोई बेहतर तरीका है?

Comments

मेरे लिए ऐसा लगता है कि "ऊपर नीचे" आदमी बिग डिजाइन अप फ्रंट करना चाहता है। जबकि "बॉटम टॉप" आदमी सिर्फ हैकिंग शुरू करना चाहता है और इंक्रीमेंट से सॉल्यूशन हासिल करना चाहता है।

— व्यंग्यात्मक

दोनों सही हैं। आपको एक समझौता खोजने की जरूरत है, जिस पर दोनों सहमत हों। एक पक्ष को यह सीखने की ज़रूरत है कि सामने वाले कुछ डिज़ाइन लंबे समय में समय बचा सकते हैं। दूसरे पक्ष को यह सीखने की जरूरत है कि एक बिंदु पर, सोच को रोकना और काम करना शुरू करना फायदेमंद है।

— व्यंग्यात्मक

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

— मेहरदाद

शब्द "संचार" दिमाग में आता है।

— ब्रायन ओकले

प्रबंधक कौन है? निर्णय कौन करता है?

— corsiKa

Answer 1

जाहिर है कि वे दोनों गलत हैं।

नीचे वाला आदमी कोड पर हैकिंग कर रहा है और कभी भी कुछ ऐसा उत्पन्न नहीं करेगा जो वह करता है जो वह करने वाला है - यह एक निरंतर मंथन होगा क्योंकि अज्ञात आवश्यकताएं निर्धारित की जाती हैं।

ऊपर से नीचे का आदमी वास्तुशिल्प की दृष्टि से बस इतना ही खर्च कर सकता है और कुछ भी नहीं कर सकता है।

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

इसे एजाइल कहा जाता है (न कि फुर्तीले का बीएस संस्करण जो कि कुछ लोग अभ्यास करते हैं जहां कार्य करने वाले सॉफ्टवेयर की तुलना में प्रक्रियाएं अधिक महत्वपूर्ण हैं) लेकिन यह सच है कि सामान्य रूप से वर्णित और समझे गए अंतिम लक्ष्य के लिए काम करने के साथ ही चुस्त हो जाता है।

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

Comments

चंचल के बीएस संस्करण के लिए +1। आजकल बहुत से लोग फुर्तीले हो रहे हैं ...

— टी। सर -

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

— मेहरदाद

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

— gbjbaanb

@ मेहरदाद आपको जिस उत्तर की आवश्यकता है, लेकिन अभी उसके लायक नहीं है;)

— पागल

@ थेल्सपेरेरा "चपल का बीएस संस्करण" क्या है?

— Sjoerd222888

Answer 2

दोनों डेवलपर्स को एक -दूसरे के लिए आपसी सम्मान बनाए रखने की जरूरत है ।

शीर्ष डाउन व्यक्ति को इस तथ्य का सम्मान करने की आवश्यकता है कि नीचे वाला व्यक्ति कुछ ऐसा लेकर आया है जो वास्तव में काम करता है। जैसा कि मेरे "क्वांट" प्रोफेसरों में से एक ने मुझसे कहा, "एक कामकाजी मॉडल की कीमत 1000 अनुमान है।" अगर ऐसा है, तो नीचे वाले व्यक्ति को अपने "डिज़ाइन" को फिर से करने पर विचार करना चाहिए ताकि नीचे के व्यक्ति के काम को समायोजित किया जा सके।

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

Answer 3

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

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

सभी को सूचित रखें!

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

आपको उन्हें आशीर्वाद के रूप में साथ काम करते हुए भी देखना चाहिए। तथ्य यह है कि वे एक साथ काम कर रहे हैं और अपनी गलतियों को ठीक कर रहे हैं क्योंकि वे जाते हैं एक अच्छा संकेत है। मैंने आपकी पोस्ट को यह सोचकर आधा कर दिया कि "यार ये दोनों शायद एक-दूसरे से नफरत करते हैं ..." और मेरे आश्चर्य के लिए आपने कहा कि वे एक साथ काम करना चाहते हैं।

मुझे लगता है कि यह उद्धरण आपके परिदृश्य को देखते हुए उपयुक्त है।

"अगर दो लोग हर बात पर सहमत हैं, तो उनमें से एक अनावश्यक है।" ~ कोई पुराना लड़का

Answer 4

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

हो सकता है कि यह कई दिमागों के लिए एक अच्छा मॉडल हो।

Comments

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

— hBy2Py

Answer 5

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

यह पर्यवेक्षण के माध्यम से किया जा सकता है जैसा कि अन्य लोगों ने बताया है, लेकिन इससे भी बेहतर आपसी समझौते द्वारा किया गया है जब डिजाइन करने के लिए और कब कोड करना है, और सामान्य रूप से कोड से बचने के लिए जो वर्तमान में डिजाइन में है।

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

Comments

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

— मेहरदाद

आदर्श रूप से, दोनों डिजाइन और कोडिंग पर काम करेंगे, इसीलिए शेड्यूल होना, भले ही आपकी टीम छोटी हो, अच्छा है। बस कुछ "मीटिंग्स" की योजना बनाएं, जब दोनों मॉड्यूल को डिजाइन / लागू करने के बारे में प्रश्नों और योगदान को स्पिन कर सकते हैं, और अगले कार्य के लिए समय आवंटित कर सकते हैं और अगली बैठक की योजना बना सकते हैं। फुर्तीले-को छोड़कर आपको इसे इस तरह से कॉल करने की आवश्यकता नहीं है;)

— आर्थर हैवेलिस

दुर्भाग्य से, ऐसे मामलों में, टॉप-डाउन लड़का योजनाएं बनाएगा, और नीचे-ऊपर वाला लड़का उन्हें अनदेखा करेगा। अर्थात। दोनों अपनी-अपनी बात करते रहेंगे।

— gbjbaanb

Answer 6

एक नोट: आपने कहा

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

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

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

आपके लिए यहां एक बड़ी संभावना है कि दोनों लोगों को अपने तरीके से काम करने की अनुमति दें, और फिर भी काम करने के लिए टुकड़ों को मिलाएं।

1. मैं उन दोनों को बैठकर चर्चा करूंगा, उन्हें दूसरे के दृष्टिकोण से देखने के लिए प्रोत्साहित करूंगा।

2. उस चर्चा के बाद, आप योजना के बारे में बात करना शुरू कर सकते हैं: यह एक टीम के रूप में किया जाना चाहिए, इस समझ के साथ कि न तो दूसरे को 'स्वीकार' करना है, लेकिन समझौता करना होगा। एक कोडबेस के लिए आर्किटेक्चर की योजना बनाने के बहुत सारे तरीके हैं जो इसे अतिरिक्त कोड का एक टन पेश किए बिना, बाद में आसानी से आगे बढ़ाने की अनुमति देते हैं।

3. एक बार जब आप उन्हें किसी प्रकार के आघात के लिए आ सकते हैं, तो उन्हें जंगली चलाने दें! उच्च स्तर की वास्तुकला, इंटरफेस, पदानुक्रम आदि की योजना बनाते हुए 'ऊपर नीचे आदमी' ड्राइव करें, एक बार जब मॉड्यूल की एक जोड़ी की योजना बनाई है, तो 'नीचे ऊपर आदमी' को कूदने दें और कोड लिखना शुरू करें। समग्र परियोजना के लिए अन्य के तरीकों को स्वीकार करने के लिए औपचारिक रूप से सहमत होने के लिए उन्हें प्राप्त करें: आसान भविष्य के परिवर्तनों के लिए अनुमति देने की योजना अच्छी है, लेकिन इसे उस तरह से कोडित नहीं करना है। कोड की संरचना प्राप्त करने के लिए इंटरफेस बनाएं और स्टब आउट करें, और स्वीकार करें कि भविष्य के लिए कोड का एक अच्छा सा हिस्सा वास्तव में जरूरत तक लिखा नहीं जाएगा।

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

5. यह संभवतः सबसे महत्वपूर्ण बिंदु है: जिस चक्र में काम किया जा रहा है, उसके बजाय केवल प्रक्रिया के बारे में बात करते हैं। निर्मित किए जा रहे गतिशील पर प्रतिबिंबित: आपके द्वारा पूछे जाने वाले चार प्रश्न हैं। क्या अच्छा हुआ जो हमें करते रहना चाहिए? बेचारा क्या गया कि हमें करना बंद कर देना चाहिए? हम क्या याद कर रहे हैं? हम जो कुछ याद कर रहे हैं, उसके बारे में हम क्या कर सकते हैं?

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

Answer 7

आम तौर पर, मेरे करियर के अनुभव में, सामने की ओर अपर्याप्त डिजाइन है। और जो डिजाइन सामने होता है, वह कम गुणवत्ता वाला होता है । ये गलत है। ज्यादातर इसलिए क्योंकि इसका परिणाम (अधिक या कम डिग्री तक) दीवार पर कीचड़ फेंकना और यह देखना है कि क्या चिपक जाता है। गेट-गो से तकनीकी ऋण में सेंध लग जाती है।

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

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

Comments

"सामने की ओर अपर्याप्त डिज़ाइन है। और जो डिज़ाइन सामने होता है वह निम्न गुणवत्ता वाला होता है।" - आम तौर पर अप-फ्रंट डिज़ाइन की निम्न गुणवत्ता वास्तव में यही कारण है कि आप इसे जितना चाहें उतना नहीं देख पाएंगे।

— user1172763

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

— maple_shaft

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

— gbjbaanb

Answer 8

न ही दृष्टिकोण पर्याप्त है। ऐसा लगता है कि उनमें से प्रत्येक दूसरे दृष्टिकोण की छोटी-छोटी अभिव्यक्तियों को महसूस करने के लिए काफी चालाक या अनुभवी है (शायद वे जल गए हैं?) लेकिन अपने स्वयं के चयनित दृष्टिकोण की लघु-हास्य को देखने में विफल रहे ...

सच है, एक मिश्रित दृष्टिकोण आवश्यक है:

• "राइट" डिज़ाइन अपफ्रंट के साथ आना लगभग असंभव है; दर्द बिंदुओं, अड़चनों की पहचान करने के लिए प्रयोग की एक डिग्री आवश्यक है, ... (संकेत: वे कभी नहीं हैं जहां आपको लगता है कि होगा)
• कहीं भी जाना असंभव है बस "जा रहा है", आप कहीं और समाप्त होने की संभावना रखते हैं जो आप नहीं चाहते थे, या बस हलकों में चलाएं, कुछ भी नहीं

हालांकि, आप दोनों को मिला सकते हैं:

• दिशा-निर्देश देने वाला बुनियादी ढांचा और बुनियादी ढांचे का एक कंकाल है
• और विकासशील घटक इस दृष्टि को फिट करते हैं

क्योंकि इस उद्देश्य को पूरा करने वाली कोई भी मौजूदा प्रणाली मौजूद नहीं है, इसलिए यह समझना जरूरी है कि:

• प्रयोग / प्रोटोटाइप आवश्यक होगा
• इसलिए, पुनरावृत्ति आवश्यक होगी

इसलिए, जितनी जल्दी हो सके "काम" प्रणाली तक पहुंचने पर जोर दिया जाना चाहिए, भले ही इसका मतलब है कि कोने के मामलों की अनदेखी, आदि ... यह "पतली ऊर्ध्वाधर टुकड़ा" की अवधारणा है: घर की नींव बनाने के बजाय , फिर दीवारें, फिर छत की संरचना, ... और केवल बहुत ही अंत में उपयोग करने योग्य कुछ (या इसे प्राप्त करने, या इसे या वास्तव में उपयोग करने योग्य नहीं होने के कारण) ... यह बेहतर है कि पहले एक पूरी तरह से तैयार किए गए कमरे का निर्माण करें । बाथरूम की तरह। यह तुरंत प्रयोग करने योग्य है, और इसका उपयोग प्रतिक्रिया एकत्र करने के लिए किया जा सकता है।

बहुमूल्य होने के लिए प्रतिक्रिया के लिए, हालांकि, पहले एक मुख्य भाग से निपटना सबसे अच्छा है।

---

तो, अपने सहकर्मियों के साथ क्या करते हैं?

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

फिर, उन्हें इस बात पर सहमत होने की आवश्यकता है कि कौन क्या करता है। ध्यान दें कि ऊपर बताए गए मध्य मैदान के दृष्टिकोण में, दोनों को उन कार्यों को ठीक करना चाहिए जिनकी वे सराहना करते हैं।

ध्यान दें कि दोनों कंकालों का निर्माण और ईंटों का निर्माण करना वृद्धिशील रूप से सबसे अच्छा है।

1. उन दोनों को कंकाल का एक मोटा स्केच मिलना चाहिए, और फिर एक साथ तय करना होगा कि पहले किस पर ध्यान केंद्रित करने के लिए "पतली टुकड़ा"
2. नीचे-ऊपर आदमी को "पतली स्लाइस" के सबसे अच्छे से समझे जाने वाले टुकड़े पर काम करना शुरू कर देना चाहिए
3. शीर्ष-नीचे वाले व्यक्ति को कंकाल को खोलना शुरू कर देना चाहिए, आदर्श रूप से स्लाइस को पूरा करने के लिए सबसे अवरुद्ध टुकड़ों से निपटना चाहिए

कुल्ला और दोहराएं जब तक आप टुकड़ा काम नहीं करते; जरूरत के अनुसार ट्विक करने के तरीके के साथ प्रतिक्रिया जमा करें।

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

Comments

4 प्रमुख शब्दों को हटा दें, वे एक अनावश्यक पंच-रेखा हैं (और इस अन्यथा संतुलित उत्तर के साथ कुल विरोधाभास हैं)।

@Tibo: आप कठोर हैं, अगर हम लोगों को थोड़ा हिला भी नहीं सकते ...: D

— Matthieu M.

सहमत :) मैं उन लोगों को हिलाना पसंद करता हूं जो एक हाथीदांत टॉवर में रहते हैं, उम्मीद करते हैं कि सब कुछ उनके पैरों के नीचे बिखर जाएगा। -1 -> +1 btw।

अंत में, एक और व्यक्ति जो दरवाजे से बाहर कम से कम-व्यापक कार्यक्षमता के साथ अंत-टू-एंड प्रोटोटाइप प्राप्त करने में ज्ञान देखता है जितनी जल्दी हो सके। इस उत्तर के लिए धन्यवाद, मुझे इसे पढ़ने में मज़ा आया।

— फजी विश्लेषण

Answer 9

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

एकमात्र कुशल समाधान जो मैं सोच सकता हूं कि समय बर्बाद नहीं होता है, प्रत्येक डेवलपर को डिजाइन के लिए अपनी खुद की शैली का पालन करने देना चाहिए।

वास्तव में, यह अत्यधिक अक्षम हो सकता है ... क्योंकि संभावना है कि बहुत सारे संघर्ष और पुनरावृत्ति होंगे। इससे भी बदतर, आप कुल परियोजना की विफलता के साथ समाप्त हो सकते हैं।