मैं एक सॉफ्टवेयर विकास टीम के प्रदर्शन को मापने के कुछ तरीकों की देखभाल कर रहा हूं। क्या बिल्ड टूल का उपयोग करना अच्छा विचार है? हम एक स्वचालित निर्माण उपकरण के रूप में हडसन का उपयोग करते हैं। मुझे आश्चर्य है कि क्या मैं हडसन की रिपोर्ट से जानकारी ले सकता हूं और इसे प्रत्येक प्रोग्रामर की प्रगति से प्राप्त कर सकता हूं।सॉफ्टवेयर विकास प्रदर्शन को मापने के लिए कैसे?
बस निर्माण उपकरण का उपयोग कर प्रत्येक व्यक्ति प्रोग्रामर के प्रदर्शन को मापने न करें। आप पूरी तरह से टीम को माप सकते हैं, या आप निश्चित रूप से प्रत्येक प्रोग्रामर की प्रगति को माप सकते हैं, लेकिन आप इस तरह के टूल के साथ अपने प्रदर्शन को माप नहीं सकते हैं। कुछ मॉड्यूल दूसरों की तुलना में अधिक जटिल होते हैं, कुछ प्रोग्रामर अन्य परियोजनाओं के साथ काम करते हैं, आदि। यह करने का एक अनुशंसित तरीका नहीं है, और यह प्रोग्रामर को स्लॉपी कोड लिखने के लिए प्रोत्साहित करेगा ताकि ऐसा लगता है कि उन्होंने सबसे अधिक काम किया है।
यह एक सच्ची कहानी है। – Njax3SmmM2x2a0Zf7Hpd
मैं एक तरह से सॉफ्टवेयर डेवलपर्स के प्रदर्शन/प्रगति को मापने के रूप में निर्माण उपकरण जानकारी का उपयोग करने की सलाह देते हैं नहीं होगा। कुछ उलझन में समस्याएं: संभवतः एक कार्य दूसरे की तुलना में काफी कठिन है; संभावित रूप से एक कार्य "कार्यान्वयन स्थान" की तुलना में "डिजाइन स्थान" में अधिक शामिल है; संभवतः (संभवतः) अधिक कुशल समाधान बेहतर समाधान है, लेकिन यह बेहतर समाधान कोड की कम लाइनों को एक बहुत ही अक्षम अक्षमता से योगदान देता है जो कोड की कई और रेखाएं प्रदान करता है; आदि
जांचें कि प्रत्येक कोड ने कितनी पंक्तियां लिखी हैं।
तो हर दिन नीचे 70% आग .. सं 90%! ...!
(लोगों कि निश्चित नहीं हैं, के लिए, हाँ, मैं मजाक कर रहा हूँ। गंभीर जवाब here)
मैं यह नहीं बता सकता कि आप मजाक कर रहे हैं या नहीं, लेकिन क्योंकि लोगों की नौकरियां खतरे में पड़ सकती हैं क्योंकि कुछ प्रबंधक को आपके उत्तर के कारण गलत विचार मिलता है, मैं इसे नीचे वोट दे रहा हूं। –
आपके पास मौका मिलने पर उस पीयर प्रेशर बैज को लें! 8-) – RichieHindle
एलओएल, हास्यास्पद आदमी, हास्यास्पद। –
सं
मेट्रिक्स उस तरह विफलता के लिए बर्बाद कर रहे हैं। विभिन्न लोग कोड के विभिन्न हिस्सों पर समस्या के विभिन्न वर्गों पर काम करते हैं, और पूर्ण माप सर्वोत्तम रूप से भ्रामक हैं।
रास्ता डेवलपर प्रदर्शन को मापने के उत्कृष्ट प्रबंधकों है कि अपना काम अच्छी तरह से करते हैं, अच्छा चश्मा है कि सही ढंग से आवश्यकताओं को प्रदर्शित होता है, और उन चश्मा के खिलाफ ध्यान से सभी की प्रगति को ट्रैक करने के लिए है।
सही करना मुश्किल है। एक सॉफ्टवेयर समाधान काम नहीं करेगा।
सहमत हुए, लड़का लिखता है कि कम से कम कोड वास्तव में सबसे अधिक काम कर सकता है। –
यह भी सहमत है - मैंने कभी भी सबसे अधिक उत्पादक चीजों में से एक कोड कोड की सैकड़ों लाइनों को हटाना था – jalanb
ऐसा करने के कई अलग-अलग तरीके हैं। विषय पर लिखी गई पूरी किताबें। आप हडसन से रिपोर्ट का उपयोग कर सकते हैं, लेकिन मुझे लगता है कि गलत जानकारी होगी और कच्चे नतीजे मिलेगा। वास्तव में आपको कार्य ट्रैकिंग पद्धति की आवश्यकता है।
आप शायद बेहतर कार्यक्रम को कितनी अच्छी तरह अपनी टीम पटरियों को मापने करते हैं। यदि कोई टीम सदस्य (या पूरी टीम) लगातार देर हो चुकी है, तो आपको प्रदर्शन में सुधार के लिए उनके साथ काम करने की आवश्यकता होगी।
शॉर्ट कटौती करो या तत्काल आसान तरीके से डेवलपर्स के प्रदर्शन/प्रगति को मापने के लिए देखो। डेवलपर के आउटपुट को प्रभावित करने वाले कई कारक हैं। मैंने देखा है लोगों की बहुत विभिन्न मैट्रिक्स की कोशिश ...
उत्पादित कोड की रेखाएँ - अक्षम कचरा जटिलता उपायों बाहर मंथन करने के लिए प्रोत्साहित करता - विश्लेषण पर प्रोत्साहित करती है और उत्पादित कीड़े की संख्या पुनर्रचना - वास्तव में बाहर की तलाश करने के लिए के लिए प्रोत्साहित करती सरल कार्य और अपने परीक्षकों से नफरत ... सूची जारी है।
किसी डेवलपर की समीक्षा करते समय आपको वास्तव में यह देखने की ज़रूरत है कि उनके काम कितने अच्छे हैं और कॉमनी की ज़रूरतों के संदर्भ में "अच्छा" परिभाषित किया गया है और कंपनी ने किस स्थिति/स्थिति को अविश्वसनीय रूप से रखा है। प्रगति का मूल्यांकन किया जाना चाहिए समान विचार और विचार।
आम तौर पर, सीधे प्रदर्शन माप के लिए मीट्रिक का उपयोग करना एक बुरा विचार माना जाता है, और एक टीम को जमीन में चलाने के आसान तरीकों में से एक माना जाता है।
अब, आप मेट्रिक्स का उपयोग समय-समय पर पूर्ण परियोजनाओं की तरह कर सकते हैं, मंथन का% कोड पूरा होने की ओर जाता है, आदि ... यह एक विस्तृत क्षेत्र है। मिशन के लिए महत्वपूर्ण बग के
60% जो द्वारा लिखे गए थे:
यहाँ एक उदाहरण है। यह एक सरल, सीधा मीट्रिक है। फायर जो, है ना?
लेकिन प्रतीक्षा करें, और भी कुछ है!
जो वरिष्ठ डेवलपर है। वह अकेला आदमी है, हर बार अल्ट्रा-विश्वसनीय कोड लिखने पर भरोसा करता है। उन्होंने लगभग 80% मिशन-महत्वपूर्ण सॉफ्टवेयर लिखा है, क्योंकि वह सर्वोत्तम है।
मेट्रिक्स डेवलपर्स का खराब माप है।
इस तरह के प्रदर्शन मीट्रिक के साथ मुख्य समस्या यह है कि मनुष्य किसी भी प्रणाली को गेमिंग में बहुत अच्छे हैं जो सटीक प्रदर्शन मीट्रिक को अधिकतम करने के लिए अपने स्वयं के प्रदर्शन को मापता है - आम तौर पर मूल्यवान चीज़ों की कीमत पर।
आइए कहें कि हम प्रोग्रामर आउटपुट पर आंकड़े इकट्ठा करने के लिए हडसन बिल्ड का उपयोग करते हैं। आप क्या देख सकते हैं, और यह समझने के अनपेक्षित दुष्प्रभाव क्या होंगे कि एक बार प्रोग्रामर इस पर चिपके रहते हैं?
और यह चलता रहता है।
बिंदु कोई फर्क नहीं पड़ता, क्या आप मापते हैं, इंसान (न सिर्फ प्रोग्रामर) बिल्कुल उस चीज़ को पूरा करने के लिए अनुकूलित करने में बहुत अच्छे होते हैं।
तो आपको अपने डेवलपर्स के प्रदर्शन को कैसे देखना चाहिए? अच्छा, यह मुश्किल है। और इसमें मानव प्रबंधकों को शामिल किया जाता है, जो लोगों को समझने में अच्छे होते हैं (और बीएस वे खींचते हैं), और प्रत्येक व्यक्ति को व्यक्तिपरक पर संदर्भित कर सकते हैं, जहां वे एक अच्छी नौकरी कर रहे हैं या नहीं या नहीं।
एक बार जब आप यह पता लगाएंगे कि कौन/प्रदर्शन नहीं कर रहा है, तो आप एक अलग सवाल पूछ सकते हैं।
(मैं सोच की इस पंक्ति के लिए ऋण नहीं ले सकते। यह योएल Spolsky। Here और here मूल रूप से है)
+1 और जोएल के लिए +1। 8-) – RichieHindle
+1 महान उत्तर के लिए। हालांकि मैंने और भी खराब जोड़ों को देखा है - उदाहरण के लिए मैंने लोगों को * बग/समस्याएं बनाई हैं जब उन्हें निश्चित संख्या पर प्रोत्साहन दिया जाता है। Aaargh !! ..... – mikera
हम टीम के सभी व्यक्तियों से 360 प्रतिक्रिया प्राप्त करें। यदि आपके सभी टीम के सदस्यों को लगता है कि आप बकवास कर रहे हैं, तो आप शायद हैं।
सॉफ्टवेयर डेवलपर्स में केपीआई की बात करते हुए। www.smartKPIs.com आपके लिए एक अच्छा संसाधन हो सकता है। इसमें अच्छी तरह से प्रलेखित प्रदर्शन उपायों की एक उपयोगकर्ता के अनुकूल पुस्तकालय शामिल है। फिलहाल यह 7300 से अधिक केपीआई उदाहरणों को सूचीबद्ध करता है, जिसमें 73 कार्यात्मक क्षेत्रों, साथ ही 83 उद्योग और उप श्रेणियां भी शामिल हैं।
सॉफ्टवेयर डेवलपर्स के लिए KPI उदाहरण यह पेज www.smartKPIs.com - application development पर उपलब्ध हैं उनमें शामिल हैं लेकिन सीमित नहीं:
प्रदर्शन उपायों के उदाहरण के अलावा , www.smartKPIs.com में प्रदर्शन रिपोर्टों की एक सूची भी शामिल है जो अभ्यास में केपीआई के उपयोग को दर्शाती है। सूचना प्रौद्योगिकी के लिए ऐसी रिपोर्ट के उदाहरण यहां उपलब्ध हैं: www.smartKPIs.com - अभ्यास में केपीआई - सूचना प्रौद्योगिकी वेबसाइट को नई सामग्री के साथ दैनिक अद्यतन किया जाता है, इसलिए अतिरिक्त सामग्री के लिए समय-समय पर इसे जांचें।
कृपया ध्यान दें कि प्रदर्शन उपायों के उदाहरण निर्णय लेने के लिए उपयोगी हैं, प्रत्येक प्रदर्शन उपाय को प्रत्येक संगठन के उद्देश्यों और प्राथमिकताओं के आधार पर चुना और अनुकूलित करने की आवश्यकता है।
मुझे लगता है कि डेवलपर्स के प्रदर्शन को मापने के तरीकों का निर्णय लेने के दौरान इसे बहुत सावधानीपूर्वक दृष्टिकोण की आवश्यकता होती है क्योंकि कोड की रेखा, चेक इन की संख्या, निश्चित बग की संख्या आदि जैसी पारंपरिक विधियां आज के सॉफ्टवेयर के साथ व्यक्तिपरक साबित होती हैं। इंजीनियरिंग अवधारणाओं। हमें एक परियोजना में व्यक्तिगत केपीआई को मापने के बजाय टीम प्रदर्शन दृष्टिकोण को महत्व देने की आवश्यकता है। हालांकि वाणिज्यिक विकास पर्यावरण में काम करना व्यक्तिगत डेवलपर्स के निम्नलिखित कारकों पर एक ट्रैक रखने और नज़दीकी नजर रखने के लिए महत्वपूर्ण है;
कुछ परियोजनाओं में चुस्त दृष्टिकोण के साथ, विकास टीम के माप और अपेक्षित प्रदर्शन रिलीज के आधार पर तय किए जाते हैं। प्रत्येक रिलीज प्लानिंग में अपेक्षित प्रदर्शन के लिए टीम के सदस्यों के साथ बातचीत के विभिन्न 'अनुबंध' होते हैं।मुझे लगता है कि यह दृष्टिकोण अधिक सफल है क्योंकि रिलीज में यूआई से संबंधित मापों का पालन करने का कोई कारण नहीं है जहां एक जटिल एल्गोरिदम जारी किया जाना है।
मैं अपना अनुभव साझा करता हूं और टीम प्रदर्शन को मापने के लिए मैंने एक बहुत ही मूल्यवान प्रक्रिया कैसे सीखी। मुझे स्वीकार करना होगा, मैं केवल केपीआई को ट्रैक करने पर गिर गया हूं क्योंकि अधिकांश विभाग वही करेंगे, लेकिन वास्तव में अंतर्दृष्टि के लिए नहीं जब तक कि डेवलपर्स प्रदर्शन का मूल्यांकन करने की ज़िम्मेदारी न हो, जहां कई समाधानों के बाद मैंने निम्नलिखित समाधान के साथ विकसित किया।
एक परियोजना, मैं परियोजना की आवश्यकताओं पर चर्चा में टीम का मनोरंजन करता हूं और उन्हें शामिल करता हूं ताकि सभी जानते हैं कि क्या किया जाना है। सहयोग के माध्यम से एक ही चर्चा में हम परियोजनाओं को कार्यों में तोड़ देंगे और उन कार्यों को वज़न देंगे। अब पहले हम परियोजना पूर्ण होने का अनुमान लगाएंगे 100% जहां प्रत्येक कार्य में प्रतिशत योगदान होता है। वैसे यह थोड़ी देर के लिए काम किया लेकिन सबसे अच्छा समाधान नहीं था। अब हम वजन या अंक पर कार्य को सटीक मानते हैं और कार्य की तुलना करने के लिए सापेक्ष माप का उपयोग करते हैं और उदाहरण के लिए वजन को अलग करते हैं। उपयोगकर्ता डेटा एकत्र करने के लिए एक वेब फॉर्म विकसित करने की आवश्यकता है। टास्क की तरह
1. User Interface - 2 Points
2. Database CRUD - 5 Points
3. Validation - 4 Points
4. Design (css) - 3 Points
के बारे में जाना होगा इस रणनीति हम बिंदु कितना हम पूरा कर लिया है और क्या टास्क फोर्स पर लंबित है पर एक साप्ताहिक अनुमानित पिन कर सकते हैं के साथ। हम उस बिंदु को पिन करने में सक्षम भी हो सकते हैं जिसने सर्वश्रेष्ठ प्रदर्शन किया है।
मुझे यह स्वीकार करना होगा कि मुझे अभी भी इस रणनीति पर कुछ चुनौतियों का सामना करना पड़ रहा है जैसे हर डेवलपर हर तकनीक पर सहज नहीं है। किसी भी तरह से कुछ तकनीक सीखने के लिए उत्साहित हैं क्योंकि उन्हें लगता है कि उस अनुभाग में 2015 के उच्च अंक गिरते हैं जो कुछ कर सकते हैं।
याद रखें, अपने स्वयं के लिए केपीआई को ट्रैक न करें, इसे अंतर्दृष्टि के लिए ट्रैक करें।
एक आम गलती है कि कई व्यवसाय अपने रिलीज प्रबंधन उपकरण की स्थापना करते समय करते हैं। सेल्सफोर्स रिलीज मैनेजमेंट टूलकिट आज बाजार में उपलब्ध सबसे अच्छे लोगों में से एक है, लेकिन यदि आप इसे स्थापित करने के महत्वपूर्ण कदमों का पालन नहीं करते हैं, तो आपके पास निश्चित रूप से कुछ बहुत खराब परिणाम होंगे। आप इसका उपयोग करेंगे, लेकिन इसकी पूरी क्षमता के लिए नहीं। व्यावसायिक प्रक्रियाओं से अलगाव में रिलीज प्रबंधन प्रक्रियाओं की स्थापना करना सबसे खराब गलतियों में से एक है। रिलीज प्रबंधन उपकरण एंटरप्राइज़ रणनीति, उद्देश्यों, शासन, परिवर्तन प्रबंधन और कुछ अन्य पहलुओं के साथ हाथ में हैं। रिलीज प्रबंधन की प्रक्रियाओं को इस तरह से गठित करने की आवश्यकता है कि व्यवसाय में हर कोई एक ही पृष्ठ पर है। रिलीज प्रबंधन की
लक्ष्य रिलीज प्रबंधन का मुख्य लक्ष्य विश्वसनीय और repeatable प्रक्रियाओं है कि संसाधन स्वतंत्र हैं का एक संगत सेट है। यह उपलब्ध सर्वोत्तम संसाधनों के उपयोग को अनुकूलित करने के साथ ही सबसे अनुकूल व्यापार मूल्य की उपलब्धि को सक्षम बनाता है। यह ध्यान में रखते हुए कि अधिकांश संगठन छोटी, उच्च उपज वाली व्यावसायिक परियोजनाओं को चलाने पर ध्यान केंद्रित करते हैं, यह सुनिश्चित करने के लिए कि आवेदन मूल्य की डिलीवरी मूल्य श्रृंखला के अनुकूलन के लिए यह आवश्यक है कि व्यापार मूल्य की डिलीवरी में कोई होल्डअप न हो।
उदाहरण के लिए force.com माइग्रेशन टूलकिट लें, क्योंकि यह टूल शासन में महान साबित हुआ है। एक रिलीज प्रबंधन उपकरण को शासन में इष्टतम दृश्यता और उत्तरदायित्व की अनुमति देनी चाहिए।
प्रक्रियाएं और रिलीज चक्र रिलीज प्रबंधन प्रक्रिया पूरे व्यवसाय के लिए सुसंगत होना चाहिए। विभिन्न टूल उपयोगकर्ताओं में सुव्यवस्थित और मानकीकृत प्रक्रियाओं के लिए आवश्यक है। ऐसा इसलिए है क्योंकि वे एक ही मंच और संसाधनों का उपयोग करेंगे जो उनके कार्यों के कुशल समापन को सक्षम करते हैं।आपके व्यवसाय के विभिन्न डिवीजनों के लिए विभिन्न प्रक्रियाओं के कारण टूल प्रबंधन में गंभीर विफलताओं का कारण बन सकता है। उपयोगकर्ताओं के विभिन्न सेटों में दृश्यता की आवश्यकता होगी कि दूसरे क्या कर रहे हैं। जैसा कि उपर्युक्त है, किसी भी व्यावसायिक प्रक्रिया में दृश्यता बहुत महत्वपूर्ण है।
जब रिलीज चक्र की बात आती है, तो यह भी एक केंद्रीकृत प्रणाली होना जरूरी है जो उपयोगकर्ताओं के विभिन्न सेटों की सभी आवश्यकताओं को ट्रैक करेगी। इस प्रणाली को केंद्रीकृत करना भी आवश्यक है ताकि सॉफ्टवेयर डेवलपमेंट टीमों को व्यापार द्वारा अनुरोध की गई सुविधाओं और परिवर्तनों में अंतर्दृष्टि मिल सके। अनुरोधों को यह सुनिश्चित करने के लिए प्राथमिकताएं बननी होंगी कि व्यवसाय को अधिकतम लाभ का आनंद मिले। एक स्टीयरिंग टीम रखना महत्वपूर्ण है क्योंकि यह व्यावसायिक आवश्यकताओं की समीक्षा में शामिल है और साथ ही व्यवसाय को सबसे उचित परिवर्तनों को प्राथमिकता देने में भी शामिल है।
सेल्सफोर्स सिस्टम के साथ होने वाले परिवर्तन बहुत मुश्किल हो सकते हैं और इसलिए व्यवसाय और आईटी के बीच नियमित रूप से मिलना अच्छा होता है। यह उस प्रणाली को बनाने में सर्वोत्तम बदलाव निर्धारित करने में मदद करेगा जो व्यापार को लाभ पहुंचाएगा। किसी सुविधा को लागू करने की लागत और मूल्य पर विचार करके, स्टीयरिंग कमेटी के पास सबसे महत्वपूर्ण फीचर बदलावों का निर्णय लेने का कार्य है। यहाँ भी अच्छा अनुसंधान http://intersog.com/blog/tech-tips/how-to-manage-millennials-on-software-development-teams
यह एक पुरानी सवाल है, लेकिन अभी भी कुछ आप कर सकते हैं फुर्तीली सॉफ्टवेयर विकास, जहाँ आप प्रत्येक कार्य के लिए एक वजन आवंटित और फिर आप कितना "वजन" आप में हल की गणना से Velocity उधार है प्रत्येक स्प्रिंट (या पुनरावृत्ति या जो भी डीएलसी आप उपयोग करते हैं)। बेशक यह इस तथ्य के साथ आता है कि, पहले उल्लेखित एक टिप्पणीकार की तरह, आपको सक्रिय रूप से अपने आप को ट्रैक रखने की आवश्यकता है कि आपके डेवलपर काम कर रहे हैं या ऑनलाइन चैट कर रहे हैं या नहीं।
यदि आप जानते हैं कि आपके डेवलपर उत्तरदायी रूप से काम कर रहे हैं, तो आप यह अनुमान लगाने के लिए कि velocity पर भरोसा कर सकते हैं कि टीम कितनी काम कर सकती है। यदि किसी भी पुनरावृत्ति पर यह संख्या बूँदें (काफी), तो या तो खराब अनुमान लगाया गया था या टीम कम काम करती थी।
आखिरकार, KPIs का उपयोग वेग के साथ-साथ आपको प्रदर्शन पर प्रति-डेवलपर (या प्रति-टीम) अंतर्दृष्टि प्रदान कर सकता है।
आपके प्रोग्रामर क्या कर रहे हैं में सक्रिय रुचि लें और आपको कुछ जानकारी देने के लिए कुछ यादृच्छिक सॉफ़्टवेयर टूल पर निर्भर न हों जो इसे देने के लिए डिज़ाइन नहीं किया गया था। –
संबंधित: http://programmers.stackexchange.com/questions/26596/metric-by-which-to-hold-developers-accountable –
यह प्रश्न ऑफ़-विषय प्रतीत होता है क्योंकि यह प्रदर्शन के "मापने" के बारे में है -duh-viduals। – devnull