क्या नए रंगरूटों को अनुभवी डेवलपर्स से एक अलग उपप्रोजेक्ट देने से नवविवाहिता को अधिक तेज़ी से रैंप करने में मदद मिलेगी?


12

हमारे पास एक टीम में 7 डेवलपर्स हैं और कम समय (लगभग एक महीने) में हमारी विकास गति को दोगुना करने की आवश्यकता है। मुझे पता है कि एक सामान्य ज्ञान नियम है कि "यदि आप अधिक डेवलपर्स को किराए पर लेते हैं, तो आप केवल पहले कुछ महीनों के लिए उत्पादकता में खो देते हैं"। यह परियोजना एक ई-कॉमर्स वेब सेवा है और इसमें कोड की 270K लाइनें हैं।

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

मेरा सवाल यह है: क्या यह दृष्टिकोण नौसिखिया डेवलपर्स को नई परियोजना में आसानी से अनुकूल बनाने में मदद करेगा? दो महीने के इंतजार के बिना तेजी से विकास टीम का विस्तार करने के अन्य तरीके क्या हैं जब तक कि newbies अधिक सॉफ़्टवेयर का उत्पादन शुरू नहीं करता है?

=======

अपडेट करें

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

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

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


2
यदि आप अधिक डेवलपर्स को किराए पर लेते हैं, तो आप केवल पहले महीनों में उत्पादकता में ढीले होते हैं - मैंने कभी नहीं सुना अगर यह हो, लेकिन मुझे यकीन है कि यह अधिक है
BЈовиЈ

2
जब आप दो भागों को एक साथ एकीकृत करने का प्रयास करते हैं तो क्या होता है? क्या कोई मौका है कि दो टुकड़े प्रत्येक अपने स्वयं के परीक्षण पास करेंगे, लेकिन पूरे लॉट में एक बड़ा एकीकरण परीक्षण विफल हो जाएगा? मुझे संदेह है कि आप यह पता लगाने जा रहे हैं कि ब्रूक का नियम इतनी आसानी से दरकिनार नहीं है। उत्कृष्ट रचनात्मक सोच हालांकि; एक लायक 1। और मैं वास्तव में जानना चाहता हूं कि यह आपके लिए कैसे काम करता है।
दाऊद इब्न करीम

1
javana: हम अनुभवी डेवलपर्स को काम पर रखने जा रहे हैं
दिमित्री नेगोडा

2
@DmitryNegoda यदि आप उन्हें पर्याप्त समय में पा सकते हैं। अनुभवी डेवलपर्स आमतौर पर काम से बाहर नहीं होते हैं, भले ही आप उनका साक्षात्कार करें और उन्हें कल एक पद प्रदान करें, उन्हें संभवतः अपने वर्तमान नियोक्ता को कुछ सप्ताह का नोटिस देने की आवश्यकता होगी, इससे पहले कि वे भी शुरू कर सकें। अगर मैं तुम होते तो मैं एक आकस्मिक योजना तैयार कर देता, जैसे कि रात में काम करने की तैयारी और थोड़ी देर के लिए सप्ताहांत।
maple_shaft

4
कोई फर्क नहीं पड़ता कि आप किसी डेवलपर से कितने अद्भुत हैं, वे ~ 1 महीने से कम के 3 सप्ताह में कोड की 100k लाइनों को समझने नहीं जा रहे हैं
Ryathal

जवाबों:


1

सोचा, मैं यहाँ हर किसी की तरह सहमत हूँ, कि:

"... एक देरी परियोजना में अधिक डेवलपर्स को जोड़ने, परियोजना को और अधिक विलंब करने के लिए बनाता है ..."

मुझे लग रहा है, आप इसे करने जा रहे हैं, कहीं भी, इसलिए ...

आपका विचार मदद कर सकता है, यदि, आपकी मौजूदा परियोजना, पर्याप्त व्यवस्थित है, तो मॉड्यूल, सबसिस्टम या सबप्रोजेक्ट द्वारा।

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

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

नए डेवलपर्स जो प्रोग्रामिंग लैंग्वेज या प्रोग्रामिंग एनवायरमेंट जानते हैं, उनके पास पर्याप्त नहीं है, सॉफ्टवेयर एप्लाएंसेज बहुत जटिल हो सकते हैं।

क्या आपके पास अप्लीकेशन के कुछ डॉक्यूमेंटेशन हैं जैसे: UML, ER, Codd-Yourdon, जो भी हो?

शुभ लाभ।


हम कोड की केवल 100K लाइनों के बारे में बात कर रहे हैं, यह उस जटिल नहीं है, हालांकि चिंता के लिए धन्यवाद
दिमित्री नेगोडा

1
@ डिट्री नेगोडा: जटिलता एलओसी का कार्य नहीं है।
जोर्मेनो

काफी शोध (उदाहरण के लिए बोहम) है जो दर्शाता है कि प्रोग्रामर की उत्पादकता, औसतन, LOC का एक कार्य है।
दिमित्री नेगोडा

15

मेरा सवाल यह है कि क्या यह दृष्टिकोण नौसिखिया डेवलपर्स को नई परियोजना के लिए आसानी से अनुकूल बनाने में मदद करेगा?

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

दो महीने के इंतजार के बिना तेजी से विकास टीम का विस्तार करने के अन्य तरीके क्या हैं जब तक कि वे अधिक सॉफ़्टवेयर का उत्पादन शुरू नहीं करते हैं?

  • अपने स्वयं के निर्माण की कोशिश करने के बजाय किसी मौजूदा उत्पाद को खरीदें या लाइसेंस दें। क्या आपको वास्तव में चेकआउट व्हील को सुदृढ़ करने की आवश्यकता है?

  • जैसा कि मैंने ऊपर कहा, ऐसे लोगों को किराए पर लें, जिन्हें आप चाहते हैं कि किस तरह की प्रणाली का निर्माण करने का अनुभव हो।

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

  • क्या आपने आवश्यकताओं का लिखित सेट बनाया है? यदि नहीं, तो अब ऐसा करें। यदि आप उम्मीद करते हैं कि नई टीम को ऐसा करने के बजाय परियोजना को डिजाइन करना चाहिए, तो आपको एक स्पष्ट डिजाइन दस्तावेज तैयार करना चाहिए, लेकिन नई टीम के सदस्यों से इनपुट के जवाब में परिवर्तन के लिए खुला होना चाहिए।

  • क्या आपके पास एक अच्छी तरह से परिभाषित विकास प्रक्रिया है? बग डेटाबेस? संस्करण नियंत्रण? कोड की समीक्षा प्रक्रिया? शैली गाइड? उन चीजों को जगह मिल जाए।

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


1
आवश्यकताओं के लिखित सेट के लिए +1, वे थोड़ा पुराने हैं ...
दिमित्री नेगोडा

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

कोड स्व-दस्तावेजीकरण है, और हम केवल अनुभवी डेवेलपर्स को काम पर रखने वाले हैं। और हां, वर्तमान डेवलपर्स नए लोगों की मदद करेंगे, और उनकी गति थोड़ी कम हो जाएगी। मैं सिर्फ यह उम्मीद कर रहा हूं कि 100K लोक प्रोजेक्ट में डेवलपर्स को काम पर रखना 270K लोक प्रोजेक्ट में हायरिंग जितना दर्दनाक नहीं होगा, और यह सवाल था।
दिमित्री नेगोडा

क्या आपके पास एक आंतरिक विकी है, या लैन पर बिखरे हुए डॉक्स में सब कुछ संग्रहीत है?
स्पेंसर रथबुन

1
100k, 50k या 10k सभी एक ही चीज़ का प्रतिनिधित्व करेंगे - एक टन कोड जिसे कोई भी व्यक्ति अपने सिर में स्थानांतरित नहीं करेगा। यदि कोड की कई सौ लाइनें हैं, तो यह उचित है। एक बार जब आप कई हजार से अधिक हो जाते हैं तो आपके पास एक जटिल प्रणाली होती है और गति की इच्छा अक्सर प्राप्त नहीं होती है।
माइकल डुरंट

12

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

मैं आपकी मौजूदा टीम को दो में विभाजित करने और नए सदस्यों को दोनों टीमों में भर्ती करने का सुझाव देता हूं। इस तरह दोनों टीमों में ऐसे लोग हैं जो नए लोगों को सलाह दे सकते हैं और यह सुनिश्चित कर सकते हैं कि एक सामान्य, सुसंगत वास्तुशिल्प दृष्टि रखी जाए।

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


4
+1 - आप निश्चित रूप से नए लोगों को बोर्ड पर लाने के लिए अपने पुराने डेवलपर्स का उपयोग करना चाहते हैं। हालांकि यह अपरिहार्य है कि यह आपको थोड़ा धीमा कर देगा।
मायके

साथ ही +1। आप चाहते हैं कि आपके अनुभवी डेवलपर्स नए लोगों को सलाह दें। यहां तक ​​कि अगर नए लोगों के पास बहुत अनुभव है, तो वे ठीक से नहीं जानते हैं कि आपकी कंपनी कैसे काम करती है।
एंडी

9

दिमित्री, थोड़े समय में अपने विकास की गति को दोगुना करना एक अविश्वसनीय महत्वाकांक्षी लक्ष्य है। कुछ अच्छे सुझावों को यहाँ पोस्ट किया गया है; लेकिन, कोई फर्क नहीं पड़ता कि आप क्या कोशिश करते हैं, इस बात से अवगत रहें कि ऐसा नहीं हो सकता है । यदि आपके विकास की गति दोगुनी नहीं होती है, तो व्यावसायिक दृष्टिकोण से क्या परिणाम होंगे? क्या आप एक समय सीमा को पूरा करने के लिए पुश करने की कोशिश कर रहे हैं?

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


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

अगर ऐसा है, तो शायद एक कदम में अपनी विकास की गति को दोगुना करने के लक्ष्य के बजाय, शायद आप समय की अवधि में "रैंप अप" करने की कोशिश कर सकते हैं।
एलेक्स डी

4

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

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

MMM का दूसरा हिस्सा यह था कि जैसे-जैसे टीम बढ़ती है, वैसे-वैसे संचार समस्याएँ बढ़ती जाती हैं। मुलाकातें बड़ी होती जाती हैं, ईमेल चेन लंबी होती जाती है ...

मैं उन्हें छोटे समूहों में लाऊंगा और यह जानूंगा कि लंबे समय तक उत्पादकता टीम के बढ़े हुए आकार के समानुपाती नहीं होगी। बोर्डिंग लागत और उपकरणों के कारण, पहले कुछ महीनों के दौरान नकदी प्रवाह पर नाली का एहसास महत्वपूर्ण हो सकता है।

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


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

2

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

कृपया पुराण-मास पढ़ें। आपको स्पष्ट रूप से वरिष्ठ प्रबंधन को बताने में सक्षम होने की आवश्यकता है कि वे परियोजना को गति देने के लिए वर्जन विकल्प क्यों बना रहे हैं। ।


आपके सभी प्रश्नों के लिए हां, पिछले एक को छोड़ दें।
दिमित्री नेगोडा

0

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


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

मैं सिर्फ यह उम्मीद कर रहा हूं कि 100K लोक प्रोजेक्ट में डेवलपर्स को काम पर रखना 270K लोक प्रोजेक्ट में हायरिंग जितना दर्दनाक नहीं होगा, और यह सवाल था।
दिमित्री नेगोडा
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.