क्या वास्तुकला से लेकर विकास तक के हैंडओवर के बारे में कोई सर्वोत्तम प्रथाएं हैं?

Question

हम वास्तुकला से विकास तक के कार्यों को सौंपने की प्रक्रिया में सुधार देख रहे हैं।

पैमाने के एक छोर पर यह कोई वास्तु मार्गदर्शन नहीं है कि आप अराजकता का जोखिम उठाते हैं, प्रत्येक डेवलपर अपने तरीके से काम कर रहा है।

पैमाने के दूसरे छोर पर जहां सब कुछ निर्दिष्ट है, विनिर्देश विकास से अधिक समय लेता है, और आप बहुत उबाऊ विकास कार्यों को जोखिम में डालते हैं।

क्या किसी को इन चरम सीमाओं के बीच एक इष्टतम मध्य जमीन मिली है? आप किन कलाकृतियों को विकास तक पहुँचाते हैं? उदाहरण के लिए: मॉड्यूल, वर्ग संरचना, या अनुक्रम आरेख?

Comments

मैंने यहां एक टिप्पणी पढ़ी जिसमें कहा गया था कि वास्तुकला एक टीम खेल है। यदि आप आर्किटेक्ट से लेकर विकास टीम तक सौंप रहे हैं, तो आप शायद गलत कर रहे हैं।

— चींटी

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

— रॉबिंस

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

— डेविड थॉर्नले

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

— maple_shaft

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

— जेम्स एंडरसन

Answer 1

मैं यह कहकर शुरू करूंगा कि एक अलग "आर्किटेक्चर" टीम की अवधारणा अच्छी सॉफ्टवेयर विकास प्रथाओं का एक साथ है। कॉर्पोरेट वातावरण में आर्किटेक्चर टीमों को सबसे खराब हाथीदांत-टॉवर छद्म-बौद्धिक बैल * * कलाकारों की एक परिणति होती है, जो डेवलपर्स के पूल के बीच पाया जा सकता है।

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

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

• डेवलपर्स डिजाइन को समझ नहीं पाते हैं, या मौजूदा कार्यान्वयन की वास्तविकताओं के कारण इसे अस्वीकार कर देते हैं, और अंत में अपने स्वयं के अनजाने डिजाइन को निर्धारित करते हैं और इसके बजाय इसे लागू करते हैं। स्थिति औपचारिक डिज़ाइन दस्तावेज़ हैं जो सॉफ़्टवेयर के कार्यान्वयन को प्रतिबिंबित नहीं करते हैं।

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

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

इस समस्या को कम करने का सबसे अच्छा तरीका वास्तुकला समूह को बदलना है और संभवतः उन्हें तकनीकी प्रमुख पदों पर रखना है। आर्किटेक्चर ग्रुप की भूमिका कमोबेश "टेक्नॉलॉजी लीड्स ऑफ स्क्रैम" की होनी चाहिए। उन्हें केवल शायद ही कभी मिलना चाहिए और केवल उच्चतम स्तर की तकनीकी दिशा के मुद्दों पर चर्चा करनी चाहिए, जैसे। विचार करें कि जावा से स्काला की ओर पलायन चर्चा, MySQL के लिए ओरेकल को त्याग कर, संभवतः आम उपयोगिता पुस्तकालय लिख रहा है जो एक निश्चित TYPE डिजाइन प्रक्रिया को दूसरे पर करता है, StarUML से Altova UML पर स्विच करना।

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

Comments

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

— S.Robins

@ एस.रोबिंस सभी उचित सम्मान के साथ, ओपी का सवाल था कि समस्या को कैसे हल किया जाए (इस साइट पर सभी प्रश्न समस्या का समाधान कैसे किया जाए)। टीम संरचना को बदलना ही एकमात्र सही तरीका है समस्या का समाधान। अन्य सुझाव महान हैं, लेकिन वे सिर्फ बैंड-एड्स हैं। वे लंबी अवधि में मदद नहीं करते हैं।

— maple_shaft

+1: मैंने आर्किटेक्ट्स की एक अलग टीम के साथ दो कंपनियों में काम किया है, और एक CTO के साथ है जिसने सभी वास्तु निर्णय लेने पर जोर दिया लेकिन उसकी कोई डिलीवरी जिम्मेदारी नहीं थी। जैसा आप वर्णन करते हैं, वैसे ही तीनों का विकास हुआ। कोई भी मजबूत डेवलपर्स को बनाए नहीं रख सकता; "मृत सागर" प्रभाव स्पष्ट किया गया था। परियोजनाएं पूरी हुईं, लेकिन अत्यधिक उच्च लागत पर।

— केविन क्लाइन

Answer 2

आर्किटेक्चर से डेवलपमेंट टेस्ट और ऑपरेशंस तक की जानकारी को कैसे प्रवाहित किया जाता है, इसमें हमेशा समस्याएं रही हैं। इन समस्याओं से निपटने का तरीका इम्हो जैसे कई कारकों पर निर्भर करता है:

• सॉफ्टवेयर का आकार
• जटिलता
• आपके संगठन में संस्कृति
• विश्वास।

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

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

ज्यादातर सरकार और वित्त परियोजनाओं के लिए यह आवश्यक है कि अधिक दस्तावेज़ीकरण को आगे लिखा जाए और यह आपकी पसंद पर वास्तविक दुनिया की प्रतिक्रिया के साथ लंबा समय ले सकता है। मेरे दिमाग में सबसे बड़ा कारण यह है कि इनमें से कई परियोजनाएं विफल हैं। फिर भी अगर यह आपकी स्थिति है तो मैं आवश्यकताओं को पूरा करने के लिए दस्तावेज़ीकरण करूँगा और उपयोग के विकल्प 1 या 2 की तुलना में वास्तव में सॉफ़्टवेयर का निर्माण और प्रलेखन को परिष्कृत / अनुकूलित कर सकता हूं।

उम्मीद है की यह मदद करेगा।

Answer 3

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

पैमाने के दूसरे छोर पर अगर सब कुछ निर्दिष्ट किया जाता है, तो विनिर्देश विकास से अधिक समय लेता है। और आपको बहुत उबाऊ विकास कार्य होने का जोखिम है।

वास्तव में आप के लिए प्रयास करना चाहिए कुछ है। यदि डिजाइन और विनिर्देश पर्याप्त ठोस हैं कि विकास कार्य उबाऊ हैं, तो विकास की लागत कम हो जाती है। एक विनिर्देशन को तय करना बहुत कम खर्चीला है, क्योंकि यह कोड को ठीक करना है, और सॉफ्टवेयर परियोजनाओं की सबसे बड़ी लागत बिल्ड नहीं है, यह दीर्घकालिक समर्थन है। और समर्थन कोड जो एक ठोस कल्पना पर आधारित है, बहुत कम महंगा है।

Comments

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

— maple_shaft

यह एकदम सच है। हालांकि चाल सही संतुलन पा रही है।

— माइकल

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

— बिल ग्रिब्बल

Answer 4

मैं पूरी तरह से Maple_shaft के जवाब से सहमत नहीं हूं, लेकिन मेरी पूरी बात कहने के लिए टिप्पणी में पर्याप्त जगह नहीं थी! ;-)

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

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

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

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

Comments

अगर मैं कर सकता था +1 और 1000 अधिक! आपने मेरे उत्तर पर और अधिक विस्तार से प्रकाश डाला। मैं विशेष रूप से इस उद्धरण से प्यार है, architects should first and foremost be facilitators & communicators, and designers second। यह अनिवार्य रूप से मैं अपने उत्तर में कह रहा हूं। तथ्य यह है कि आर्किटेक्ट डेवलपर्स को डिजाइन चश्मा वितरित कर रहे हैं, मौलिक रूप से गलत है और इसके खिलाफ जाता है कि एक आर्किटेक्ट किसी संगठन के लिए मूल्य कैसे लाता है। यही कारण है कि मैं अपने जवाब में कठोरता से अनिवार्य था कि एक टीम पुनर्गठन ही एकमात्र जवाब है।

— maple_shaft

Answer 5

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

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

Answer 6

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

इसके अलावा नई टीम के लिए ऐसी धारणाएँ हैं जो अमान्य हैं।

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

Answer 7

मैं कहूंगा कि क्लास डायग्राम एक मॉडल बनाने के साथ-साथ कोड का भी समाधान है। वर्ग आरेख आपकी परियोजना वास्तुकला के स्थिर दृश्य का प्रतिनिधित्व करता है। मेरा मतलब है कि आपके पास संकुल> कक्षाएं, पूर्णांक, enum> विशेषताएँ, mehtods आदि ...> आदि हैं। यदि आप अच्छी तरह से देखते हैं तो UML2 मेटामोडेल में जावा या डॉटनेट परियोजना के समान संरचना है।

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

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