✊🏻 😲 🍗 डेवलपर्स इतने धीमे क्यों हैं: आम समस्याएं और उनके समाधान 🚵🏻 😊 🎂

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

यदि आप पढ़ने से अधिक सुनना पसंद करते हैं, तो ऑडियो प्रारूप में, अनुवाद Yandex.Music और Apple पॉडकास्ट पर उपलब्ध है ।

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

अवास्तविक उम्मीदें
बहुत सारे खुले टिकट
कार्यों का अनियंत्रित दायरा
संचय कोड समीक्षा
खराब तैयारी
बर्नआउट डेवलपर्स
कीड़े
कर्मचारी आवाजाही

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

अवास्तविक उम्मीदें

डेवलपर्स की उत्पादकता के साथ ज्यादातर समस्याएं आमतौर पर विकास को प्रभावित नहीं करती हैं। यह प्रबंधकों और हितधारकों के रूप में विकास प्रक्रिया की हमारी धारणा की समस्या है।

प्रबंधक की नौकरी का सबसे कठिन हिस्सा यह समझ रहा है कि कोड लिखने में जितना समय लगता है और इस प्रक्रिया को तेज करने की कोशिश की जा रही है, यह केवल इसे धीमा कर देगा और कीड़े की संख्या में वृद्धि करेगा। धैर्य ही हमारा सब कुछ है।

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

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

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

जैसा कि द परफेक्ट कोड के लेखक स्टीव मैककोनेल लिखते हैं: “निष्कर्ष है कि पेशेवर डेवलपर्स (कर्टिस 1981, मिल्स 1983, डेमार्को और लिली 1985, कर्टिस एट अल 1986, कार्ड 1987) के कई अध्ययनों से विभिन्न प्रोग्रामर्स की उत्पादकता के बीच एक महत्वपूर्ण अंतर की पुष्टि हुई है। , बोहेम और पपीशियो 1988, वालेट और मैकगरी 1989, बोहेम एट अल। 2000)। हमारे पास यह अनुमान लगाने के लिए पर्याप्त डेटा नहीं है कि हमारी परियोजना को पूरा करने में कितना समय लगेगा। हम यह पता लगाएंगे कि पैमाने और जटिलता पहले से ही काम करना शुरू कर रहे हैं और यह प्रक्रिया अक्सर कई आश्चर्य से भरा है। "विकास केवल योजना नहीं है, बल्कि अनुसंधान भी है, चाहे हम कितनी भी सावधानी से सब कुछ करने की कोशिश करें।"

« 90 10 , . 10 90 »
— , Bell Labs

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

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

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

चीजों के दो उदाहरण जो मापने के लायक नहीं हैं:

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

इन दोनों चीजों को मापने से उत्पादकता, कर्मचारियों और अन्य लागतों के नुकसान के कारण अनगिनत कंपनियों को भारी नुकसान होता है।

कार्य प्रगति आरेख

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

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

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

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

एक अच्छा संकेतक एक वक्र है जिसमें उतार-चढ़ाव होता है, लेकिन कुल मिलाकर यह नीचे चला जाता है, जो परियोजना के अंत तक खुले कार्यों की संख्या में कमी दर्शाता है।

प्रोजेक्ट शेड्यूल जहां टिकटों की संख्या कम हो

प्रोजेक्ट शेड्यूल जहां टिकटों की संख्या कम हो

अतिवृद्धि क्षेत्र से पीड़ित एक परियोजना विपरीत रूप से झुकती वक्र द्वारा दर्शाई जाएगी।

नए कार्यों में डूबने वाली परियोजना की अनुसूची

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

लक्ष्य प्रक्रियाओं की पारदर्शिता है, न कि एक सुंदर नीचे की ओर।

गुडहार्ट सिद्धांत से सावधान रहें : "यदि एक आयाम एक लक्ष्य बन जाता है, तो यह उपयोगी साबित होता है।"

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

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

एक प्रोग्रामर द्वारा टिकट बंद कर दिया गया

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

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

कई साल पहले, मैंने एक वैश्विक खुदरा नेता के लिए खरीदारी की टोकरी पर काम किया था। एक बार मैंने जीरा में कोड लिखना और टिकट बंद करना बंद कर दिया और एक और टिकट जोड़ा: "प्रयोज्य अध्ययन"।

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

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

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

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

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

अगर आप सावधान नहीं हैं, फिर अपने सबसे उत्पादक डेवलपर्स के योगदान को देखें। किसी प्रोग्राम के लिए प्रोग्रामर क्या कर रहे हैं, यह पता लगाने का सबसे अच्छा तरीका है उनसे पूछना। टीम से पूछें कि उन्हें कौन लगता है कि उनका सबसे सहायक सहयोगी है।

आमतौर पर इस फीडबैक में जो जानकारी परिलक्षित होती है, वह उन आंकड़ों से बहुत अलग होती है, जिन्हें बस टिकटों की संख्या गिनकर प्राप्त किया जा सकता है।

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

बहुत सारे खुले कार्य

यह सरल प्रतीत होता है - ट्रैकर में एक टिकट खोलें और आगे बढ़ें। लेकिन ट्रैकर में प्रत्येक कार्य के लिए पूरे प्रसंस्करण चक्र की आवश्यकता होती है।

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

फिर डेवलपर को कार्य के संदर्भ में तल्लीन करने की आवश्यकता है, समस्या के सार को समझें, जटिल कार्यों को उप-प्रकारों में विघटित करें, और उसके बाद ही आप अंततः निष्पादित करना शुरू कर सकते हैं।

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

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

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

अनियंत्रित कार्य आकार

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

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

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

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

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

कोड समीक्षा द्वारा कार्यों का संचय

जब डेवलपर्स अधिक से अधिक काट सकते हैं तो वे निगल सकते हैं, परिणाम समीक्षा और सत्यापन के लिए एक बड़ा पुल अनुरोध है।

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

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

हम मानक परिदृश्य में ऐसे कार्यों की संख्या की गणना करते हैं:

बॉब और जेन एक ही शाखा में काम शुरू करते हैं (0 क्रियाएं)
बॉब परिवर्तन करता है और अपनी शाखा में आता है। जेन वही करता है (2 क्रियाएं)
बॉब का कोड मास्टर को जाता है। जेन बॉब के बदलावों को डाउनलोड करता है और एक संघर्ष को रोकता है। वह इसे सही करती है और परिणाम को उसके धागे तक पहुंचाती है। (3 क्रियाएँ)
जेन एक पुल अनुरोध खोलता है। बॉब ने नोट किया कि उसके कोड में उसके बदलाव से कुछ टूट जाएगा, जिसे उसने ध्यान नहीं दिया। जेन बॉब की टिप्पणियों के आधार पर बदलाव करता है और कोड को फिर से करता है (4 क्रियाएं)
पीआर जेन अंत में विलय। केवल ४ कर्म।

अब ऐसी स्थिति पर विचार करें जिसमें कमिट्स कम होंगे, और अनुरोधों को तेजी से झटका देगा:

बॉब एक छोटा सा बदलाव करता है और उसका कोड मास्टर में गिर जाता है (1 क्रिया)
जेन जादूगर के नए संस्करण को डाउनलोड करता है और बॉब के परिवर्तनों को ध्यान में रखते हुए अपना कोड लिखता है। (2 क्रियाएँ)
चूँकि जेन भी छोटा है इसलिए वह जल्दी से मास्टर के यहाँ आयोजित होता है। कुल केवल दो क्रियाएं।

जब हम छोटे पीआर बनाते हैं, तो हम कोड को फिर से करने की आवश्यकता को कम करते हैं, जो संघर्ष और कोड जटिलता के कारण होता है।

खराब तैयारी

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

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

टीमें धीरे-धीरे काम करती हैं क्योंकि उन्हें इस बात की बुरी समझ होती है कि वे क्या कर रही हैं और कोई भी उन्हें पढ़ाना नहीं चाहता है।

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

क्या किया जा सकता है:

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

खराब हुए

अपनी टीम को जलाने के लिए समय सीमा को पूरा करने में विफल रहने की तुलना में नेता के लिए एक बड़ा झटका है।

बर्नआउट एक गंभीर समस्या है जो डेवलपर्स, स्टाफ टर्नओवर, बड़ी लागत, बास कारक (बस कारक - व्यक्तिगत परियोजना के सदस्यों के बीच जानकारी की एकाग्रता का एक उपाय; नुकसान का मतलब हो सकता है; परियोजना प्रतिभागियों की संख्या, जिसके नुकसान के बाद परियोजना शेष प्रतिभागियों द्वारा पूरी नहीं की जा सकती); ।

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

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

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

डेवलपर्स को अधिक काम करने के लिए मजबूर करने के बजाय, प्रबंधकों को यह पहचानना चाहिए कि समय सीमा को पूरा करने की जिम्मेदारी प्रबंधन की नहीं बल्कि डेवलपर्स की है।

यदि आप निम्नलिखित तकनीकों का उपयोग करते हैं तो समय सीमा आसान है:

बेहतर कार्यों को प्राथमिकता दें और स्कोप कम करें
स्ट्रीमलाइन प्रक्रिया
कोड को पहचानना और रिफ्लेक्टर कोड भ्रम

कर्मचारी आवाजाही

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

कई कंपनियां विशेषज्ञों को बनाए रखने के लिए महत्व नहीं देती हैं। आइए कर्मचारियों के टर्नओवर की लागत पर एक नज़र डालें।

रिक्तियों के स्थान पर 15-30 हजार डॉलर खर्च होते हैं। इंजीनियर का समय औसतन $ 90 प्रति घंटे का होता है। नौसिखिया सवालों के जवाब देने और टीम के लिए आदी होने में उसकी मदद करने के लिए लगभग 50 साक्षात्कारों और कई, कई घंटे से गुणा करें। इस प्रकार, हम पहले ही 50 हजार डॉलर खर्च कर चुके हैं, लेकिन यह सब नहीं है।

एक नए कर्मचारी को डेवलपर के स्तर तक पहुंचने में एक वर्ष तक का समय लग सकता है, जिसे उसने बदल दिया, पहली बार वह बहुत सारी गलतियाँ करेगा और उन्हें ठीक करने में बहुत समय बिताएगा।

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

यह सब बहुत समय लेने वाली है और बड़ी टीमें लगातार चल रहे टर्नओवर से पीड़ित हैं, क्योंकि स्टैक ओवरफ्लो के 2019 के सर्वेक्षण के अनुसार, 60% डेवलपर्स ने पिछले दो वर्षों में नौकरियों को बदल दिया।

जब तक डेवलपर अंततः अधिकतम दक्षता के साथ काम करना शुरू नहीं करता, तब तक आप इसे खो देंगे।

तरलता से कैसे बचें? यहाँ विभिन्न स्रोतों से कुछ सुझाव दिए गए हैं:

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

कीड़े

यदि आपको लगता है कि आपके पास उच्च-गुणवत्ता वाली विकास प्रक्रिया को लागू करने का समय नहीं है, तो आप वास्तव में इसके बिना नहीं कर सकते।

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

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

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

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

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

जैसा कि पहले ही उल्लेख किया गया है, उत्पादन में एक बग आपको विकास के दौरान पाए जाने वाले बग से बहुत अधिक खर्च होगा।

निम्नलिखित युक्तियां प्रक्रिया की गुणवत्ता में सुधार करने में मदद करेंगी।

गति तेज करने के लिए धीमा। धीम का अर्थ है निर्बाध, निर्बाध का अर्थ है तेज।
एक डिजाइन समीक्षा का संचालन करें। कोड सत्यापन और आवश्यकताओं का संयोजन आपको 70% बग्स को पकड़ने की अनुमति देता है।
पोस्ट कोड की समीक्षा। अच्छी तरह से परीक्षण किए गए कोड को बनाए रखने के लिए 90% आसान है। एक घंटे की समीक्षा से आपको 33 घंटे का समर्थन प्राप्त होता है। प्रोग्रामर जो कोड समीक्षा करते हैं, वे 20% अधिक उत्पादक हैं।
TDD दृष्टिकोण का उपयोग करें। यह बगों की संख्या को 30-40 प्रतिशत कम कर देता है।
CI/CD. , , . , . CI/CD .
परीक्षण कवरेज बढ़ाएँ । आपकी CI / CD प्रक्रिया को परीक्षण चलाने चाहिए और यदि उनमें से कम से कम एक दुर्घटनाग्रस्त हो जाती है। यह उत्पादन में बग की तैनाती से बचने और आपको बहुत सारा पैसा और समय बचाने में मदद करेगा। आपका लक्ष्य कम से कम 70% कवरेज है, लेकिन 80% के करीब रहने की कोशिश करें। जैसे ही आप 100% तक पहुंचते हैं, आप देखेंगे कि कार्यात्मक परीक्षणों के साथ महत्वपूर्ण उपयोगकर्ता प्रक्रियाओं की कवरेज आपको इकाई परीक्षणों में और अधिक वृद्धि प्रदान करेगी।

निष्कर्ष

टीम के प्रदर्शन को प्रभावित करने के कई तरीके हैं, जिनमें शामिल हैं:

यथार्थवादी अपेक्षाएँ निर्धारित करें
ट्रैक करें और खुले कार्यों की संख्या को नियंत्रित करें
नियंत्रण कार्य आकार
कोड समीक्षा द्वारा कार्यों को संचित करने की अनुमति न दें
ट्रेन डेवलपर्स
काम और आराम के बीच एक अच्छा संतुलन प्रदान करें
प्रभावी विकास प्रक्रियाओं को लागू करें
कर्मचारी प्रतिधारण पर ध्यान दें

डेवलपर्स इतने धीमे क्यों हैं: आम समस्याएं और उनके समाधान