Delivery system को मापें

जरूरी निर्णय से शुरू करें

Team जानना चाहती है कि AI delivery सुधारता है या नहीं। Generated lines गिनना अलग प्रश्न का उत्तर है। Metric चुनने से पहले उपयोगी परिणाम और quality की शर्तें तय करें।

काल्पनिक export service में इच्छित परिणाम कम कुल प्रयास से स्वीकार किए बदलावों की भरोसेमंद delivery है। तैयारी, implementation, review, सुधार और इंतजार दर्ज करें। Failed या छोड़े गए changes शामिल करें।

स्पष्ट सीमा वाली एक service लें। प्रयोग वाली website और महत्वपूर्ण payment service को जोड़ने से ऐसा आँकड़ा बन सकता है जो दोनों को नहीं समझाता। समय-अवधियों या teams की तुलना से पहले context बताएँ।

वर्तमान परिभाषाएँ इस्तेमाल करें

DORA के वर्तमान delivery model में पाँच metrics हैं। उनका दायरा delivery performance है, हर feature का मूल्य या किसी व्यक्ति का योगदान नहीं। DORA metric definitions।

Dashboard दूसरी परिभाषा इस्तेमाल कर सकता है। परिणाम का अर्थ निकालने से पहले उसे पढ़ें। Taiga का वर्तमान deployment documentation provider deployment records से निकाले चार reported metrics बताता है। उसका recovery measure बाद के successful deployment का उपयोग करता है। यह हर production incident का पूरा record नहीं है। Taiga की परिभाषाएँ।

काल्पनिक बदलावों की प्रक्रिया देखें

मान लें service महीने में बारह deployments करती है। आठ planned changes देते हैं। चार पुराने releases की समस्याएँ ठीक करते हैं। संख्या बारह है, लेकिन उसमें किस तरह का काम है, यह मायने रखता है।

अगले महीने team दस deployments करती है: नौ planned changes और एक repair। कम deployments के साथ अधिक उपयोगी काम हो सकता है। ये आँकड़े अर्थ समझाने के लिए हैं; performance benchmark नहीं।

Distribution भी देखें। एक लंबा review wait औसत में छिप सकता है। अकेली failure का recovery measure भविष्य की reliability का कमजोर प्रमाण है। Observations की संख्या और महत्वपूर्ण exceptions बताएँ।

Flow को परिणामों के साथ देखें

Delivery changes का users पर असर जाँचने के लिए service signals इस्तेमाल करें। Exports अधिक fail हों तो तेज pipeline पर्याप्त नहीं है। उचित SLO या दूसरा स्पष्ट outcome measure लें। SLO guidance।

Review का प्रयास और rework परिणाम समझाते हैं। AI implementation का समय घटाए लेकिन बड़े diffs बनाए तो review बाधा बन सकता है। Environments पाने में दिन लगते हों तो तेज coding का कुल delivery time पर कम असर हो सकता है।

देखी गई बाधा हल करने वाला एक सुधार चुनें। उदाहरण के लिए, supported test environment दें या बदलाव का आकार घटाएँ। Quality का साथ में मापा जाने वाला metric तय करें, ताकि कमजोर checks के कारण दिखने वाला speed gain पकड़ा जा सके।

Measurement को उपयोगी रखें

PR counts या generated code पर व्यक्तिगत rankings से बचें। ये माप काम को कृत्रिम रूप से बाँटने, कठिन maintenance टालने या review का प्रयास सहकर्मियों पर डालने को बढ़ावा दे सकते हैं।

पूरी service के जिम्मेदार लोगों के साथ परिणाम का review करें। Tool, काम के प्रकार, team और environment में क्या बदला, यह दर्ज करें। Before-and-after तुलना को सीमाओं वाला प्रमाण मानें, कारण का अपने आप प्रमाण नहीं।

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

दस बदलावों से अभ्यास करें

यह अलग काल्पनिक dataset दस planned changes दर्ज करता है। सभी समय दी गई तारीख पर UTC में हैं। खाली correction field का अर्थ है कि इस dataset में कोई correction दर्ज नहीं है।

Code तैयार होने से review शुरू होने तक, फिर acceptance से release तक के समय की तुलना करें। सबसे लंबा दिखाई देने वाला इंतजार पहचानें। उसे टाला जा सकने वाला कहने से पहले कारण जाँचें। ये timestamps सक्रिय प्रयास नहीं मापते और incident कब शुरू हुआ यह नहीं बताते। केवल correction release से failed deployment recovery time सिद्ध नहीं होता।

काल्पनिक dataset download करें (CSV)