टीम प्रभावशीलता का मूल्यांकन कैसे करें

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


सेंट टीमलीड पर एलेक्सी कटेव के व्याख्यान को देखें या पढ़ें कि क्या आपको पता नहीं है कि आपकी टीम भयानक है या नहीं, यह निर्धारित करने के लिए क्या औपचारिक मानदंड हैं। यदि आप "काफी थोड़ा", "कितना", "बहुत ज्यादा" श्रेणियों के साथ काम करने के बजाय घंटों में तकनीकी ऋण को मापने में सक्षम होना चाहते हैं। यदि आपके उत्पाद प्रबंधक का मानना ​​है कि एक महीने में तीन लोगों की टीम 60 कार्य करेगी - तो उसे यह लेख दिखाएं। यदि आपके प्रबंधक ने मैट्रिक्स के साथ विकास को लटका दिया है और सुझाव दिया है कि आप परिणामों के आधार पर उपाय करते हैं जैसे: "34% सोचते हैं कि टीम को योजना बनाने में समस्या है," यह रिपोर्ट आपके लिए है।



वक्ता के बारे में: अलेक्सेई कटावे ( देसदेउरुम ) 15 वर्षों से वेब विकास में लगे हुए हैं। एक बैकएंड, फ्रंटएंड, फुलस्टैक-डेवलपर और टीम लीड के रूप में काम करने का प्रबंधन किया। वर्तमान में स्काईेंग में विकास प्रक्रियाओं को सुव्यवस्थित करने में लगे हुए हैं। वितरित टीम के काम के बारे में बोलने में टीम के नेताओं से परिचित हो सकते हैं।

अब अंत में हम स्पीकर को फर्श पास करते हैं। आइए संदर्भ से शुरू करें और धीरे-धीरे मुख्य समस्या पर आगे बढ़ें।



मैं 2015 में स्काईेंग में शामिल हुआ था और पांच डेवलपर्स में से एक था - वे कंपनी में सभी डेवलपर्स थे।

तीन साल से थोड़ा अधिक समय बीत चुका है, और अब हमारे पास 15 टीमें हैं - ये 68 डेवलपर हैं ।



सभी डेवलपर्स दूर से काम करते हैं, वे दुनिया भर में बिखरे हुए हैं।

आइए उन समस्याओं को देखें जो 5 से 68 कर्मचारियों की कंपनी को स्केल करते समय अनिवार्य रूप से उत्पन्न होती हैं।

तस्वीर में, सर्गेई विकास प्रबंधक है।


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

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


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

आपको यह समझने की जरूरत है कि क्या टीम शांत है ।


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


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


अंत में - हम यह कैसे सुनिश्चित करें कि सभी टीम सैप्सन हैं और ट्रेनें नहीं हैं?

1. हम यह निर्धारित करते हैं कि हमारी टीमें कितनी शांत हैं।

बेशक, पहली बात जो दिमाग में आती है, वह है कुछ मेट्रिक्स को मापना! अब मैं आपको हमारे अनुभव के बारे में बताऊंगा और कैसे हम बार-बार गलत हुए।


सबसे पहले, हमने वेग की निगरानी करने की कोशिश की - हम स्प्रिंट के लिए कितने कार्य कर रहे हैं। लेकिन यह पता चला कि हमारी आधी टीमों में स्प्रिंट बिल्कुल नहीं हैं, उनके पास कानबन है। और जहां स्प्रिंट होते हैं, कार्यों को घंटों या कहानी बिंदुओं में रेट किया जाता है। अभी भी कुछ ऐसे दल हैं जो केवल कार्य करते हैं - उनके पास कानबन नहीं है, वे नहीं जानते कि स्क्रम क्या है।

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

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

हर तिमाही, हम देखते हैं कि टीम व्यावसायिक आवश्यकताओं को पूरा करती है या नहीं, कितने नियोजित कार्य पूरे हो चुके हैं।


घटनाओं की संख्या की गिनती भी विफल रही।

हम हर असफल रोलआउट या बग को लॉग करते हैं, जिससे कंपनी को नुकसान हुआ, और पोस्टमार्टम हुआ। सर्गेई एक टीम लीडर के रूप में मेरे पास आए और कहा: “आपकी टीम सबसे अधिक गिरावट को स्वीकार करती है। ऐसा क्यों? ” हमने सोचा, देखा और यह पता चला कि हमारी टीम सबसे अधिक जिम्मेदार है और केवल वही है जो सभी गिरावटों को लॉग करता है। बाकी के सिद्धांत पर काम जल्दी से उठाया, माना जाता है कि गिर नहीं गया।

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

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

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


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

सबसे पहले, यदि आप बंद प्रश्न पूछते हैं, तो इन आंकड़ों से कोई निष्कर्ष नहीं निकाला जा सकता है। उदाहरण के लिए, हम पूछते हैं: "क्या टीम को योजना बनाने में कोई समस्या है?" और 34% कहते हैं कि वहाँ है - और इसके बारे में क्या करना है? यदि आप ओपन-एंडेड प्रश्न बनाते हैं: "बुनियादी ढांचे के साथ टीम में क्या समस्याएं हैं?" - आपको खाली उत्तर मिलेंगे, क्योंकि हर कोई कुछ भी लिखने के लिए बहुत आलसी है। इन आंकड़ों से कोई निष्कर्ष नहीं निकाला जा सकता है ।

हमने इस विचार को विकसित किया - पहले हम स्क्रीनिंग के रूप में सर्वेक्षण करते हैं, और फिर यह समझने के लिए साक्षात्कार करते हैं कि वास्तव में समस्या क्या है। हम साक्षात्कार के बारे में थोड़ी देर बाद बात करेंगे।

मैंने तीन उदाहरण दिए, वास्तव में हमने दर्जनों मैट्रिक्स की कोशिश की ।

अब हम केवल उपयोग करते हैं:

• योजनाओं की पूर्ति।
• घटनाओं की संख्या।
• पोल + साक्षात्कार।

मैं धोखा दे रहा हूं अगर मैं कहता हूं कि हम इन सरल चीजों को सभी टीमों में मापते हैं, क्योंकि सबसे महंगी चीज कार्यान्वयन है । विशेष रूप से जब 15 अलग-अलग टीमें होती हैं, जब उत्पाद कहता है: “हाँ, हमें इसकी आवश्यकता नहीं है! हमें अपना काम पूरा करना होगा, अब इस पर निर्भर नहीं है! इसे बनाना बहुत मुश्किल है ताकि सभी टीमों में एक संख्या को मापा जा सके।

साक्षात्कार

चलो डेवलपर्स के साथ साक्षात्कार के बारे में एक संक्षिप्त विषयांतर करते हैं। मैंने कई लेख पढ़े, किराना कोर्स से गुजरा। उपयोगकर्ता अनुसंधान और ग्राहक विकास के बारे में बहुत कुछ है। मैंने वहां से कई अभ्यास किए, और वे डेवलपर्स के साथ संचार में बहुत अच्छी तरह से गिर गए।

यदि आपका लक्ष्य यह पता लगाना है कि टीम को क्या समस्याएँ हैं, तो सबसे पहले आपको लक्षित प्रश्न लिखने चाहिए जो आप उत्तर के लिए देखेंगे। यही है, आप केवल 30 प्रश्नों को नहीं फेंकते हैं, आप उन 2-3 प्रश्नों का चयन करते हैं जिन्हें आप उत्तर की तलाश में हैं। उदाहरण के लिए: क्या टीम के पास बुनियादी ढांचा समस्याएं हैं; कैसे व्यापार और टीम के बीच संचार स्थापित किया जाता है।

इस मामले में, प्रश्न निम्न होने चाहिए:

• खोलो । प्रश्न का उत्तर: "क्या कोई समस्या है?" - "हाँ!" "वह आपको कुछ भी नहीं बताएगा।"
• तटस्थ। एक समस्या के बारे में एक सवाल एक बुरा सवाल है। पूछने के लिए बेहतर है: "मुझे अपनी टीम में नियोजन प्रक्रिया के बारे में बताएं।" एक व्यक्ति प्रक्रिया के बारे में बात करता है, और आप पहले से ही उससे गहरे सवाल पूछना शुरू कर रहे हैं।

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

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

2. संसाधनों का मूल्यांकन

अब बात करते हैं संसाधनों के मूल्यांकन की ।

आइए उत्पाद के दृष्टिकोण से शुरू करें - क्योंकि वह आमतौर पर अपनी टीम के संसाधनों का मूल्यांकन करता है। 3 लोग हैं, एक महीने में 20 कार्य दिवस - हम लोगों को दिनों से गुणा करते हैं, हमें 60 कार्य मिलते हैं।



बेशक, मैं अतिशयोक्ति करता हूं, एक सामान्य उत्पाद इसे 60 दिनों के विकास के रूप में गुणा करेगा। लेकिन यह भी गलत है, कोई भी 60 दिनों में 60 दिनों के लिए किए गए कार्यों को पूरा नहीं करेगा। यहां तक ​​कि स्क्रम आपको फ़ोकस फैक्टर पर विचार करने और एक निश्चित जादू की संख्या से गुणा करने की सलाह देता है, उदाहरण के लिए, 0.2। वास्तव में, पुनरावृत्ति से पुनरावृत्ति तक हम 12, फिर 17, फिर 10 कार्य करेंगे। मुझे लगता है कि यह बहुत मोटा आकलन है।

संसाधनों के आकलन के लिए मेरा अपना दृष्टिकोण है। शुरू करने के लिए, हम काम के घंटों में टीम के कुल संसाधन पर विचार करते हैं। हम डेवलपर्स द्वारा घंटों को गुणा करते हैं, हम छुट्टियों और दिनों की छुट्टी लेते हैं। मान लीजिए कि आपको 750 मिलते हैं। लेकिन सबका साथ सबका विकास नहीं है।


उदाहरण के रूप में आदेशों में से एक का उपयोग करके ऊपर वास्तविक डेटा है:

• संचार पर बिताया गया समय का 36.9% हिस्सा बैठकों, चर्चाओं, तकनीकी समीक्षाओं, कोड समीक्षाओं आदि के बारे में है।
• 63.1% - समस्याओं को हल करने के लिए सीधे।

क्या उत्पाद इन 63.1% पर भरोसा कर सकता है? नहीं, यह नहीं हो सकता, क्योंकि उत्पाद कार्य केवल भाग हैं। बग्स को ठीक करने और फिर से तैयार करने के लिए अभी भी एक कोटा (लगभग 20%) है । यह वही है जो डरपोक वितरित करता है, और उत्पाद इस समय पर मायने नहीं रखता है।


उत्पाद कार्यों में से, सभी कार्य भी नहीं हैं, जो उत्पाद ने योजना बनाई है। अन्य टीमों के उत्पाद कार्य हैं जो रिलीज होने के कारण तत्काल मदद मांग रहे हैं। हम लगभग 8-10% कार्यों का अनुमान लगाते हैं जो अन्य टीमों से आते हैं ।


और अब हमारे पास 287 घंटे हैं! अगर हम हमेशा अपने ग्रेड में फिट होते हैं तो सब कुछ अच्छा होगा। लेकिन इस टीम में औसत ओवरपॉइंट की गिनती की गई - 1.51, अर्थात, औसतन, कार्य का अनुमान लगाने की तुलना में डेढ़ गुना अधिक समय लगा।


मुख्य कार्यों को पूरा करने के लिए कुल 750 घंटे 189 घंटे लगते हैं । बेशक, यह एक सन्निकटन है, लेकिन इस सूत्र में चर हैं जिन्हें बदला जा सकता है। उदाहरण के लिए, यदि आप एक महीने को रिफैक्टरिंग के लिए समर्पित करते हैं, तो आप इस मूल्य को प्रतिस्थापित कर सकते हैं और पता लगा सकते हैं कि आप क्या गिन सकते हैं।

मैंने पूरे दिन इसे समर्पित किया - मैंने कार्य लिया, एक्सेल में मैंने औसत समय की गणना की, इसका विश्लेषण किया - मैंने बहुत समय बिताया और फैसला किया कि मैं इसे फिर कभी नहीं करूंगा। मुझे इसके लिए कुछ त्वरित दृष्टिकोण की आवश्यकता है, ताकि हर बार अपने हाथों से ऐसा न करें।

मुझे जीरा और ईज़ीबीआई के लिए एक प्लगइन की सलाह दी गई थी। यह एक सुपर-जटिल उपकरण है, या मेरे पास पर्याप्त कौशल नहीं है, लेकिन बीच में मैंने हार मान ली।

मुझे किसी भी रिपोर्ट को जल्दी से बनाने का एक तरीका मिला।


अपने कार्य ट्रैकर से किसी भी डीबीएमएस जिसे आप जानते हैं (हमारे लिए PostgreSQL) को अपलोड करें, और फिर विश्लेषक को सब कुछ गणना करने के लिए कहें। हमारे पास यह दीमा है, और उसने 2 घंटे में सब कुछ गणना की।


उसी समय, उन्होंने अतिरिक्त डेटा का एक गुच्छा दिया - डेवलपर्स के लिए ओवरटाइम, प्रकार के कार्यों के लिए ओवरटाइम, कुछ गुणांक, हमें उनकी अंतर्दृष्टि और नए परिकल्पनाओं के बारे में बताया - मजेदार और स्केलेबल: आप इसे तुरंत सभी टीमों में उपयोग कर सकते हैं।

संसाधन कैसे बढ़ाएं

अब आप कैसे टीम को गति दे सकते हैं - डेवलपर्स की संख्या में वृद्धि किए बिना इसके संसाधन को बढ़ाएं।

सबसे पहले, किसी चीज़ में तेजी लाने के लिए, आपको पहले इसे मापना होगा। हम आमतौर पर दो मैट्रिक्स की गणना करते हैं:

1. घंटों में पुनरावृत्ति के लिए कार्यों का प्रारंभिक सारांश मूल्यांकन। उदाहरण के लिए, हमने एक सप्ताह में 100 घंटे के लिए कार्यों को पूरा किया।
   
2. और कभी-कभी औसत रोलिंग का समय उस समय से होता है जब कार्य विकास में आया था, इससे पहले कि यह उत्पादन पर हो। यह एक अधिक व्यवसायिक मीट्रिक है और उत्पाद के लिए दिलचस्प है, न कि डेवलपर।
   

मैं बॉट आर्सेनी के बारे में नहीं बताऊंगा, जिसे मैंने सप्ताहांत में लिखा था। हर हफ्ते वह एक पाचन पोस्ट करता है - हम कितने काम करते हैं।



यहाँ दो दिलचस्प बातें हैं:

1. मैं पर्यवेक्षक प्रभाव को क्या कहता हूं - कुछ संकेतक का मूल्यांकन करना, हम पहले से ही इसे बदल रहे हैं। जैसे ही हमने इस बॉट का उपयोग शुरू किया, हमने पुनरावृत्ति के दौरान हमारे द्वारा किए जाने वाले कार्यों की संख्या बढ़ा दी।
   
2. मीट्रिक प्रेरक होना चाहिए । मैंने यह दिखाना शुरू किया कि हमारे पास स्प्रिंट के लिए कितना समय नहीं है। यह पता चला कि हम समय में 10%, 20% तक नहीं थे। यह बिल्कुल भी प्रेरित नहीं करता है, कोई पर्यवेक्षक प्रभाव नहीं होगा।
   

स्पीड एक लैगिंग मीट्रिक है, हम इसे सीधे प्रभावित नहीं कर सकते। यह कुछ दिखाता है, लेकिन मैट्रिक्स हैं, जो प्रभावित करते हैं, हम गति को प्रभावित कर सकते हैं। मेरी राय में, दो मुख्य हैं:

1. मूल्यांकन कार्यों की सटीकता।
यहां हमें हमारे आरोपित विश्लेषक दीमा द्वारा फिर से मदद की गई, जिन्होंने प्रारंभिक मूल्यांकन के आधार पर कार्य के वास्तविक समय की गणना की।


यह वास्तविक डेटा है। ऊपर कार्य पूरा करने के लिए वास्तविक समय का एक ग्राफ है, और नीचे हमारा अनुमान है।

जोएल स्पोल्स्की का दावा है कि प्रति कार्य 16 घंटे की सीमा है। हमारे लिए यह स्पष्ट है कि 12 घंटे के बाद मूल्यांकन का कोई मतलब नहीं है, वहाँ विचरण बहुत अच्छा है। हमने वास्तव में सॉफ्ट-लिमिट की शुरुआत की और 12 घंटे से अधिक के कार्यों का मूल्यांकन नहीं करने का प्रयास किया। उसके बाद, या तो अपघटन या अतिरिक्त शोध।

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

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

3. तकनीकी ऋण से निपटना

जब मैं "तकनीकी कर्तव्य" कहता हूं, तो मैं इसे कुछ धुंधली के रूप में कल्पना करता हूं - यह स्पष्ट नहीं है कि इसे कैसे मापा जा सकता है?


अगर मैं आपको बताता हूं कि हमारी किसी टीम में 648 घंटे की तकनीकी ड्यूटी है, तो आप मुझ पर विश्वास नहीं करेंगे। लेकिन मैं आपको एल्गोरिथ्म बताऊंगा जिसके द्वारा हम इसे मापते हैं।


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

और यहां हमारे पास जीरा में 150 टिकट हैं - उनके साथ क्या करना है?



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

हमें इसकी आवश्यकता क्यों है? हम इस मूल्यांकन को एक तिमाही में एक बार आयोजित करते हैं। यदि हमारे पास पहली तिमाही में 700 घंटे थे, और फिर यह बन गया, उदाहरण के लिए, 800, तो सब कुछ क्रम में है। और अगर यह 1400 हो गया है, तो इसका मतलब है कि एक खतरा है और रिफैक्टरिंग के लिए कोटा बढ़ाने के लिए आवश्यक है - इस व्यवसाय से सहमत हैं कि अब हम पूरे महीने या पूरे समय का 40% रिफ्लेक्टर करेंगे।

ठीक है, हमने तकनीकी ऋण समस्या को हल कर दिया है, यह लॉक एंड की के तहत है।


लेकिन आइए उन कारणों के बारे में बात करते हैं जो इसकी घटना को जन्म देते हैं। यह सबसे अधिक बार खराब कोड की समीक्षा है।

खराब कोड की समीक्षा

खराब कोड समीक्षा के मुख्य कारणों में से एक बस-कारक है। हमने बस-कारक को औपचारिक रूप देना सीख लिया है । हम एक टीम लेते हैं, इस टीम के लिए प्रासंगिक क्षेत्रों की एक सूची लिखते हैं, उदाहरण के लिए, एक प्लेटफ़ॉर्म टीम के लिए यह है: वीडियो संचार, व्यायाम का सिंक्रनाइज़ेशन, उपकरण। प्रत्येक डेवलपर 1 से 3 की रेटिंग देता है:

• 1 - "मुझे समझ नहीं आया कि यह क्या है, मैंने एक दो बार सुना।"
• 2 - "मैं इस क्षेत्र से कार्य कर सकता हूं।"
• 3 - "मैं इस क्षेत्र में एक सुपर विशेषज्ञ हूँ।"

दिलचस्प बात यह है कि कुछ क्षेत्रों के लिए टीम में एक भी विशेषज्ञ नहीं था, किसी को नहीं पता था कि यह कैसे काम करता है।

हमने बस कारक के साथ समस्या को कैसे हल किया ?

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


अब कोड समीक्षा के बारे में जब पर्याप्त समय नहीं है। , review code review. pull requests, code review . , , - , review. - — , — , code review .

. — , .

4.

. , , cross review . -, : , , , . , . , .

, Google Suite : , , , .

— - .


-, . , , Continuous Integration ..

- — , . — , . , , , , , , . -.

:

• , , .
• - .
• , .
• .

, .

• QA- — 10 , .
• , - Skyeng - . — , , .
• open source, , .

Telegram (@ax8080) facebook , .

, Call for Papers TeamLead Conf 2019, 25–26 , . , , , .

! , .