डेवलपर्स के अंतिम भोज

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

तीन साल से हमने बहुत सारी अच्छी सामग्री जमा की है। इसलिए, देवफोरम में भाषणों पर आधारित लेखों की एक श्रृंखला होगी :

1. बॉक्स के बिना श्रोडिंगर बिल्ली: वितरित प्रणालियों में आम सहमति की समस्या।
2. इंफ्रास्ट्रक्चर कोड के रूप में: पहला परिचित।
3. इन्फ्रास्ट्रक्चर कोड के रूप में: कैसे XP के साथ समस्याओं को दूर करने के लिए।
4. सर्वर एक-दूसरे से कैसे सहमत होते हैं: रेज़िस्टेंस कंसिस्टेंट एल्गोरिथम वितरित करता है।
5. घोड़ा मर चुका है - रोना: tslint से eslint में संक्रमण।
6. सी # मॉडल के लिए टाइपस्क्रिप्ट अनुबंध की पीढ़ी। (प्रगति पर है ...)
...

DevForum क्या है और यह किन समस्याओं का समाधान करता है?

देवफोरम डोडो आईएस डेवलपर्स के लिए हमारा साप्ताहिक आंतरिक कार्यक्रम है। यह गुरुवार को तीन साल से चल रहा है। डेवलपर्स एक साथ मिलते हैं और एक-दूसरे के साथ संवाद करने के लिए एक घंटा समर्पित करते हैं।



इस बैठक में, हम पूरी टीम के लिए प्रासंगिक तकनीकी मुद्दों पर चर्चा करते हैं। एक घंटे का समय, आधे घंटे की दो रिपोर्ट, सवाल और जवाब के लिए समय।

आंतरिक सम्मेलन किन समस्याओं का समाधान करता है?

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

यहाँ समस्याओं और उनके समाधानों की एक सूची दी गई है:

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

थोड़ा रेट्रो: कैसे DevForum के बारे में आया

यह प्रारूप कहां से आया? Korotenechko। तीन साल पहले, हमारी कंपनी ने नियमित आधार पर स्प्रिंट रिव्यू पेश करने का पहला प्रयास किया।

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

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

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


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

अपनी कंपनी में DevForum को कैसे व्यवस्थित करें

आपको 6 बुनियादी चीजों की आवश्यकता होगी:

1. देवफोरम के कार्यों और स्वरूपों को समझना।


2. शक्तिशाली और आवेशित आयोजक।


3. अपने आईटी विभाग के प्रबंधन से सहमति।


4. बैठकों के लिए स्थान और उपकरणों की उपलब्धता।
5. श्रोताओं की एक श्रोता की उपस्थिति।


6. चर्चा के लिए वक्ताओं और विषयों की उपस्थिति।

कुछ और महत्वपूर्ण

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

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

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

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



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

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

मानवता के साथ डोडो पिज्जा इंजीनियरिंग से