हम उद्देश्य डेटा के आधार पर विकास टीम में प्रक्रियाओं का मूल्यांकन करते हैं

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

सर्गेई सेमेनोव का मानना ​​है कि यह मुख्य रूप से दो कारणों से होता है।

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

और यह उद्देश्य डेटा के आधार पर प्रक्रियाओं के मूल्यांकन और नियंत्रण के लिए एक दृष्टिकोण प्रदान करता है।

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


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

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

डेटा स्रोत

अगर हम माप के बारे में बात कर रहे हैं, तो यह समझना अच्छा होगा कि डेटा कहाँ से प्राप्त करें। सबसे पहले, हमारे पास:

• कोड जानकारी के साथ गिट ;
• कार्यों के बारे में जानकारी के साथ जीरा या कोई अन्य कार्य ट्रैकर;
• GitHub , Bitbucket, Gitlab कोड समीक्षा जानकारी के साथ।

इसके अलावा, इस तरह के एक शांत तंत्र है जो विभिन्न व्यक्तिपरक आकलन एकत्र करता है। मैं एक आरक्षण करूँगा कि इसका उपयोग व्यवस्थित रूप से किया जाए यदि हम इस डेटा पर निर्भर रहना चाहते हैं।


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

पहला नियम जिसे हम डिजाइन करने और निर्माण करने की प्रक्रिया का पालन करने की सलाह देते हैं, ताकि वे डेटा में कलाकृतियों को छोड़ दें। आपको न केवल एजाइल का निर्माण करने की आवश्यकता है, बल्कि इसे मापने योग्य एजाइल बनाएं।

मैं आपको डरावनी कहानी बताऊंगा, जो हम उन ग्राहकों में से एक से मिले थे, जो उत्पाद की गुणवत्ता में सुधार करने के अनुरोध के साथ हमारे पास आए थे। आपको पैमाना समझने के लिए, उत्पादन से लगभग 30-40 कीड़ों ने एक सप्ताह में 15 डेवलपर्स की टीम के लिए उड़ान भरी। उन्होंने कारणों को समझना शुरू किया, और पाया कि 30% कार्य "परीक्षण" की स्थिति में नहीं थे। पहले, हमने सोचा कि यह सिर्फ एक डेटा त्रुटि थी, या परीक्षकों ने कार्य की स्थिति को अपडेट नहीं किया। लेकिन यह पता चला कि वास्तव में 30% कार्य केवल परीक्षण नहीं किए जाते हैं। एक बार बुनियादी ढांचे में कोई समस्या थी, जिसके कारण पुनरावृति में 1-2 कार्य परीक्षण में नहीं आए। फिर हर कोई इस समस्या के बारे में भूल गया, परीक्षकों ने इसके बारे में बात करना बंद कर दिया और समय के साथ यह 30% हो गया। परिणामस्वरूप, इसने अधिक वैश्विक समस्याओं को जन्म दिया।

इसलिए, किसी भी प्रक्रिया के लिए पहला महत्वपूर्ण मीट्रिक यह डेटा छोड़ देता है। इसका पालन अवश्य करें।


कभी-कभी, औसत दर्जे के लिए, आपको एजाइल के सिद्धांतों का हिस्सा बलिदान करना होगा और, उदाहरण के लिए, कहीं न कहीं मौखिक पर लिखित संचार को प्राथमिकता दें।

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

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

समस्या दृष्टिकोण

प्रक्रियाओं की माप में, हम निम्नलिखित दृष्टिकोण का अनुमान लगाते हैं: हमें समस्याओं से आगे बढ़ने की आवश्यकता है। हम कुछ आदर्श प्रथाओं और प्रक्रियाओं की कल्पना करते हैं, और फिर हम रचनात्मक हैं कि वे किन तरीकों से काम नहीं कर सकते हैं।

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

यह समझने के लिए कि आपको किन प्रक्रियाओं और प्रथाओं को लागू करने की आवश्यकता है, आपको यह समझने की आवश्यकता है कि विकास टीम में ऐसा क्यों करना है, व्यवसाय को विकास से क्या चाहिए। हर कोई समझता है कि इतना जरूरी नहीं है:

• यह उत्पाद पर्याप्त पूर्वानुमान अवधि के लिए दिया जाता है;
• उत्पाद उचित गुणवत्ता का था, जरूरी नहीं कि वह सही हो;
• ताकि यह सब काफी तेजी से हो।

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

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


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



अगला, हम सुविधाओं के जीवन के 4 चरणों पर विचार करते हैं:

• आयोजन
  
• डिज़ाइन
• कोड की समीक्षा
• परीक्षण

और हम विश्लेषण करेंगे कि इन चरणों में से प्रत्येक में अनुशासन, पूर्वानुमेयता और गुणवत्ता की क्या समस्याएं हो सकती हैं।

नियोजन स्तर पर अनुशासन के साथ समस्याएं

बहुत सारी जानकारी है, लेकिन मैं सबसे बुनियादी बिंदुओं पर ध्यान देता हूं। वे काफी सरल लग सकते हैं, लेकिन उनका सामना बड़ी संख्या में टीमों के साथ होता है।


पहली समस्या जो अक्सर नियोजन के दौरान उत्पन्न होती है, एक गंभीर संगठनात्मक समस्या है - हर कोई जो नियोजन बैठक में मौजूद होना चाहिए, वह नहीं है।

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

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

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

पहली अनुशासनात्मक समस्या यह है कि कार्यों का कोई विवरण नहीं है, या वे खराब रूप से वर्णित हैं। यह प्राथमिक रूप से नियंत्रित किया जाता है। एक प्रारूप है जिसके लिए कार्यों को अनुरूप होना चाहिए - हम जांचते हैं कि क्या यह ऐसा है। उदाहरण के लिए, हम मानते हैं कि स्वीकृति मानदंड निर्धारित हैं, या फ्रंट-एंड कार्यों के लिए लेआउट का एक लिंक है। आपको रखे गए घटकों पर भी नज़र रखने की आवश्यकता है, क्योंकि विवरण प्रारूप अक्सर घटक से जुड़ा होता है। बैकएंड टास्क के लिए, एक विवरण प्रासंगिक है; एक फ्रंटेंड टास्क के लिए, दूसरा।


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

हम इस तरह के वितरण में आने की कोशिश करते हैं: 20% उच्च प्राथमिकता वाले कार्य (आप मदद नहीं कर सकते हैं लेकिन अनलोड); 60% - मध्यम प्राथमिकता; 20% - कम प्राथमिकता (अगर हम इसे जारी नहीं करते हैं तो यह डरावना नहीं है)। हम इस सब पर सिग्नल लटकाते हैं।


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

नियोजन स्तर पर समस्या की भविष्यवाणी

हम भविष्यवाणी के साथ समस्याओं की ओर मुड़ते हैं।


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

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

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

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


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

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

योजना स्तर पर गुणवत्ता की समस्याएं

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

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


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


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

विकास के तहत अनुशासन के साथ समस्याएं

अब विकास की ओर बढ़ते हैं। अनुशासन के साथ क्या समस्याएं हैं?

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

• कमिट की आवृत्ति - दिन में कम से कम एक बार;
• जीरा में कम से कम एक सक्रिय कार्य।

यदि यह नहीं है, तो यह एक तथ्य नहीं है कि आपको डेवलपर के हाथों को हरा करने की आवश्यकता है, लेकिन आपको इसके बारे में जानने की आवश्यकता है।

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

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

प्रथाओं पर सहमत होने के लिए भी यही बात लागू होती है। विकास के स्तर पर, कई प्रथाएं हैं जिन्हें एक डेवलपर को पालन करना चाहिए। उदाहरण के लिए, नियत तिथि के मामले में, तीन संकेत होंगे:

• ऐसे कार्य जिनके लिए नियत तिथि निर्धारित नहीं है;
• कार्य जो नियत तारीख तक समाप्त हो चुके हैं;
• ऐसे कार्य जिनके लिए नियत तारीख बदली गई है लेकिन कोई टिप्पणी नहीं।

इन सभी के लिए सिग्नल ट्यून किए गए हैं। इसी तरह की चीजें किसी अन्य अभ्यास के लिए भी स्थापित की जा सकती हैं।

विकास के स्तर पर भविष्यवाणी की समस्याएं

विकास के स्तर पर पूर्वानुमानों में बहुत सी चीजें गलत हो सकती हैं।

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

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


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

एक अन्य उदाहरण, डेवलपर, इसके विपरीत, किसी प्रकार का बड़ा कार्य है जो कोड में बढ़ता और बढ़ता रहता है। यह भी पता लगाया जा सकता है और संभवतः विघटित हो सकता है ताकि अंत में कोड समीक्षा या परीक्षण चरण में कोई समस्या न हो।

, . , , . .

. , , .


. «» : , ; «»; «»; , bug fix. , , , , , — « ».

, , , , . , - , .

, , , , «» . , . , Legacy Refactoring , , , .

, — SLA high-priority- . , . , , : high-priority critical .

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

-

Code review. ? , , — pull requests. -, pull request, . , , «in review», , Jira. , . , 2-3 , .


, , , pull request, . — , pull request ticket Jira .


, , , . pull requests, . , , : «, , - ». , . pull requests , , Jira.

pull request, , — , , - , - , , . .

, , — , , , , . : , « , ». , .


, , linter. , , - linter, - - , .

-

, SLA , , . , , .

SLA , " - " — . , -. pull request .


, - , . , CTO , , , . -. - , 6 50% - . , , 50%, CTO . , CTO - , 100%.

, — , - . :

• , ;
• -;
• , .

, -.

-

, -. , . 100 . - 10 , - 1-2 . , . — , , . , , , .


, , , , .

— , - , . — churn -, .. pull request , .

, - , , , . , commit, , -.


, - ( pull request ), - . , commit, . , .

. , — Jira. Jira. , «testing». task-tracker. , , - .

SLA . SLA , .

-, , , — . . , , , .


pipeline test- — , , , . build' , , — , . , 1-2 , , . , .

— . , . , , «» , , , , , .


, , , . . , , , , . , , , . : , , , .


, «» , , . , , , .



, — - . , , . , , .

हमने मेट्रिक्स के बारे में बात की, और अब सवाल है - यह सब कैसे काम करना है? मैंने केवल सबसे बुनियादी चीजें बताईं, लेकिन उनमें से भी बहुत कुछ। यह सब क्या करना है और इसका उपयोग कैसे करना है?

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

यहाँ बिंदु बहुत सरल है: टीम बॉट से प्रबंधक की तुलना में संकेतों के लिए बहुत अधिक शांति से प्रतिक्रिया करती है, जो समस्याओं को इंगित करता है। यदि संभव हो तो, सबसे पहले सीधे डेवलपर को संकेत दें, फिर टीम को, यदि डेवलपर जवाब नहीं देता है, उदाहरण के लिए, एक से दो दिनों के भीतर।


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

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


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


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

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

निष्कर्ष

डेटा इकट्ठा करें। प्रक्रियाओं का निर्माण करें ताकि आपके पास डेटा एकत्र हो। यहां तक ​​कि अगर आप अभी मेट्रिक्स और सिग्नल का निर्माण नहीं करना चाहते हैं, तो आप भविष्य में एक शांत, पूर्वव्यापी विश्लेषण कर सकते हैं, अगर आप उन्हें इकट्ठा करना शुरू करते हैं।

प्रक्रियाओं को स्वचालित रूप से नियंत्रित करें। प्रक्रियाओं को डिजाइन करते समय, हमेशा इस बारे में सोचें कि आप उन्हें कैसे हैक कर सकते हैं, और आप डेटा से ऐसी हैक को कैसे पहचान सकते हैं।

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

आओ टीमलाइड कॉन्फ पर अपने टाइमलाइड को साझा करें। फरवरी सम्मेलन मास्को में आयोजित किया जाएगा और कॉल फॉर पेपर्स पहले से ही खुला है ।

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