विस्तृत मार्गदर्शिका
क्यूए और स्प्रिंट अड़चन सिम्युलेटर: जब डेवलपर परीक्षण की क्षमता से आगे निकल जाते हैं
उद्योग का कार्यकारी विश्लेषण
सॉफ्टवेयर टीम एक पाइपलाइन है, और पाइपलाइन अपने सबसे धीमे चरण से तेज जारी नहीं कर सकती। जब डेवलपर उतने फीचर पूरे करते हैं जितने परीक्षक जांच नहीं सकते, तो अतिरिक्त काम गायब नहीं होता; वह एक कतार में जुड़ जाता है। प्रबंधक व्यस्त डेवलपर और भरा हुआ स्प्रिंट बोर्ड देखते हैं और निष्कर्ष निकालते हैं कि टीम उत्पादक है। पर जो फीचर बना है और जांचा नहीं गया उसने कुछ नहीं कमाया, और वह जितने सप्ताह इंतजार करता है उतना मूल्य खोता है। ऐसी स्थिति में डेवलपर जोड़ना वेतन-बिल और कतार की लंबाई साथ-साथ बढ़ाता है और जारी हुआ उत्पादन ठीक वहीं छोड़ देता है जहां था।
समस्या की बनावट दो दरों के बीच का अंतर है। डेवलपर का उत्पादन डेवलपरों की संख्या गुणा हर एक के पूरे किए फीचर है। क्यूए की क्षमता परीक्षकों की संख्या गुणा हर एक के जांच सकने वाले फीचर है। जारी हुए फीचर दोनों में से छोटे हैं, और उनके बीच का अंतर वह दर है जिस पर कतार बढ़ती है। चूंकि कतार महीने दर महीने जमा होती है, उसकी लागत स्थिर नहीं रहती; वह बढ़ती है। थोड़ी सी क्षमता से अधिक भार वाली टीम पहले स्प्रिंट में ठीक दिखती है और छठे तक स्पष्ट रूप से टूटी हुई, इसीलिए इस समस्या को बड़ी होने तक अनदेखा करना आसान है।
डोमिनो प्रभाव क्रम दिखाता है। ऊंचा डेवलपर उत्पादन मांगी गई क्यूए क्षमता के हिस्से को सौ प्रतिशत से ऊपर ले जाता है। वह भार कतार को बढ़ाता है, जो उसके पीछे के हर फीचर को विलंबित करती है। इंतजार सीधे मूल्य खर्च कराता है, और वह डेवलपरों को बग सुधारों और सवालों के जरिये पुराने काम में वापस खींचता है, इसलिए उनका समय संदर्भ बदलने में खो जाता है। अतिभार वाले परीक्षक जल्दबाजी करते हैं, और अधिक दोष निकल जाते हैं। हर चरण अगले को पोषित करता है, इसलिए दूसरे डिब्बे में छोटा सा अतिभार कुछ ही स्प्रिंट में अंतिम डिब्बे को लाल कर सकता है।
हिमशैल वेतन-बिल को अड़चन की लागत से अलग करता है। जलरेखा के ऊपर डेवलपर और क्यूए के वेतन हैं, जिन्हें सब देखते हैं। उसके नीचे चार लागतें हैं जिन्हें शायद ही कभी पंक्ति मिलती है: फीचरों के इंतजार में खोया मूल्य, उन बग की लागत जो जल्दबाजी में हुए परीक्षण के कारण ग्राहकों तक पहुंचे, संदर्भ बदलने में खोया डेवलपर का समय, और अतिभार में परीक्षकों का ओवरटाइम। मिलकर ये उस अतिरिक्त परीक्षक की लागत से अधिक हो सकती हैं जो इन्हें हटा देता। वह डेवलपर-से-क्यूए अनुपात खोजने के लिए सिम्युलेटर का उपयोग करें जिस पर आपकी पाइपलाइन अपनी लागत निकालना बंद कर देती है, फिर उसकी तुलना एक परीक्षक जोड़ने से करें।
सूत्र और कार्यप्रणाली का खाका
यह मॉडल स्थिर अवस्था में हर महीने के हिसाब से काम करता है। डेवलपर का उत्पादन डेवलपर गुणा हर एक के फीचर हैं। क्यूए की क्षमता परीक्षक गुणा हर एक के फीचर हैं। जारी हुए फीचर दोनों में से छोटे हैं। कतार हर महीने उस अंतर से बढ़ती है, और छह महीने की अवधि में औसत कतार उस वृद्धि के छह गुना का आधा है। देरी की लागत औसत कतार गुणा देरी की लागत है। हर कतार में लगे फीचर के लिए डेवलपर संदर्भ बदलने में समय का 1% खोते हैं, अधिकतम 20% तक। निकल गए दोष अतिभार के साथ बढ़ते हैं।
- डेवलपर का उत्पादन
- P = डेवलपर × प्रति डेवलपर फीचर
- हर महीने पूरे होकर क्यूए को सौंपे गए फीचर।
- जारी हुए फीचर
- S = min(P, परीक्षक × प्रति परीक्षक फीचर)
- पाइपलाइन केवल वही जारी कर सकती है जिसे परीक्षण सत्यापित करता है।
- कतार
- Q = max(0, P − क्षमता) × 3
- छह महीने की अवधि में प्रतीक्षारत फीचरों की औसत संख्या, क्योंकि कतार रैखिक रूप से बढ़ती है।
- निकले दोष की लागत
- E = S × (3% + 15% × अतिभार) × 4,000
- क्यूए पर अतिभार बढ़ने के साथ ग्राहकों तक पहुंचने वाले दोष बढ़ते हैं, प्रत्येक की लागत 4,000।
- पाइपलाइन का परिणाम
- शुद्ध = S × मूल्य − वेतन-बिल − Q × देरी की लागत − E − संदर्भ बदलने का कर − क्यूए ओवरटाइम
- मासिक परिणाम। लाभ-हानि की बराबरी का भार वह है जहां यह शून्य पर पहुंचता है।
क्रमिक संवेदनशीलता
डेवलपर के उत्पादन और क्यूए की क्षमता के बीच का अंतर सबसे अधिक संवेदनशील कारक है, क्योंकि वह कतार, देरी, संदर्भ बदलने और निकले दोषों को एक साथ चलाता है। प्रति फीचर मूल्य जारी हुए उत्पादन को सीधे बढ़ाता है। वेतन-बिल रैखिक है और सीमा की तरह काम करता है, इसीलिए एक परीक्षक जोड़ना अक्सर अपनी लागत से कई गुना वसूल करता है।
वास्तविक दुनिया के तीन केस अध्ययन
स्वयं-वित्तपोषित शुरुआती व्यवसाय
तीन लोगों की उत्पाद टीम
तीन डेवलपर और एक परीक्षक एक छोटे उत्पाद पर काम करते हैं। डेवलपर महीने में छह फीचर पूरे करते हैं और परीक्षक सात जांच सकता है, इसलिए कुछ भी कतार में नहीं रुकता। इसे लोड करके एक संतुलित छोटी टीम देखें जहां जारी करना बनाने के बराबर है और ठीक करने के लिए कोई अड़चन नहीं है।
विस्तार करता मध्यम बाज़ार
संतुलित चौबीस डेवलपरों का संगठन
एक बड़ा संगठन चौबीस डेवलपरों के लिए सात परीक्षक रखता है और स्वचालन में निवेश करता है, इसलिए क्यूए डेवलपर के उत्पादन से थोड़ा अधिक है। कतारें न्यूनतम हैं और जारी हुआ मूल्य ऊंचा है। इसे लोड करके देखें कि स्वस्थ अनुपात एक बड़ी टीम को लाभदायक कैसे रखता है।
ब्लैक स्वान संकट
दस डेवलपर और दो अतिभारित परीक्षक
दस तेज डेवलपर महीने में तीस फीचर पूरे करते हैं, पर दो परीक्षक केवल दस जांच सकते हैं। कतार हर महीने बीस फीचर बढ़ती है, बग निकल जाते हैं और डेवलपर बार-बार पुराने कोड पर लौटते हैं। इसे लोड करके देखें कि अनुपात की समस्या बड़े वेतन-बिल को घाटे में कैसे बदल देती है।
उद्योग बेंचमार्क तालिका
| मापदंड | खतरे का क्षेत्र | उद्योग औसत | शीर्ष 10% श्रेष्ठ |
|---|---|---|---|
| प्रति परीक्षक डेवलपर | 8:1 से ऊपर | 3–5:1 | स्वचालन के साथ लगभग 2–3:1 |
| क्यूए भार (क्षमता के मुकाबले डेवलपर का उत्पादन) | 130% से ऊपर | 90–105% | 90% से नीचे |
| परीक्षण की प्रतीक्षा में औसत कतार | 10 फीचर से अधिक | 2–4 फीचर | 2 फीचर से कम |
| प्रति रिलीज उत्पादन में निकले दोष | 10% से ऊपर | 3–6% | 2% से नीचे |
| पूरा होने से जारी होने तक का चक्र समय | 4 सप्ताह से अधिक | 1–2 सप्ताह | 3 दिन से कम |
चर और नियंत्रक कारक
डेवलपर
फीचर बनाने वाले इंजीनियर। अधिक डेवलपर उत्पादन बढ़ाते हैं पर परीक्षण की गति नहीं।
नियंत्रक कारक: परीक्षण क्षमता बढ़ने से पहले डेवलपर न जोड़ें; चालू कामों की सीमा तय करें ताकि टीम कम पूरा करे पर अधिक जारी करे।
प्रति डेवलपर प्रति माह पूरे किए फीचर
एक डेवलपर महीने में जितने फीचर पूरे करके क्यूए को सौंपता है।
नियंत्रक कारक: प्रति स्प्रिंट शुरू किए जाने वाले फीचरों को उतने तक सीमित करें जितने क्यूए जांच सके, क्योंकि पूरे हुए पर बिना जांचे काम से कोई कमाई नहीं होती।
क्यूए परीक्षक
रिलीज से पहले फीचरों की जांच करने वाले लोग।
नियंत्रक कारक: परीक्षक जोड़ें या टीम में परीक्षण इंजीनियर शामिल करें, क्योंकि हर परीक्षक उन फीचरों का एक खंड खोल देता है जो अभी इंतजार में हैं।
प्रति परीक्षक प्रति माह जांचे गए फीचर
एक परीक्षक महीने में जितने फीचरों की पूरी जांच, दोबारा जांच और स्वीकृति कर सकता है।
नियंत्रक कारक: रिग्रेशन परीक्षण स्वचालित करें और स्वीकृति मानदंड पहले से लिखें, ताकि परीक्षक पुरानी जांचें दोहराने के बजाय नए काम की जांच करें।
जारी हुए फीचर का मूल्य
उपयोगकर्ताओं तक पहुंचने पर एक फीचर जितना राजस्व, ग्राहक प्रतिधारण या बचत लाता है।
नियंत्रक कारक: फीचरों को मूल्य के अनुसार प्राथमिकता दें और कम मूल्य वाले छोड़ दें, क्योंकि परीक्षण क्षमता उसी पर खर्च होती है जो कतार में आता है।
प्रति फीचर प्रति माह देरी की लागत
कतार में इंतजार करने वाला हर फीचर हर महीने जितना खोता है, खोए राजस्व या ग्राहक भरोसे के रूप में।
नियंत्रक कारक: छोटे बदलाव अधिक बार जारी करें, जिससे हर फीचर का इंतजार छोटा होता है और देरी की लागत घटती है।
इस सिमुलेटर का उपयोग कैसे करें
- 1डेवलपरों की संख्या और हर एक द्वारा महीने में पूरे किए फीचर दर्ज करें।
- 2परीक्षकों की संख्या और हर एक द्वारा जांचे जा सकने वाले फीचर तय करें।
- 3जारी हुए फीचर का मूल्य और प्रति फीचर प्रति माह देरी की लागत का अनुमान लगाएं।
- 4पांचों डोमिनो पढ़ें और देखें कि क्यूए भार सौ प्रतिशत से कब ऊपर जाता है।
- 5समानांतर ब्रह्मांड टैब में अतिरिक्त परीक्षक योजना से तुलना करें और लिंक साझा करें।
इन गलतियों से बचें
- डेवलपरों को पूरे किए फीचरों से मापना। परीक्षण की प्रतीक्षा में पड़ा काम भंडार है, उत्पादन नहीं।
- लंबी अवधि पर औसत लेना। हर महीने बढ़ती कतार शुरू में छोटी और बाद में बड़ी दिखती है।
- परीक्षकों को घटाई जाने वाली लागत मानना। अड़चन की स्थिति में परीक्षक की क्षमता पाइपलाइन की सबसे मूल्यवान क्षमता है।
- केवल देरी की लागत गिनना। निकले हुए बग और संदर्भ बदलना अक्सर उससे अधिक होते हैं।
अक्सर पूछे जाने वाले प्रश्न
डेवलपर जोड़ने से जारी हुआ उत्पादन क्यों नहीं बढ़ता?
क्योंकि जारी करना सबसे धीमे चरण से सीमित होता है। अतिरिक्त डेवलपर क्यूए के सामने की कतार बढ़ाते हैं, जो रिलीज की दर बढ़ाए बिना लागत बढ़ाता है।
क्या डेवलपर-से-परीक्षक अनुपात योजना बनाने के लिए काफी है?
यह एक शुरुआत है, पर उपयोगी तुलना क्षमता के मुकाबले उत्पादन की है। स्वचालन, आवश्यकताओं की गुणवत्ता और उत्पाद का प्रकार अनुपात को बहुत बदल सकते हैं।
देरी की लागत का अनुमान कैसे लगाया जाता है?
प्रतीक्षारत हर फीचर पर मासिक हानि के रूप में, खोए राजस्व, ग्राहक प्रतिधारण या भरोसे में। यह एक मान्यता है, इसलिए कम और ऊंचा दोनों आंकड़े परखें और देखें कि कौन हावी है।
अतिभार में दोष क्यों बढ़ते हैं?
जल्दबाजी में परीक्षक कुछ जांचें छोड़ देते हैं और दोबारा कम जांचते हैं। मॉडल इस अनुपात में निकले दोष जोड़ता है कि मांग क्षमता से कितनी अधिक है।
अतिरिक्त परीक्षक वाला परिदृश्य क्या दिखाता है?
यह एक और परीक्षक और स्वचालित रिग्रेशन का लाभ दिखाता है, जो क्यूए की क्षमता बढ़ाता है और आमतौर पर कतार साफ कर देता है। 24 महीनों वाला टैब दिखाता है कि यह कब वसूल होता है।
यह कितना सटीक है?
यह दिखाई गई मान्यताओं वाला एक शैक्षणिक योजना-मॉडल है, इंजीनियरिंग या वित्तीय सलाह नहीं। इनपुट की जगह अपने थ्रूपुट और लागत के आंकड़े डालें।
यह घोषित मान्यताओं पर आधारित एक शैक्षिक योजना मॉडल है। यह वित्तीय, कर संबंधी या कानूनी सलाह नहीं है। इनपुट की जगह अपने आँकड़े डालें और महत्वपूर्ण निर्णयों की पुष्टि किसी योग्य पेशेवर से कराएँ।