यदि दो स्क्रैम टीमें एक ही सॉफ्टवेयर घटक का उपयोग करती हैं, तो उस घटक की स्पष्ट वास्तुकला दृष्टि प्रदान करने के लिए कौन ज़िम्मेदार है और कोड आधार विकसित होते ही इस दृष्टि को बनाए रखना / विकसित करना? स्क्रम में आपको एक सामूहिक कोड स्वामित्व माना जाता है, इसलिए यह सुनिश्चित करने के लिए कि टीम ए द्वारा किया गया विकास टीम बी द्वारा किए गए विकास में हस्तक्षेप नहीं करता है?
जवाबों:
मैं एक स्क्रैम विशेषज्ञ नहीं हूं, लेकिन AFAIK "सामूहिक कोड स्वामित्व" का अर्थ प्रति टीम और प्रति उत्पाद है (और मुझे लगता है कि आपका प्रश्न स्क्रैम के लिए विशिष्ट नहीं है, इसे किसी भी "साझा कोड" विकास प्रक्रिया पर लागू किया जा सकता है)।
यदि आपके पास दो टीम A, B, दो उत्पाद A, B और एक साझा घटक C हैं, तो अलग-अलग संभावित परिदृश्य हैं। हो सकता है कि साझा घटक मुख्य रूप से उत्पाद A के अंतर्गत आता है (और इसका पुन: उपयोग नहीं किया जाता है, लेकिन उत्पाद B के लिए टीम द्वारा विकसित नहीं किया जाता है)। इस स्थिति में टीम ए वास्तु दृष्टि के लिए स्पष्ट रूप से जिम्मेदार है। या इसके विपरीत: यह स्पष्ट रूप से उत्पाद बी से संबंधित है - इसलिए जिम्मेदारी है। यदि टीम ए ज़िम्मेदार है, तो टीम बी तत्काल बगफिक्स की अनुमति देने के लिए घटक के एक कांटे का उपयोग कर सकती है (सी की मुख्य लाइन में उन्हें फिर से स्थापित करने का एक तरीका भी होना चाहिए), लेकिन बी को घटक के किसी भी बड़े विकास को करने से बचना चाहिए।
हालांकि, यदि दोनों उत्पादों ए और बी में सी के लिए "ड्राइविंग आवश्यकताएं" बहुत हैं, तो आपको सी को पूरी तरह से अलग उत्पाद के रूप में प्रबंधित करना चाहिए, जिसमें स्वयं के संस्करण, रिलीज प्रबंधन, परिवर्तन प्रबंधन, इकाई परीक्षण आदि, और एक अलग टीम होती है। उस घटक की जिम्मेदारी। वह टीम सिर्फ एक "आभासी टीम" हो सकती है, जिसमें टीम ए, बी या दोनों के अलग-अलग देव शामिल हैं। इस टीम में सी के लिए "साझा कोड स्वामित्व" है, और "वास्तुशिल्प दृष्टि" के लिए जिम्मेदारी है। सी-थर्ड पार्टी वेंडर द्वारा दिए गए कंपोनेंट के बारे में सोचें।
स्क्रम या फुर्तीली में "स्पष्ट स्थापत्य दृष्टि" की कोई अवधारणा नहीं है!
मैं लंबे समय से एक वास्तुकार रहा हूं, और यह मेरे लिए स्पष्ट है कि वास्तु दृष्टि होने के लिए भविष्य की आवश्यकताओं के बारे में स्पष्ट दृष्टिकोण होना चाहिए। चूंकि अधिकांश मामलों में आवश्यकताएं बिल्कुल स्पष्ट नहीं होती हैं, इसलिए यह निश्चित दृष्टि रखने का कोई मतलब नहीं है।
यह आवश्यक है कि एक वास्तुकला का होना आवश्यक है जो बदलती आवश्यकताओं के अनुकूल हो। दूसरे शब्दों में, चीजें बदल जाती हैं, और वास्तुकला में परिवर्तन होता है - मैं "नरम" वास्तुकला की वकालत नहीं कर रहा हूं जिसे फिर से जोड़ा जा सकता है। मैं यह स्वीकार करने के बारे में बात कर रहा हूं कि आज जो वास्तुकला है वह जल्द ही अप्रचलित हो जाएगी और इसे बदलने की आवश्यकता होगी, इसलिए किसी को भी इससे "शादी" नहीं करनी चाहिए।
सामूहिक कोड स्वामित्व का मतलब है कि हर किसी को - सिद्धांत में - कुछ भी बदलने में सक्षम होना चाहिए। इसे "साइलो के विपरीत" के रूप में समझना होगा। दूसरे शब्दों में, जगह में कौशल बाधा हो सकती है, जो सामान्य और अपेक्षित है - हर कोई एक अनुभवी डीबीए नहीं है जो एसक्यूएल प्रश्नों को ठीक कर सकता है, एक उदाहरण देने के लिए - लेकिन इसमें से केवल डीबीए का पालन नहीं किया जा सकता है। हाथ प्रश्नों का अनुकूलन करें। एक "फीचर डोमेन विशेषज्ञ" होगा जो अन्य लोगों को कुशल बनने में मदद कर सकता है, लेकिन कार्यों को अभी भी सभी पर गिरना चाहिए।
उदाहरण के लिए: यदि मैं फीचर "ए" पर डोमेन विशेषज्ञ हूं, तो मैं अभी भी किसी और से "ए" फीचर पर काम करने की उम्मीद करता हूं, लेकिन जब कोई बड़ा बदलाव होना चाहिए या लोगों की मदद की जरूरत हो तो मुझे सलाह दी जाएगी। फ़ीचर "ए" निश्चित रूप से मेरी सुविधा नहीं होगी । यह एक ऐसा फीचर होगा जिसे मैं अच्छी तरह से जानता हूं। कई और विशेषताओं को जानना मेरा हित होगा, और इस सुविधा को जानने के लिए अन्य लोगों की रुचि।
संश्लेषण में: डिज़ाइनरों को डेवलपर्स द्वारा कई बार डिज़ाइन किया गया और पुन: डिज़ाइन किया गया है क्योंकि आवश्यकताएं उभरती हैं और बदलती हैं। हर किसी से अपेक्षा की जाती है कि वे अपने कौशल के अनुसार कोई भी आवश्यक बदलाव करें, और यह जानें कि मदद के लिए कब पूछा जाए। वास्तुकला पर कोई दीर्घकालिक दृष्टि नहीं है क्योंकि हम लोगों पर भरोसा करते हैं और हम आवश्यकताओं पर भरोसा नहीं करते हैं ।
उदाहरण के लिए, इस समस्या को हल करने के लिए "सिस्टम ओनर" नामक एक भूमिका का उपयोग करें, दस्तावेज़ से सीधे:
तकनीकी रूप से, किसी को भी किसी भी प्रणाली को संपादित करने की अनुमति है। चूंकि स्क्वाड प्रभावी रूप से टीम हैं, इसलिए उन्हें उत्पादन में एक नई सुविधा प्राप्त करने के लिए आमतौर पर कई प्रणालियों को अपडेट करने की आवश्यकता होती है। इस मॉडल के साथ जोखिम यह है कि एक प्रणाली की वास्तुकला गड़बड़ हो जाती है अगर कोई भी समग्र रूप से सिस्टम की अखंडता पर ध्यान केंद्रित नहीं करता है।
इस जोखिम को कम करने के लिए, हमारे पास "सिस्टम ओनर" नामक एक भूमिका है। सभी प्रणालियों में एक सिस्टम ओनर, या सिस्टम ओनर्स की एक जोड़ी होती है (हम पेयरिंग को प्रोत्साहित करते हैं)। परिचालन रूप से महत्वपूर्ण प्रणालियों के लिए, सिस्टम ओनर एक देव-ऑप्स जोड़ी है - अर्थात, एक डेवलपर परिप्रेक्ष्य वाला व्यक्ति और संचालन दृष्टिकोण वाला एक व्यक्ति।
सिस्टम का मालिक उस सिस्टम से संबंधित किसी भी तकनीकी या वास्तु संबंधी मुद्दों के लिए "व्यक्ति" पर जाएं। वह एक समन्वयक है और उस प्रणाली में कोड रखने वाले लोगों को यह सुनिश्चित करने के लिए निर्देशित करता है कि वे एक-दूसरे पर ठोकर न खाएं। वह गुणवत्ता, प्रलेखन, तकनीकी ऋण, स्थिरता, मापनीयता, और रिलीज प्रक्रिया जैसी चीजों पर ध्यान केंद्रित करता है।
सिस्टम मालिक एक अड़चन या हाथी दांत टॉवर वास्तुकार नहीं है। उसे व्यक्तिगत रूप से सभी निर्णय लेने या सभी कोड लिखने या सभी रिलीज़ करने की आवश्यकता नहीं है। वह आम तौर पर एक स्क्वाड मेंबर या चैप्टर लीड होता है, जिसके पास सिस्टम के स्वामित्व के अलावा अन्य दिन-प्रतिदिन की जिम्मेदारियां होती हैं। हालांकि, समय-समय पर वह "सिस्टम ओनर डे" लेगा और उस सिस्टम पर हाउसकीपिंग का काम करेगा। आम तौर पर हम इस प्रणाली को किसी व्यक्ति के समय के दसवें से कम के स्वामित्व में रखने की कोशिश करते हैं, लेकिन यह निश्चित रूप से प्रणालियों के बीच बहुत भिन्न होता है।
मैं वास्तव में इस विचार को पसंद करता हूं, कंपनी स्तर पर (न केवल टीम स्तर पर) लाभ या सामूहिक कोड स्वामित्व है, बल्कि इस प्रणाली के मालिकों के साथ कुछ वास्तु अखंडता सुनिश्चित करने की कोशिश कर रहा है।
पूर्ण दस्तावेज़ के लिए एक लिंक: https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf , चुस्त फुर्तीली के बारे में वास्तविक अनुभव में आधारित एक छोटा लेकिन बहुत ही दिलचस्प दस्तावेज़।
इसे हल करना एक कठिन समस्या है, और यह निश्चित रूप से स्क्रैम द्वारा हल नहीं किया गया है, जो एक परियोजना प्रबंधन पद्धति है, न कि एक विकास पद्धति।
सबसे प्रभावी उपाय जो मैंने पाया है वह है अच्छे पैकेज प्रबंधन (नगेट / रत्न / आदि) और संस्करण। जब तक वे इसका उपभोग करने के लिए तैयार नहीं होते तब तक किसी अन्य टीम में बदलाव को लागू न करें। जब आप नए पर जाते हैं, तो उन्हें पुराने बिल्ड का उपयोग करते रहने दें।
सुनिश्चित करें कि आपके पास एक संस्करण रणनीति है जो यह स्पष्ट करती है कि कौन से परिवर्तन टूट रहे हैं और कौन से एक्सटेंशन हैं।
इसके अलावा, जब आप एक बदलाव करते हैं, तो किसी पर एक कोड समीक्षा को धक्का दें। उन्हें यह देखने दें कि इससे प्रभावित होने की संभावना कैसे है, इससे पहले कि वे इसका उपभोग करने के लिए मजबूर हो जाएं ताकि वे शीर्ष पर अपने स्वयं के परिवर्तनों को लागू कर सकें।
और, जब चीजें वास्तव में गड़बड़ हो जाती हैं; जब एक टीम को एक बदलाव करने की आवश्यकता होती है और आसानी से एक और बदलाव का उपभोग नहीं कर सकता है (यह वास्तव में एक दुर्लभ मामला हो सकता है), कोड को शाखा दें, इसे पूरी तरह से अलग पैकेज बनाएं, लेकिन जैसे ही यह आम कोड पर वापस आना प्राथमिकता है। अनुमति देता है।
इसका उत्तर हमेशा उतना स्पष्ट नहीं होता जितना यह हो सकता है कि टीमों को यह तय करने देना है कि वे किसी दिए गए घटक को कैसे साझा करने जा रहे हैं।
उदाहरण के लिए, मेरी टीम ने हाल ही में एक नई उत्पाद लाइन विकसित करना शुरू किया है जो दो अन्य टीमों के साथ आम तौर पर बहुत सारे कोड साझा करती है जो लंबे समय से समान उत्पाद विकसित कर रहे हैं। हमारा उत्पाद कुछ तरीकों से अलग है, इसलिए हमें कभी-कभी कॉमन कोड में कस्टमाइज़ेशन पॉइंट्स जोड़ने के तरीकों का पता लगाना पड़ता है।
हमने उस कोड के बारे में कुछ झड़पें की हैं, और आम स्वामित्व से निपटने के कुछ अलग तदर्थ तरीकों की कोशिश की है। फिर एक बड़ी नई विशेषता सामने आने के बाद, हमने तय किया कि हमें एक ही पेज पर आने के लिए सभी टीमों को एक साथ लाने की आवश्यकता है, जिसके परिणामस्वरूप प्रत्येक टीम से एक छोटा सदस्य बना है, जो विवरण तैयार कर रहे हैं।
हमारी टीम ने जिस समाधान के साथ काम किया वह शायद दूसरी स्थिति में काम न करे। आपको कुछ अधिक सरल, या कुछ अधिक औपचारिक की आवश्यकता हो सकती है। मुद्दा यह है, आप सामूहिक स्वामित्व लेते हैं और यह पता लगाते हैं कि आपके लिए क्या काम करता है।
मैं मानने के लिए स्वतंत्रता लूंगा:
यदि उपरोक्त धारणाएं सही हैं, तो कभी-कभी ऐसा समय आ सकता है जब दो टीमें एक-दूसरे के साथ हस्तक्षेप करेंगी। वे निम्नलिखित तरीकों से इसका समाधान कर सकते हैं: