आर्किटेक्ट्स स्वयं-आयोजन स्क्रम टीमों के साथ कैसे काम कर सकते हैं?


20

कई फुर्तीली टीमों के साथ एक संगठन में "उद्यम आर्किटेक्ट" के रूप में नियुक्त लोगों का एक छोटा समूह भी है। ईए समूह गुणवत्ता और निर्णयों के पालन के लिए नियंत्रण और द्वारपाल के रूप में कार्य करता है। यह टीम के निर्णय और ईए के निर्णयों के बीच ओवरलैप होता है।

उदाहरण के लिए, टीम लाइब्रेरी X का उपयोग करना चाहती है या SOAP के बजाय REST का उपयोग करना चाहती है, लेकिन EA इसे स्वीकार नहीं करता है।

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

स्क्रम गाइड इसके बारे में कहने के लिए यह है:

स्व-आयोजन: कोई भी (स्क्रम मास्टर भी नहीं) विकास टीम को बताता है कि कैसे उत्पाद बैकलॉग को संभावित भरोसेमंद कार्यक्षमता में वृद्धि में बदल दिया जाए।

क्या यह उचित है? क्या ईए टीम को भंग कर दिया जाना चाहिए? क्या टीमों को मना करना चाहिए या बस अनुपालन करना चाहिए?

जवाबों:


20

एक विकास दल क्रॉस-फ़ंक्शनल कौशल वाले 3-9 लोगों से बना है जो वास्तविक कार्य करते हैं

स्क्रैम मास्टर को "एंटरप्राइज आर्किटेक्ट" को प्रोजेक्ट टीम का हिस्सा बनने के लिए आमंत्रित करना चाहिए। फिर वास्तुकार और प्रोग्रामर के बीच संचार उत्कृष्ट होगा।


2
अच्छी बात; हालाँकि, मैं यह नहीं देखता कि यह कैसे काम कर सकता है अगर कई टीमें हैं जो आर्किटेक्ट के साथ काम करती हैं।
sleske

1
"अरे, ईए, अब आप यहां बैठते हैं और अभी भी एक ही लोगों के साथ संवाद कर रहे हैं। बस अधिक बार।" यह कैसे ईए और अन्य देवों के बीच किसी भी टकराव को हल करने में मदद करता है?
इज़्काता

@ स्लेसके, टीमों के बीच "एंटरप्राइज़ आर्किटेक्ट्स" समूह को विभाजित क्यों नहीं करते हैं? या अधिक वास्तुकारों को नियोजित करते हैं? समस्या यह है कि क्या कंपनी SCRUM और फुर्तीली टीमों, या sth तेज़ चाहता है। इजाका, दैनिक बैठकें टीम के संचार में बहुत बदलाव करती हैं, गंभीरता से, जब ईए को लगेगा कि वह डीटी का हिस्सा है और कुछ अलौकिक वास्तुकला गुच्छा नहीं है, तो समझौता करने का बेहतर मौका है।

1
@ariwez: "टीमों के बीच" एंटरप्राइज़ आर्किटेक्ट्स "समूह को विभाजित क्यों नहीं करते?" क्योंकि हमारे पास आर्किटेक्ट से ज्यादा टीमें हैं; आर्किटेक्ट भी ज्यादातर समस्याओं पर काम करते हैं जो कई टीमों को प्रभावित करते हैं।
sleske

@ स्लेस्क: "व्यक्तियों और प्रक्रियाओं और उपकरणों पर बातचीत"

17

उपयोग की जाने वाली प्रौद्योगिकी का विकल्प सॉफ़्टवेयर की आवश्यकताओं का हिस्सा है, जिसका अर्थ है कि यह उस सुविधा अनुरोध का हिस्सा है जिसका उपयोग आप कुछ तकनीकों का उपयोग नहीं करते हैं, जो भी कारण हो।

आर्किटेक्ट सिस्टम और कोडबेस के लिए बोलते हैं क्योंकि सिस्टम और कोडबेस खुद के लिए नहीं बोल सकते हैं। एक आर्किटेक्ट का होना आमतौर पर किसी कंपनी के दीर्घकालिक सर्वोत्तम हितों में होता है, विशेष रूप से एक जो सॉफ्टवेयर पर निर्भर करता है जो घर में बनाया जाता है।

आर्किटेक्ट डेवलपर्स को यह नहीं बता रहे हैं कि बैकलॉग को वेतन वृद्धि (स्प्रिंट) में कैसे बदलना है, वे कह रहे हैं कि कौन सी प्रौद्योगिकियां इस्तेमाल नहीं की जा सकती हैं और क्या नहीं। आप दो अलग-अलग मुद्दों का सामना कर रहे हैं।

समाधान कुछ भी नहीं बदलने के लिए है। यदि आपकी टीमें निराश हो रही हैं, क्योंकि आर्किटेक्ट बहुत अधिक प्रतिबंधात्मक या बहुत अधिक काम कर रहे हैं, तो यह एक कार्मिक समस्या है जिसका SCRUM से कोई लेना-देना नहीं है और व्यवसाय के हितधारकों के साथ कर्मचारी संतुष्टि के मुद्दे के रूप में लिया जाना चाहिए और, यदि संभव हो तो, नीचे की रेखा ("इसके लिए हमें x%सुविधाओं को विकसित करने में अधिक समय लगता है yक्योंकि आर्किटेक्ट zअभ्यस्त हमें टर्बो पास्कल का उपयोग करने देंगे।"


यह व्यक्तिगत संतुष्टि के बारे में नहीं है, यह उत्पाद की कीमत के बारे में उत्पादकता, गुणवत्ता और देखभाल के बारे में है। मुझे लगता है कि टीमों में देवता उस अंतर को बना सकते हैं।
मार्टिन विकमन

2
किसी ने, किसी समय यह निर्णय लिया कि वे नहीं कर सकते। इसलिए आर्किटेक्ट मौजूद हैं।
जोनाथन रिच

4
मैं वर्तमान में रेल-स्टैक सर्वर-साइड ऐप पर मेल रेल्स, जावा और .NET पर काम कर रहा हूं, जिन्हें वास्तव में बहुत जटिल होने की आवश्यकता नहीं थी। तो हाँ, द्वारपाल एक अच्छी बात हो सकती है, लेकिन तकनीकी निर्णय देवों के साथ आम सहमति और प्रबंधन को मंजूरी देने या चिंताओं को संप्रेषित करने के लिए उत्पन्न होने चाहिए, न कि गैर-देवों के मनमाने ढंग से तकनीकी निर्णय लेने या एक स्प्रिंट के बीच में साइड टीम के फैसलों को स्वाइप करने के लिए।
एरिक रेपेन

4
@ हार्इक और जब तीन अलग-अलग टीमें अपने तीन, अलग-अलग, सर्वसम्मति के निर्णयों पर पहुंचती हैं, तो आपको रेल, जावा और नेट का मिश्रण मिल सकता है।
MarkJ

@MarkJ यदि आपके पास एक ही सर्वर-साइड वेब ऐप के लिए अलगाव में काम करने वाली तीन अलग-अलग टीमें हैं, तो आपको वही मिलता है जो आपको मिलता है।
एरिक रिपेन

6

परियोजना को पूरा करने के लिए एक बड़ी टीम की जरूरत के बीच संतुलन बनाए रखने के लिए इस तरह की चीज जरूरी है, और फुर्तीली टीमों को छोटा रखने की जरूरत है।

आम तौर पर, 'टीम लीड स्क्रैम' प्रत्येक छोटी टीमों में से चुने गए एक सदस्य से बना होता है। यह स्व-आयोजन प्रकृति के साथ-साथ प्रतिनिधित्व के कुछ तरीके प्रदान करता है ताकि उच्च स्तरीय समूह द्वारा किए गए निर्णय चुस्त समूह द्वारा स्वीकार किए जाते हैं।

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

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


2
ज़रूर, लेकिन इसे घुमाकर: सभी टीमों को एक ही भद्दी तकनीक का उपयोग करने के लिए मजबूर करना भी नास्तिक है (सभी एक ही बदसूरत रास्ते से नीचे जाते हैं)। जबकि "विविधता" होने से कम से कम कुछ समाधान पैदा होते हैं जो कि पनपेगा।
मार्टिन विकमैन

2
@MartinWickman कभी-कभी भद्दी तकनीकों को चुनने के पीछे व्यावसायिक निर्णय होते हैं। यदि किसी विशेष बाजार में 80% डेवलपर्स के पास भद्दा तकनीक के साथ अनुभव है, तो यह उक्त तकनीक का उपयोग करने के लिए बहुत अधिक व्यापारिक समझ बना सकता है क्योंकि यह आपको आवश्यकता पड़ने पर ठेकेदारों को लाने की अनुमति देता है। एक छोटे बाजार में, आप किसी भी पायथन प्रोग्रामर को उनके नमक के लायक नहीं पा सकते हैं।
जोनाथन रिच

@JonathanRich जब मैं कहता हूं कि मैं भद्दा हूं तो मेरा मतलब है भद्दा। इसमें वह भी शामिल नहीं है जो इसे जानता है।
मार्टिन विकमैन

1
@MartinWickman - ज़रूर, मैं छोटी धारणा बना रहा हूं कि आपके नामित शीर्ष स्तरीय डेवलपर्स (या तो सौंपे गए, या स्व-संगठित) पूर्ण बेवकूफ नहीं हैं।
तेलस्टिन

1
@JonathanRich ने व्यावसायिक तर्क को दोष दिया, IMO। बड़ी मात्रा का मतलब गुणवत्ता का उच्च अनुपात नहीं है और यह कम से कम सक्षम होने पर काम पाने के लिए बहुत कम पायथन देवों को लेता है।
एरिक रेपेन

5

प्रश्न है: क्या कारण है कि यह आर्किटेक्ट टीम मौजूद है? केवल यही कारण है कि मैं सोच सकता हूं कि विभिन्न टीमों के बीच अंतर को लागू करना है। या टीमें एकल उत्पाद के विभिन्न हिस्सों पर काम कर रही हैं और यह आर्किटेक्ट टीम हर हिस्से को एक साथ रखने के लिए मौजूद है।

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

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


5

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

इस से संबंधित, डीन लेफिंगवेल की हाल की पुस्तक एजाइल सॉफ्टवेयर रिक्वायरमेंट्स पर इस विषय पर एक अच्छी पुस्तक है, मैं इसे स्वयं पढ़ रहा हूं।


4

हमारे पास कई, फुर्तीली टीमें (कुछ कानबन, कुछ स्क्रैम) और आर्किटेक्ट हैं। आर्किटेक्ट्स बुनियादी ढांचे के लिए जिम्मेदार हैं जो हमारे सभी उत्पादों (सहायक पुस्तकालयों, प्रमाणीकरण, आधारभूत संरचना का निर्माण) तक फैला हुआ है आदि वे तकनीकी निर्णय लेते हैं, लेकिन चीजों को भी लागू करते हैं, ज्यादातर बुनियादी ढांचे के घटक।

यह अच्छी तरह से काम करता है, और आमतौर पर कोई संघर्ष नहीं है। मेरा मानना ​​है कि एक महत्वपूर्ण बिंदु है:

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

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


2
@MartinWickman के साथ सहमत होना कि "सीमा" कई अर्थों में महत्वपूर्ण है: सबसे पहले, आर्किटेक्ट की राय को सॉफ्टवेयर सीमाओं में ध्यान देना चाहिए , जहां कई टीमों के घटक जुड़ते हैं; माध्यमिक, कि वास्तुकारों को अपने अधिकार की सीमा पता है , ताकि वे टीम के निर्णयों में कदम रखने से परहेज करेंगे, जब तक कि निर्णय अंतर पर प्रभाव नहीं डालते।
रोंगोंग

3

मुझे यहां कोई संघर्ष नहीं दिखता। मैं जो समझ रहा हूं, उससे सभी ईए (जैसा कि मुझे लगता है कि एक शीर्षक है) का अर्थ क्यूए है। जिसके बारे में हर किसी को जानकारी होनी चाहिए।

आपको इस बात पर विचार करना चाहिए, कि किसी भी विकास पद्धति में (जिसे एक माना जाता है) आवश्यकताओं को इकट्ठा करना एक महत्वपूर्ण कदम है, चाहे वह पुनरावृत्ति या अपफ्रंट हो।

इनमें से कुछ आवश्यकताएँ कंपनी की नीति द्वारा निर्धारित की जाती हैं। और ये जमीनी नियम निर्धारित करते हैं:

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

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


वे स्पष्ट रूप से क्यूए से अधिक कर रहे हैं। वे उपकरण के उपयोग के बारे में निर्णय ले रहे हैं।
एरिक रेपेन

@ ErikReppen: मैं थोड़ा अस्पष्ट था। मेरा मतलब था कि क्यूए वे क्या करने वाले हैं।
back2dos

@ back2dos: मुझे लगता है कि आपको मानकीकरण के लिए QA बदलने की आवश्यकता है। मुझे पता है कि आप क्या कह रहे हैं, लेकिन QA पूरी तरह से और आपकी बात को भ्रमित करने वाली एक अलग टीम है।
gbjbaanb

2

आपका आर्किटेक्ट आपकी फुर्तीली टीमों द्वारा किए गए निर्णयों पर हावी नहीं होना चाहिए। आपके आर्किटेक्ट को टीमों को दी गई आवश्यकताओं / कहानियों में शामिल करना चाहिए। जब परियोजना का परिदृश्य बदलता है और नई इंटरऑपरेबिलिटी आवश्यकताओं को पेश किया जाता है तो उन्हें टीमों को अद्यतन रखना चाहिए।

आदेश देने वाले आर्किटेक्ट और तकनीकी निर्णय लेना एक सांस्कृतिक दोष है। वे एक साझा लक्ष्य / दृष्टि को बनाए रखने और एक ही पृष्ठ पर अलग-अलग टीमों को रखने के बजाय खुद को "बॉस" के रूप में देखते हैं। चंचल कार्यप्रणाली संचार और संपर्क पर आधारित हैं। जब आपके आर्किटेक्ट निर्णय लेने के बाद तक शामिल नहीं होते हैं, तो वे चुस्त होते हैं।


"जब आपके आर्किटेक्ट निर्णय लेने के बाद तक शामिल नहीं होते हैं, तो वे चुस्त होते हैं।" - अगर हम इस कथन को उलटते हैं: "जब निर्णय लेते समय टीम आर्किटेक्ट्स को शामिल नहीं करती है, तो टीम चुस्त हो रही है।" यदि टीम द्वारा ऐसे निर्णय लिए जा रहे हैं जो कि प्रौद्योगिकी, मौजूदा पैटर्न आदि में बदलाव हैं ... तो टीम को एक वास्तुकार को शामिल करने की आवश्यकता है ताकि यह सुनिश्चित हो सके कि समग्र उत्पाद एकजुट रहे।
मेट्रो स्मरफ

2

मार्टिन, मुझे लगता है कि आपको इस बारे में गलत धारणा हो सकती है कि एक स्व-आयोजन टीम अपने वातावरण में कैसे कार्य करती है।

आपने स्क्रम गाइड का हवाला दिया: "कोई भी (स्क्रम मास्टर भी नहीं) विकास टीम को बताता है कि उत्पाद बैकलॉग को संभावित भरोसेमंद कार्यक्षमता में वृद्धि में कैसे बदल दिया जाए।"

यह स्क्रम टीम के लिए एक लाइसेंस नहीं है जो वह चाहता है (इसलिए जब तक वह उद्धार करता है) एक पूरे के रूप में कंपनी की प्रौद्योगिकी और व्यावसायिक जरूरतों और अन्य टीमों की जरूरतों के संबंध में।

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


0

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

कुछ भी नहीं की तरह मुझे लगता है कि वास्तव में उन लोगों के परिणामों का परिणाम भुगतना पड़ता है, जो वास्तविक लोगों से परामर्श किए बिना प्रौद्योगिकी निर्णय लेने के लिए वास्तव में पित्त होने की तरह गैर-देवों की तरह मुझे कुछ भी नहीं जारी रखता है।


यह उत्तर की तुलना में रैंट की तरह अधिक पढ़ता है।
ब्रायन ओकले

किसी को यह करना होगा।
एरिक रेपेन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.