डेवलपर्स के बीच काम को विभाजित करने का सबसे अच्छा तरीका क्या है

Question

मेरी टीम और मैं एक साइट का पुनर्निर्माण कर रहे हैं जिसे हमने लगभग दस साल पहले विकसित किया था, और हम इसे एजाइल में करना चाहते हैं।

इसलिए जब मैंने पढ़ने में बहुत समय बिताया (शायद पर्याप्त नहीं) तो मुझे इस सवाल से परेशानी हो रही है कि डेवलपर्स के बीच काम को कैसे विभाजित किया जाए।

मैं और विशिष्ट हो जाऊंगा और कहूंगा कि साइट को अलग-अलग मॉड्यूल से विभाजित किया गया है जिसमें एक दूसरे के बीच ज्यादा एकीकरण नहीं है।

डेवलपर्स के बीच काम को विभाजित करने का सबसे अच्छा / सबसे स्वीकृत तरीका क्या है?

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

या शायद कुछ पूरी तरह से अलग?

Comments

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

यदि आप उस प्रश्न का एक भी सरल उत्तर पा सकते हैं तो बधाई हो, आपने इसे बना लिया है। जब आप 40 वर्ष के हो सकते हैं, तब तक आप सेवानिवृत्त हो सकते हैं और वे शायद आपके बाद एक कंप्यूटर विज्ञान पुरस्कार भी अपने नाम करेंगे। ;)

— गॉर्डन

Answer 1

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

• प्रति मॉड्यूल डिवाइडिंग डेवलपर्स:

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

• हर कोई एक ही समय में एक ही मॉड्यूल पर काम करता है

  • हमने कोशिश की कि एक रिलीज के लिए, जब प्रबंधन ने फैसला किया कि वे पूरी टीम पर चुस्त लगेंगे और यह पूरी तरह से उनका तरीका होगा। यह एक निरपेक्ष ट्रेन के मलबे के रूप में है। हमारे पास एक साल में 9 डेवलपर्स की एक टीम थी जो आमतौर पर 1 डेवलपर द्वारा की जाती थी। (मैं यहाँ अतिशयोक्ति कर सकता हूं लेकिन बहुत अधिक नहीं)।
  • किसी को भी ऐसा नहीं लगा कि कोई सांस लेने वाला कमरा है। जो लोग सॉफ्टवेयर की परवाह नहीं करते थे, वे घर पर सही महसूस करते थे क्योंकि एक बड़े पैक का हिस्सा होने के कारण, वे सिर्फ समूह में पतला हो जाते हैं। हममें से जिन लोगों को सॉफ्टवेयर का शौक था, वे बिल्कुल महसूस करते थे कि 9 लोग इस पर सहमत होने की सीमा से बाहर जाने या बाहर निकलने की कोई स्वतंत्रता नहीं है।
  • सभी बैठकें हमेशा के लिए चली गईं कि मैं खुद को गोली मार दूं। एक ही कमरे में एक राय वाले बहुत से लोग एक ही फ्रीकिन डीएलएल पर काम करने के लिए मजबूर हुए। डर।
• पिछले रिलीज़ में, हमने कुछ अलग करने की कोशिश की है
  • सबसे पहले और सबसे महत्वपूर्ण, विकास समूह को 3-4 डेवलपर्स की छोटी टीमों में तोड़ दें। प्रत्येक टीम ने एक दूसरे से सापेक्ष अलगाव में काम किया, लेकिन टीम के भीतर लोगों ने अधिक सामंजस्यपूर्ण ढंग से काम किया
  • इस दृष्टिकोण के साथ, स्टैंड अप तेज हैं और ठोस 4 घंटे की तुलना में बैठक की बैठक में 1-2 घंटे लगते हैं।
  • हर कोई लगा हुआ है क्योंकि प्रत्येक टीम केवल इस बात पर चर्चा करती है कि उस टीम के डेवलपर्स को क्या परवाह है।
  • प्रत्येक टीम से टेक लीड अन्य टेक से बात करता है समय-समय पर सुनिश्चित करता है कि समग्र परियोजना ट्रैक पर है।
  • लोगों को एक विशिष्ट मॉड्यूल का "मालिक" बनाने के बजाय, हमने लोगों को विशेषज्ञता के क्षेत्रों को सौंपा, इसलिए जब हमने पहली बार परियोजना शुरू की तो ऐसा लगा कि लोगों का अपना मॉड्यूल है, लेकिन कई महीनों के बाद, डेवलपर्स एक दूसरे के कोड को देखना शुरू कर देंगे। क्षेत्रों में अतिच्छादन शुरू हुआ।
  • कोड समीक्षा आवश्यक हैं। यह दूसरी रिलीज थी, जहां हमारे पास सख्त कोड समीक्षा नीति थी और टीम पर हर कोई उन्हें प्यार करता था। एक विशिष्ट क्षेत्र के विशेषज्ञ हमेशा एक कोड समीक्षा पर होते हैं जब कोई अन्य उस कोड को संशोधित करता है।
  • कोड समीक्षाओं के साथ हमारे पास ज्ञान साझा करने का एक टन है और आप हमारी टीमों की कोड गुणवत्ता में समग्र सुधार देख सकते हैं। इसके अलावा, क्योंकि कोड की इतनी बार समीक्षा की जाती है, जब लोग किसी और के विशेषज्ञता के क्षेत्र में जाते हैं, तो संभावना है कि वे कोड को कम से कम कुछ समय पहले ही देख चुके हैं।
  • प्रत्येक टीम के बड़े हिस्से को डिज़ाइन समीक्षा बैठकों में चूसा जाता है, इसलिए भले ही उन्होंने कोड कभी नहीं देखा हो, हर कोई सभी मॉड्यूल के सामान्य प्रवाह से परिचित है जो उनकी टीम के लिए जिम्मेदार है।
  • हमने लगभग 10 महीनों के लिए यह किया है और यह इस तरह का महसूस करता है जैसे हमने अलग-अलग मॉड्यूल दृष्टिकोण के साथ शुरू किया और हर किसी में काम करता है। लेकिन एक ही समय में, कोई भी ऐसा महसूस नहीं करता है कि वे तंग या सीमित हैं। और यह सुनिश्चित करने के लिए कि लोगों में अभी भी कुछ अधिकार की भावना है, हमने उन्हें क्षेत्र विशेषज्ञों के रूप में छोड़ दिया, भले ही यह अब एक औपचारिकता है।

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

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

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

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

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

Comments

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

— अमीर

Answer 2

टीम के साथ एक बैठक करें, उन्हें टू-डू सूची दिखाएं, और पूछें कि कौन क्या करना चाहता है।

Comments

एक और तरीका रखो, और इस जवाब को पूरी तरह से गूढ़-आज्ञाकारी बनाने के लिए, टीमों को स्वयं का आयोजन करना चाहिए ।

— ब्रायन ओकले

Answer 3

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

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

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

Comments

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

— DXM

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

— DXM

Answer 4

हालांकि मैं डेविड के जवाब से सहमत हूं, मुझे लगा कि यह कुछ विस्तृत से लाभ उठा सकता है:

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

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

Comments

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

— रॉबिन्स

Answer 5

सरलतम दृष्टिकोण अक्सर सबसे अच्छा होता है।

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

जब इस तरह की दुविधा का सामना करना पड़ा, तो मैंने निम्नलिखित दृष्टिकोण को नियोजित किया है:

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

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

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

• प्रत्येक डेवलपर को कार्य को लागू करने के लिए एक कार्य चुनने के लिए कहें - या आपके पुनरावृत्तियों को चलाने के आधार पर कार्यों का एक समूह प्राथमिकता कतार के शीर्ष से - जिस पर डेवलपर काम करना चाहेगा।

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

• अतिव्यापी पुनरावृत्तियों के साथ डेवलपर्स को चलाने से डरो मत, और तदनुसार अपनी रिलीज़ प्रबंधित करें। इससे कार्यों के पूरा होने की प्रतीक्षा के बीच व्यर्थ होने वाले समय को कम करने में मदद मिलेगी।

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

Answer 6

डॉ। फ्रेड ब्रुक्स की सर्जिकल टीम का उल्लेख किए बिना कोई भी डेवलपर टीम संगठनात्मक चर्चा पूरी नहीं होगी ।

मूल सूत्र है: कार्य की प्रति इकाई एक सर्जिकल टीम

एक सर्जिकल टीम को परिभाषित करना

सर्जिकल टीम की अवधारणा दो मौलिक विचारों पर आधारित है:

1. कम डेवलपर्स प्रति यूनिट काम के लिए बेहतर हैं क्योंकि क्रॉस-टॉक उत्पादकता को मारता है।
2. उच्च-आउटपुट डेवलपर्स कम-आउटपुट डेवलपर्स का प्रदर्शन करते हैं (और ब्रूक्स के अनुसार, मध्यम-उत्पादन डेवलपर के रूप में ऐसी कोई चीज नहीं है), इसलिए आपने उन्हें बेहतर काम करने के लिए सबसे बेहतर काम दिया था, और उनके विक्षेप को सीमित किया था।

एक सर्जिकल टीम 3-10 डेवलपर्स से युक्त होती है:

1. एक मुख्य प्रोग्रामर। एक उच्च-आउटपुट डेवलपर, जो अधिकांश वास्तविक प्रोग्रामिंग करता है।
2. एक सह-पायलट। एक और उच्च-आउटपुट डेवलपर, जो कुछ प्रोग्रामिंग करता है, लेकिन कुछ प्रशासनिक कार्य भी करता है, जैसे कि बैठक में भाग लेना और आवश्यकताओं को इकट्ठा करना।
3. 1 - 8 सहायक। ब्रूक्स इनका वर्णन दस्तावेज़ीकरण, कोड सफाई, शोध, लेखन उपकरण / एल्गोरिदम, परीक्षण, आदि जैसी चीजों के लिए करता है। 60 के दशक में ब्रूक्स ने ठीक 8 भूमिकाएँ प्रस्तावित की थीं, लेकिन आधुनिक उपकरणों के साथ आपको 1 या 2, और बहुत कम की आवश्यकता हो सकती है। संभवतः आपकी परियोजना की जरूरतों के आधार पर सौंपा जाना चाहिए।

कार्य की एक इकाई को परिभाषित करना

तो अब जब हम एक टीम को एक साथ रख सकते हैं, तो हम उन्हें क्या सौंपेंगे?

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

आपको तीन बुनियादी, स्वीकार्य पैटर्न सामने आने चाहिए:

1. प्रत्येक परत के लिए बिल्कुल 1 उप-टीम (UI, DAL, आदि)
2. प्रत्येक मॉड्यूल के लिए बिल्कुल 1 उप-टीम (होम पेज, सपोर्ट साइट, शॉप)
3. दो का मिश्रण (एक निम्न-स्तरीय फ्रेमवर्क टीम, और प्रत्येक मॉड्यूल के लिए एक यूआई-केंद्रित टीम)

Answer 7

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

बेशक यह हमेशा काम नहीं करता है ...

Answer 8

यहां है जो मुझे करना होगा:

यदि सभी मॉड्यूल छोटे हैं, तो आप प्रत्येक मॉड्यूल को काम करने के लिए दे सकते हैं। अन्यथा, ऐसा करें:

1. प्रत्येक मॉड्यूल आकार, जटिलता, इसे करने के लिए आवश्यक कौशल को परिभाषित करें।
2. प्रत्येक टीम के सदस्य कौशल को परिभाषित करें।
3. परिभाषित करें कि कौन से लोग एक साथ अच्छा काम करते हैं और कौन से लोग दूसरों के साथ अच्छा काम नहीं करते हैं।
4. मॉड्यूल कौशल आवश्यकताओं और टीम कौशल के आधार पर एक साथ काम करने वाले लोगों की टीमों के लिए बड़े मॉड्यूल असाइन करें।
5. ऐसे मॉड्यूल को शेष लोगों को सौंपें जो मॉड्यूल कौशल आवश्यकताओं और टीम कौशल के आधार पर अन्य लोगों के साथ अच्छी तरह से काम नहीं कर सकते।

उपरोक्त कार्य नहीं करेगा यदि वे लोग जो दूसरों के साथ काम करना पसंद नहीं करते हैं वे सबसे अधिक कुशल हैं और यह एक सामान्य मामला है, इसलिए तदनुसार 4 और 5 का अपवाद करें