विकास संस्कृति: प्रदर्शन और दक्षता का मूल्यांकन कैसे किया जाता है

( ग )

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

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

डेवलपर उत्पादकता को मापने और प्रबंधित करने के लिए एक भी अंतरराष्ट्रीय गुणवत्ता मानक नहीं हुआ है। हाई-टेक आईटी कंपनियां अपने स्वयं के मेट्रिक्स विकसित कर रही हैं ... उनमें से कुछ की गतिविधि के अन्य क्षेत्रों में पारंपरिक KPI के साथ तुलना करना लगभग असंभव है।

इस लेख में, हम सबसे दिलचस्प वर्तमान मैट्रिक्स के बारे में और आईटी में "मैट्रिक्स" के बारे में बात करेंगे।

काम किए गए घंटों की संख्या, स्रोत कोड में लाइनों की संख्या (एसएलओसी), फंक्शन पॉइंट या प्रत्येक डेवलपर द्वारा बनाई गई बग की संख्या के बारे में जानकारी प्राप्त करना पहले से ही मुश्किल है।

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

लेकिन सब कुछ मापने और गणना करने की इच्छा का क्या हुआ? जाहिर है, यह गायब नहीं हुआ है।

नेटफ्लिक्स

( ग )

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

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

नेटफ्लिक्स पर उत्पाद विकास एक परिकल्पना के साथ शुरू होता है जो कुछ इस तरह दिखता है:

एल्गोरिथम / फ़ंक्शन / डिज़ाइन (×) सेवा के साथ ग्राहकों की बातचीत को बढ़ाता है और अंततः, उनकी अवधारण।

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

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

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

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

आईबीएम

( ग )

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

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

फिर भी, बाद के प्रकाशन एक प्रतिमान बदलाव की धारणा देते हैं - परिकल्पना के निर्माण की कार्यप्रणाली पहले से ही विकास के केंद्र में उल्लिखित है। परिकल्पित विकास समय और संसाधनों की हानि के बिना नहीं कर सकता।



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

SpaceX

( ग )

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

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

कठोर अंतरिक्ष वातावरण के लिए उपकरण तैयार करने में शामिल टीमों के सामने आने वाली समस्याओं को देखते हुए, यह समझना मुश्किल नहीं है कि उनके साथ क्या जिम्मेदारी है।

स्पेसएक्स विभिन्न परियोजनाओं के बीच कोड को समानांतर बनाने की कोशिश कर रहा है - इस विकास प्रतिमान के साथ, एक परियोजना के लिए त्रुटि सुधार (अपेक्षाकृत बोल, रॉकेट) स्वचालित रूप से अन्य परियोजनाओं तक फैलता है।

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

दूसरे, वे बड़े C ++ पारिस्थितिकी तंत्र से लाभान्वित होते हैं। जब आप लंबे समय से परिचित उपकरण, जैसे gcc और gdb का उपयोग कर सकते हैं, तो विशेष सॉफ्टवेयर बनाने की कोई आवश्यकता नहीं है।

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

परीक्षण के दौरान एकत्र किए गए डेटा को उन स्रोत कोड के साथ संग्रहीत किया जाता है जो परीक्षणों के दौरान काम करते थे। यदि रॉकेट परीक्षण के दौरान कोई खराबी होती है, तो स्पेसएक्स सटीक प्रक्षेपण वातावरण को फिर से बनाने, समस्या को पुन: उत्पन्न करने और इसे ठीक करने में सक्षम होगा।

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

वीरांगना

40 मिनट के इस इंटरव्यू में उल्लिखित सबसे दिलचस्प रणनीतियों में से एक अमेज़न में AWS डेवलपर टूल्स के निदेशक के साथ है।

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

AWS डेवलपर टूल्स के सीईओ जेफ बेजोस का मानना ​​है कि एक आदर्श टीम में दो पिज्जा भरने से ज्यादा लोगों को शामिल नहीं करना चाहिए।

छोटी टीमों में, संचार अधिक प्रभावी होता है, वे विकेंद्रीकृत, स्वतंत्र रहते हैं, तेजी से विकास करते हैं और नवाचारों को पेश करते हैं।

अमेज़ॅन मूल रूप से एक अखंड और सॉफ्टवेयर आर्किटेक्चर था (पर्ल / मेसन / सी ++)। फिर वास्तुकला को सेवाओं में विघटित किया गया, और पिज्जा टीमों में संगठन संरचना। इसलिए क्लाउड सेवा Amazon Elastic Compute Cloud (Amazon EC2) एक समूह द्वारा बनाई गई थी जिसमें केवल दो "पिज़्ज़ा टीम" शामिल थे।

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

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

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

इसी समय, सामान्य अमेज़ॅन नियम हैं जो हर तैनाती को कवर करते हैं (उदाहरण के लिए, प्रत्येक क्षेत्र में एक बार की तैनाती पर प्रतिबंध)।

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

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

स्टार्टअप्स के पास क्या है

Stackify (वेब ​​अनुप्रयोगों की निगरानी और समस्या निवारण के लिए एक क्लाउड प्लेटफ़ॉर्म) द्वारा किए गए सर्वेक्षणों के लिए धन्यवाद, "मध्य हाथ" की कुछ प्रसिद्ध स्टार्ट-अप और कंपनियों में मेट्रिक्स के दृष्टिकोण का पता लगाना संभव था।

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

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

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

Adeva एक भर्ती कंपनी है और स्टार्टअप्स के लिए तैयार विकास टीमों का गठन करती है। ग्राहकों को बेहतर सेवा प्रदान करने के लिए, वह कई वर्षों से प्रोग्रामर प्रदर्शन मैट्रिक्स पर शोध कर रही है। निष्कर्ष सरल है: सॉफ्टवेयर विकास की प्रभावशीलता और उत्पादकता का कोई औपचारिक और उद्देश्य माप नहीं है।

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

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

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

यदि क्लाइंट संतुष्ट है और टीम समय सीमा को पूरा करती है तो एक प्रोजेक्ट सफल माना जाता है।

निष्कर्ष

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

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