विकास स्टैक अप - तिरछे?


11

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

यहाँ छवि विवरण दर्ज करें

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

यहाँ छवि विवरण दर्ज करें

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

यहाँ छवि विवरण दर्ज करें

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

मुझे इस दृष्टिकोण के बारे में चिंता है:

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

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

यहाँ छवि विवरण दर्ज करें

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


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

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

@DocBrown मुझे विश्वास है कि टीम ए प्रभारी बनना चाहती है क्योंकि उन्हें लगता है कि पिछली टीम के बड़े प्रोजेक्ट के साथ असफल होने के बाद 'कई रसोइयों ने शोरबा खराब कर दिया है' - लेकिन मुझे वास्तव में कुछ पता नहीं है। टीमें लगभग 5 देव हैं, और यथोचित रूप से कुशल हैं।
इयान

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

1
@hstoerr: दिलचस्प बात यह है कि स्क्रैम गठबंधन का सुझाव है कि एक खपत घटक टीम (घटक टीम जो अन्य घटक टीमों के डिलिवरेबल्स का उपयोग या "उपभोग" करती है) निर्माता टीम के उत्पाद स्वामी के रूप में कार्य करती है। scrumalliance.org/community/articles/2012/seture/…
इयान

जवाबों:


12

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

यह एक अच्छा विचार हो सकता है अगर:

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

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

  • प्रबंधन टीम ए के एक अड़चन बनने के जोखिम को समझता है, और अगर यह जोखिम वास्तविक समस्या में बदल जाता है तो चीजों को डी-डायग्नलाइज़ करने के लिए तैयार होगा।

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

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


2
आपके दूसरे बिंदु पर, यह किसी भी कारण-आकार के व्यावसायिक अनुप्रयोग के लिए सही लगता है। अच्छी तरह से परिभाषित एपीआई के साथ पुस्तकालय तार्किक सीमा प्रतीत होते हैं, बशर्ते वे बहुत बड़े न हों।
रॉबर्ट हार्वे
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.