एक टीम प्रोजेक्ट बनाम फ्लाइंग सोलो विकसित करना

इस सप्ताह मैं चिंगू कोहर्ट्स के हिस्से के रूप में अपनी दूसरी दूरस्थ टीम परियोजना को शुरू करता हूं। ऐसा करने के लिए, मैं अपने पहले age वॉयेज के सहवास में जो कुछ भी सीखा था, उसे प्रतिबिंबित करने के लिए एक मिनट का समय लेना चाहता हूं।

एंड्रयू नील द्वारा फोटो अनस्प्लैश पर

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

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

बेशक, परियोजना में आगे बढ़ते हुए, मुझे एक समूह के हिस्से के रूप में कोडिंग के बारे में सामान्य आशंकाएं और घबराहट थी, जैसे "क्या होगा यदि मेरा कोड समूह में दूसरों के साथ बराबर नहीं है?" और "अगर मैं बनाऊं तो क्या होगा?" गलती और पूरी तरह से समूह के कोड आधार को नष्ट? ”और इतने पर…

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

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

संचार

जब आप किसी प्रोजेक्ट पर अपने आप काम कर रहे हों तो आपके पास हर समय अपने प्रोजेक्ट के दायरे और स्थिति की पूरी तस्वीर होगी। यदि आप ऐसा नहीं करते हैं, तो यह कहना बहुत सुरक्षित है कि आपकी परियोजना में कुछ गंभीर मुद्दे हैं ...

हालाँकि, एक समूह परियोजना के हिस्से के रूप में, आप अपने टीम के साथियों पर निर्भर हैं कि वे आपको कोई भी और सभी बदलाव प्रदान करें (और वे आपके लिए उसी पर निर्भर हैं)।

जेम्स सटन द्वारा अनस्प्लैश पर फोटो

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

जिसका अर्थ है कि वे अपने स्वयं के कार्यों के साथ जारी रखेंगे जैसे कि आपका परिवर्तन नहीं हुआ है। इससे अनावश्यक सिरदर्द हो सकता है और सड़क से कई घंटे बर्बाद हो सकते हैं ... जिनमें से सभी को टीम के सदस्यों के बीच अच्छे संचार के माध्यम से रोका जा सकता है।

सतह पर, यह एक स्पष्ट अवधारणा की तरह लग सकता है और इसके बारे में संपूर्ण लेख लिखने (या पढ़ने) के लायक नहीं है। लेकिन अगर आप अकेले काम करने के अभ्यस्त हैं, तो आपके अपने सिर में अनजाने में होने वाले सभी संचार, यह आपकी सामान्य प्रक्रिया में महत्वपूर्ण रूप से महत्वपूर्ण परिवर्तन का प्रतिनिधित्व करता है।

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

जब संदेह में, अधिक संचार के पक्ष में।

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

मुझे संदेह है कि कई पूर्व टीमें यह कह रही हैं कि "मैं अपना काम नहीं कर पा रही थी, अभी बहुत अधिक संचार चल रहा था!"

कार्यप्रवाह

जो हमें वर्कफ़्लो में लाता है।

वर्कफ़्लो से मेरा मतलब है कि आपकी टीम कैसे git प्रक्रिया का प्रबंधन करती है और यदि वे प्रभावी रूप से शाखाओं, कमिट, पुल अनुरोधों आदि का उपयोग कर रहे हैं।

जैसा कि मैंने पहले कहा, यह मेरी पहली समूह विकास परियोजना थी। मैंने अपनी एकल परियोजनाओं के लिए पहले git का उपयोग किया था लेकिन मुझे बहुत कुछ सीखना था जब यह एक टीम के हिस्से के रूप में git का उपयोग करने के लिए आया था।

सौभाग्य से, फ्रांसेस्को अग्नोलेटो ने एक गाइड की एक श्रृंखला लिखी है जो स्पष्ट रूप से रेखांकित करती है कि टीम सेटिंग में गिट का उपयोग कैसे किया जाना चाहिए। मैं पढ़ने की सलाह देता हूं (और भविष्य के संदर्भ के लिए बुकमार्क करना) तीनों लेख। उन्हें यहां पाया जा सकता है - भाग 1, भाग 2 और भाग 3।

व्यक्तिगत रूप से, मैंने उन्हें कई बार पढ़ा है और हमारे समूह ने उन्हें नियम के रूप में उपयोग किया है कि हमारी टीम वर्कफ़्लो को कैसे हैंडल करेगी।

फ्रांसेस्को ने अपने लेखों में जो लिखा है, मैं उसे आराम करने वाला नहीं हूं, जैसा कि मुझे लगता है कि वह सामग्री को बहुत स्पष्ट रूप से कवर करता है, लेकिन मैं कई बिंदुओं को उजागर करना चाहता हूं जो वह इस लेख से संबंधित हैं।

सबसे पहले, जब प्रभावी ढंग से किया जाता है, तो अच्छा वर्कफ़्लो टीम संचार को बढ़ाता है। जैसा कि मैंने पहले कहा, संचार और वर्कफ़्लो बहुत अधिक intertwined हैं, और प्रत्येक दूसरे को बढ़ा सकते हैं।

अनस्प्लैश पर पवन त्रिकूटम द्वारा फोटो

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

उपर्युक्त गाइडों की दोनों शाखाओं और कमिटों के लिए नामकरण सम्मेलनों पर सलाह है। उन को पढओ!

अब जब हम सभी फ्रांसेस्को के लेख पढ़ चुके हैं और सभी एक ही पृष्ठ पर हैं जहाँ तक वर्कफ़्लो की बात है, तो एक अंतिम बिंदु मैं बनाना चाहता हूँ। अपनी शाखा के दायरे के बाहर बदलाव न करने के बारे में बहुत मेहनती बनें।

यह बहुत महत्वपूर्ण है और समझा नहीं जा सकता है! जब एक टीम के हिस्से के रूप में काम करते हैं, तो उस बदलाव को न करें जो उस शाखा के दायरे में नहीं है जिस पर आप काम कर रहे हैं!

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

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

कोड में परिवर्तन करने से आपके टीम के साथियों में से एक सक्रिय रूप से काम कर रहा है (उन्हें पेशाब करने के अलावा) हर तरह के संघर्ष का कारण बनता है जब वे अपने परिवर्तनों को मर्ज करने का प्रयास करते हैं। वे मर्ज संघर्षों को हल करने में बस उतना ही समय बिता सकते हैं जितना कि वे पहली बार शाखा में परिवर्तन कर रहे थे।

टीम की गतिशीलता के लिए अच्छा नहीं ...

सारांश

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

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

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