परियोजनाओं के मूल्यांकन के लिए उपयोगी मेट्रिक्स

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

कुछ भी क्यों नापें?

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

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

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

और अगर वे नहीं आते हैं, तो मीट्रिक को सुरक्षित रूप से फेंक दिया जा सकता है;)

कहानी १: उसे यहाँ किसने आने दिया ??

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

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

यह बहुत है या थोड़ा है? मेरे अनुभव में, यह एक बहुत अच्छा प्रतिशत है। फिर क्यों राय है कि परीक्षकों को बहुत याद आती है?

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

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

• रिलीज़ संस्करण त्रुटियों में% छूट गया
• % उपयोगकर्ता ने त्रुटियों की सूचना दी

हम एक लक्ष्य निर्धारित करते हैं (अन्यथा हमें कुछ भी क्यों मापना चाहिए?); हम 10% से अधिक त्रुटियां चाहते हैं जो रिलीज़ संस्करण को हिट करते हैं। लेकिन यह कैसे सुनिश्चित किया जाए? अत्यधिक संसाधनों का विस्तार? टाइमलाइन बढ़ाएं?

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

इस मामले में, सभी चूक त्रुटियों के लिए, हमने एक और फ़ील्ड जोड़ी: "लंघन का कारण"। और हम संकेत देते हैं कि हमने इस बग को पहले क्यों नहीं प्राप्त किया:

• अज्ञात आवश्यकता (पता नहीं था या यह नहीं समझा था कि यह आवश्यक था)
• परीक्षण को ध्यान में नहीं रखा (एसओ के परीक्षण के बारे में नहीं सोचा)
• परीक्षण नहीं किया गया (परीक्षण था, यह जाँच की गई थी, लेकिन फिर कार्यक्षमता टूट गई, और यह क्षेत्र फिर से जाँच नहीं किया गया)

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

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

हम अभी तक 10% तक नहीं पहुंचे हैं, लेकिन जुलाई में यह 14% था - हम पहले से ही लक्ष्य के बहुत करीब हैं, और कार्यान्वयनकर्ताओं के आश्वासन से देखते हुए, ग्राहकों ने पहले से ही गुणवत्ता में बदलाव देखा है। बुरा नहीं है, है ना?

कहानी 2: जलाऊ लकड़ी कहाँ से आई?

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

स्वाभाविक रूप से, मैंने अपनी व्यक्तिपरक भावनाओं को "धीरे-धीरे" मापने की कोशिश करके शुरू किया। इसे कैसे समझें? क्या तुलना करें? प्रति माह KLOC? पुनरावृति की सुविधा? योजना के संबंध में औसत टूट? स्वाभाविक रूप से, पहले 2 मैट्रिक्स कुछ भी उपयोगी नहीं लाएंगे, इसलिए मैंने सुविधाओं के संदर्भ में% ब्रेकडाउन को देखना शुरू किया (पुनरावृत्तियों में सुविधाओं का एक निश्चित सेट नहीं है, इसलिए वे गंभीरता से देर से नहीं हो सकते हैं - जो हम 2 सप्ताह में करने और परीक्षण करने में कामयाब रहे, फिर हम इसे पोस्ट करते हैं)। लेकिन सुविधाएँ!

यह पता चला कि उनके अनुसार हम औसतन 1.5-2 बार शब्दों को बाधित करते हैं! मैं आपको यह नहीं बताऊंगा कि रेडिमाइन से यह जानकारी प्राप्त करने के लिए मुझे क्या लागत है, लेकिन यहां यह है। और मैं "पांच" क्यों "के सिद्धांत का उपयोग करके आगे खुदाई करना चाहता हूं।" ऐसा क्यों? क्या हम योजना बनाने में बुरे हैं? मैं बहुत तेजी से परिणाम चाहते हैं? या कम योग्यता? क्या समय लगता है?

मैंने विश्लेषण करना शुरू किया: औसतन, 15 से 40 कीड़ों के लिए 1 छोटा फीचर खाता है, और उन्हें ठीक करने में अधिक समय लगता है, ताकि वे स्वयं फीचर विकसित कर सकें। क्यों? यह बहुत है या थोड़ा है? डेवलपर्स शिकायत करते हैं कि पहले से ही विकसित कार्यक्षमता को बदलने के लिए बहुत सारे अनुरोध हैं - क्या यह सच है या व्यक्तिपरक गलत आकलन है?

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

• कोड (यहां उन्होंने इसे प्राप्त किया और इसे गड़बड़ कर दिया)
• आवश्यकताओं की गलतफहमी ("ओह मुझे समझ में नहीं आया कि वास्तव में क्या आवश्यक था!"
• आवश्यकताओं में बदलाव (उत्पाद के मालिक ने परिणाम को देखा और कहा "उह, वास्तव में, इसे अलग करने की आवश्यकता है, और जिस तरह से मैंने अनुरोध किया है वह नहीं)

कोड में हमारे पास लगभग 30% त्रुटियां थीं। आवश्यकताओं में परिवर्तन - 5% से कम (डेवलपर्स आश्चर्यचकित थे, लेकिन स्वीकार किया गया - यह इसलिए है क्योंकि वे कारण इंगित करते हैं!)। और लगभग 70% त्रुटियां आवश्यकताओं की समझ की कमी के कारण हुईं। हमारे मामले में, जब एक बगफिक्स अधिक विकास लेता है, तो यह एक विशेषता को विकसित करने के द्वारा किया गया HALF TIME SPENDED है।

क्या करें?

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

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

अब हमारे पास एक सप्ताह में लगभग 3-7 ऐसे प्रति घंटा "बात करने वाले" हैं, जिनके लिए 2-3 लोग आते हैं। आरंभ किए गए बगों की संख्या कम हो गई है, जिनमें से 50% से अधिक कोड त्रुटियां बन गई हैं - इसलिए, हमारा अगला कार्य समीक्षा शुरू करना होगा, जैसे अब हमारे पास एक नई "मुख्य समस्या" है।

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

और यह सिर्फ शुरुआत है! ;-)

इतिहास # 3: कौन डेवलपर्स को धीमा कर रहा है?

एक और कहानी एक तीसरे पक्ष की कंपनी के साथ मेरे हाल के अनुभव की चिंता करती है। सच-असली चपल, साप्ताहिक पुनरावृत्तियों ... और साप्ताहिक समय सीमा!

कंपनी के प्रबंधन द्वारा कहा गया कारण: "डेवलपर्स बहुत अधिक बग की अनुमति देते हैं।"

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

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

और आपको क्या लगता है, "फीचर को टेस्टिंग के लिए दिया गया था" और "फ़ीचर का परीक्षण किया गया है और संशोधन के लिए भेजा गया है" के बीच का औसत समय क्या है? 1.5 दिन!

और कभी-कभी - केवल अवरुद्ध दोष के साथ।

इस कंपनी के डेवलपर्स ने ब्रेक टेस्टर के बारे में शिकायत की थी, लेकिन टेस्टर और प्रबंधन डेवलपर्स के खिलाफ थे: "आपको स्वयं परीक्षण करना होगा और कच्चा उत्पाद नहीं देना होगा।" लेकिन सीज़र की सीज़र!

इसलिए, एक मीट्रिक है, 1.5 दिन अस्वीकार्य रूप से लंबा है, हम कम से कम तीन बार कम करना चाहते हैं - यह एक दिन में रिलीज को गति देना चाहिए। यह कैसे करना है? फिर से, एक मंथन, फिर से विचारों का एक गुच्छा, प्रक्रिया में भाग लेने वाले 90% जोर देते हैं कि "डेवलपर्स को खुद के लिए परीक्षण करना चाहिए।"

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

हमने बहुत जल्दी 1.5 से 0.5 दिनों का कार्यकाल कम कर दिया, लेकिन व्यवहार में हमने एक और, अधिक गंभीर बदलाव हासिल किया: "रिविजन के लिए भेजे गए" स्थिति में स्थानांतरित सुविधाओं का% लगभग 80 से घटकर लगभग 20 हो गया! वह 4 गुना है! अर्थात्, 80% विशेषताओं को "परीक्षण" स्थिति में स्थानांतरित करने के तुरंत बाद स्वीकार कर लिया गया था, क्योंकि इस स्थिति में स्थानांतरण से कुछ समय पहले, परीक्षण को मक्खी पर किया गया था, जो त्रुटियों को दर्ज करने और उन्हें ठीक करने की लागत दोनों के लिए बहुत कम कर देता है।

वैसे, कहानी 3 ही एकमात्र ऐसी जगह है जहाँ हमने तुरंत अपना लक्ष्य हासिल किया। पुनरावृत्तियों के लिए बाधाएं अभी भी हैं, लेकिन अब यह अपवाद है, और लगभग हर गुरुवार को विकास टीम समय पर घर छोड़ देती है, और शुक्रवार को सच्चाई अगले पुनरावृत्ति की तैयारी शुरू कर देती है।

बिंगो!

निष्कर्ष

मैं वास्तव में सूखे फार्मूले नहीं बनाना चाहता था, दार्शनिकता और सिद्धांत बनाना चाहता था। मैंने ताजा (2012!) अनुभव से विशिष्ट कहानियां बताईं। ऐसी कहानियां जिनमें हमने बजट में बदलाव किए बिना समय सीमा और गुणवत्ता में सुधार किया।

क्या आप अभी भी अच्छे प्रभाव के लिए मैट्रिक्स का उपयोग करने के लिए तैयार नहीं हैं?

फिर हम आपके पास जाते हैं! :)