मोनोलिथ से लेकर मॉड्यूलर टीमें

बड़ी कंपनियां अक्सर अनुकूलन क्षमता और गतिशीलता की समस्या से दुखी होती हैं। अधिक सटीक रूप से, दोनों की पूर्ण अनुपस्थिति से लगभग।

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



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

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

फ़ीचर औंस

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

लेकिन खुशी तब तक जारी रही जब तक कि OUNER की सुविधा उसके स्प्रिंट से ठीक पहले बीमार नहीं हो गई। और तुष्टीकरण का पूरा भ्रम भंग हो गया, और हम जहां से शुरू हुए थे, वहीं लौट आए।

सामान्य संवारना

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

चैट

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

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

फ़ीचर-टीम

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

यह दृष्टिकोण रिलीज के रिलीज के सामंजस्य और गति के अलावा कई बड़ी समस्याओं को हल करने वाला था:

स्वराज्य
एक टीम जो एक साथ बैठकों में जाती है, वह दूसरों से यथासंभव स्वतंत्र होती है। बाहरी निर्भरता से मुख्य लिंक उत्पाद है।

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

पूरी टीम समझती है कि "उत्पाद विकास" क्या है
विशेषताएं बनती हैं या व्यावसायिक आवश्यकताएं आती हैं, और डेवलपर को हमेशा यह समझ नहीं आता है कि क्यों, क्यों, और किसकी आवश्यकता है।

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

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

परिणामस्वरूप, हम निम्नलिखित लाभ प्राप्त करने में कामयाब रहे:

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

मुझे उम्मीद है कि यह उदाहरण आपको टीमों के बीच संचार समस्याओं को हल करने में मदद करता है। यदि आपके पास अन्य शांत विकल्प हैं, तो मैं प्रतिक्रिया की प्रतीक्षा कर रहा हूं)।

आपका धन्यवाद

और हमारे पास जल्द ही आईओएस डेवलपर्स के लिए एक म्यूटाप होगा।