व्यवहार में निन्यानबे नियम

Question

कोड का पहला 90 प्रतिशत विकास के समय के पहले 90 प्रतिशत के लिए होता है। शेष 10 प्रतिशत कोड अन्य विकास के समय के 90 प्रतिशत के लिए जिम्मेदार है।

- टॉम कारगिल, बेल लैब्स

व्यवहार में वास्तव में इसका क्या मतलब है? वे प्रोग्रामर पर्याप्त मात्रा में काम करते हैं और वे 180% खुद से दे रहे हैं या?

Comments

हम सभी जानते हैं कि या तो 100% से अधिक को पुनर्परिभाषित किया जाता है, या यह कि यह ज्ञात राशि का 1.8 गुना है। इस मामले में, मैं कहूंगा कि यह शायद अतिशयोक्ति है। दूसरा नब्बे प्रतिशत इसे यादगार बनाने के लिए है, और उद्धरण के अंत में एक पंच-रेखा जोड़ें।

— AJFaraday

वाक्य के बीच में विकास के समय का अनुमान बदल जाता है।

— मिलेनियमबग

180% समय की राशि है और बजट में लागत समाप्त होती है।

— Agent_L

मुझे लगता है कि यह बिल्कुल स्पष्ट है कि यह प्रश्न अजीब अंतिम वाक्य के बावजूद क्या पूछ रहा है।

— मैथ्यू जेम्स ब्रिग्स

इस उद्धरण को एक मजाक के रूप में पढ़ा जाना चाहिए, इस संदर्भ में यह समझ में आता है। यह कह रहा है कि अंतिम 10% आपको कल्पना से अधिक समय लगेगा

— रिचर्ड टिंगल

Answer 1

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

समस्या यह है कि अधिकांश डेवलपर्स सॉफ़्टवेयर को "लगभग पूर्ण" स्थिति में प्राप्त करने का अनुमान लगाते हैं, क्योंकि सॉफ्टवेयर वास्तव में कुल प्रयास का अनुमान लगाने की तुलना में अपेक्षाकृत सरल है।

Comments

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

— रम्बलवीड

+1 लेकिन मुझे लगता है कि दूसरे पैराग्राफ को कुछ बोल्ड टेक्स्ट की ज़रूरत है क्योंकि यह पाठ का वास्तव में महत्वपूर्ण हिस्सा है :)

— बॉब Tway

Answer 2

यह एक सामान्य परिदृश्य का संदर्भ है, जो आज भी दुख की बात है:

1. टीम को सभी कोड लिखने के लिए आवश्यक कार्य की मात्रा (यानी अनुमान) के लिए कहा जाता है,
2. परियोजना "समय और बजट पर रहने" के लिए कई आंतरिक और बाहरी दबावों के साथ आगे बढ़ती है,
3. तो परियोजना के एक महत्वपूर्ण प्रतिशत के लिए, "लक्ष्य पर" सूचित किया जाता है। अच्छी प्रगति सुनिश्चित करने के लिए पहले आसान कार्यों को उठाकर इसे अक्सर जटिल बना दिया जाता है।
4. फिर किसी स्तर पर, एक महत्वपूर्ण बिंदु पर पहुंच जाता है जहां वास्तविकता को स्वीकार करना पड़ता है: परियोजना समय पर पूरी नहीं होगी और रिलीज की तारीख को पीछे धकेल दिया जाता है (अक्सर कई बार)।

"90%" एक मनमाना आंकड़ा है, लेकिन यह अच्छी तरह से बात करता है: अनुमान अनुमान हैं और संभवतः गलत (अक्सर बहुत गलत) होंगे और मानव स्वभाव हमें अनुमान के तहत लगभग हमेशा सुनिश्चित करता है, इसलिए चीजें आगे निकल जाती हैं।

Comments

जिसे "फुर्तीली" कहा जा रहा है वह समस्या को हल करने के लिए कुछ भी नहीं करता है; यह बस इसे छोटी वस्तुओं के बीच वितरित करता है, जहां बिल्कुल समान अनुपात छोटे निरपेक्ष पैमाने पर होता है, भले ही कारगिल मुखर हो रहा हो। लब्बोलुआब यह है कि प्रत्येक परियोजना में कुछ छोटी-छोटी चीजें होती हैं जो विकास के बहुत से समय को पूरा करती हैं।

— ११:०५ पर ब्लरफ्ल Bl

@ ब्लर उत्तर का अर्थ यह नहीं है कि चुस्त अनुमान के कठिन होने की समस्या को हल करता है, लेकिन यह छोटे अनुमान लगाकर इसके परिणामों को कम करता है।

— एरिक

यह केवल एक संसाधन प्रबंधन मुद्दा नहीं है जो मुझे लगता है। किसी प्रोजेक्ट के 90% तक त्वरित और गंदे प्रोटोटाइप के लिए यह बहुत आसान है, लेकिन शेष 10% में बहुत समय लगेगा, क्योंकि यह अक्सर यहां है कि हम प्रारंभिक आवश्यकताओं के साथ पूरी तरह से अनुपालन करने के बारे में परवाह करते हैं। मैं एम्बेडेड सिस्टम में हूँ और मैं उत्पाद रिलीज़ होने से महीनों पहले सेल्स मैन को एक उत्पाद का डेमो दे सकता हूँ, और वह डेमो और अंतिम उत्पाद के बीच लगभग कोई अंतर नहीं देखेगा, लेकिन यह सुनिश्चित करने के लिए कि डेमो shippable नहीं है। कीड़े, अनुकूलन, उन्नत सुविधाएँ, बिजली की खपत, वह हैother 90%

— टिम

मुझे विश्वास है कि चुस्त साथ भी पंखा मारता है और उड़ जाता है!

— 15

चुस्त के बारे में बाद में हटा दिया क्योंकि यह स्पष्ट रूप से जवाब के मुख्य बिंदु से लोक विचलित है।

— डेविड अरनो

Answer 3

मैंने इसका एक अलग संस्करण सुना है (इसे "90-90 नियम" भी कहा जाता है) जो इस प्रकार है:

मैंने 90% कार्यशीलता को लागू करने के बाद, मुझे अभी भी अन्य 90% को लागू करना है ।

दोनों संस्करण सॉफ्टवेयर उत्पादों को विकसित करने के लिए सही ढंग से अनुमान लगाने की कठिनाई का उल्लेख करते हैं और उन सामान्य नुकसानों के बारे में बताते हैं जिन्हें लोग देखते हैं:

• आँकड़ों को वहाँ फेंकना जब अनुमान लगाना आवश्यक हो और अनिवार्य रूप से अनुमान लगा रहे हों ("मैं 80% हो चुका हूँ")
• काम की मात्रा की गिरावट पर (सामान्य कार्यों के लिए आवश्यक प्रयास को कम करके) कोड की एल्गोरिथम जटिलता पर ध्यान दिया जाना चाहिए
• लापता कदम ("दृष्टि से बाहर, दिमाग से बाहर")
• मौजूदा कोड को बनाए रखने और बदलने के लिए प्रयास को कम करके आंका
• बॉयलरप्लेट / "गोंद" कोड के लिए आवश्यक प्रयास को कम करके आंका

Answer 4

यह नियम 80-20 नियम का अनुपालन करता है। अब, 80-20 नियम की कई अलग-अलग व्याख्याएं हैं, लेकिन दो मुझे सबसे ज्यादा पसंद हैं:

1. पहले 80% उत्पाद विकास में 20% प्रयास लगते हैं।
2. 20% कोड में 80% त्रुटियां हैं।

व्यवहार में, इसका मतलब निम्नलिखित है: विकास शुरू होगा और कुछ निश्चित बिंदु तक आगे बढ़ेगा जब पहली देरी पर ध्यान दिया जाएगा। देरी विभिन्न प्रकृति की हो सकती है:

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

लब्बोलुआब यह है कि वास्तव में उस तक पहुंचने की तुलना में लक्ष्य के करीब आना बहुत आसान है।

Comments

80-20 नियम के रूप में भी जाना जाता है en.wikipedia.org/wiki/Pareto_principle

— पीटर एम - मोनिका के लिए खड़ा है

Answer 5

मुझे विकिपीडिया स्पष्टीकरण काफी ज्ञानवर्धक लगता है:

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

Answer 6

व्यवहार में वास्तव में इसका क्या मतलब है? वे प्रोग्रामर काम की मात्रात्मक हैं और वे 180% खुद से दे रहे हैं या?

नहीं, प्रोग्रामर हमेशा समय की प्रति यूनिट के बराबर काम करते हैं। उद्धरण कम-अनुमानित लागत और ओवररन के बारे में है। 180% परियोजना की लागत समाप्त होने के समय और धन की राशि है।

मोटे तौर पर इसका मतलब है "जब तक आप सोचते हैं, तब तक यह आपको दो बार ले जाएगा" और "आपको लगता है कि आप अच्छा कर रहे हैं जब तक कि पहले से ही बहुत देर हो चुकी है (समय सीमा निकट है)"।

Answer 7

व्यवहार में इसका मतलब यह है कि लोग खुद से झूठ बोलते हैं।

यदि एक प्रोग्रामर कहता है "हम 90% काम कर रहे हैं" तो इसका मतलब है कि सुविधाओं के निर्माण के प्रयास का 90% खर्च किया गया है।

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

अंतर यह है कि एक परियोजना को खत्म करने के लिए कोडिंग सुविधाओं की तुलना में अधिक प्रयास होता है: क्यूए, बग फिक्स, कॉपी एडिट्स, परिनियोजन।

उन चीजों को परियोजना में प्रबंधित करने की आवश्यकता है, और परियोजना प्रबंधक की जिम्मेदारी है। यह अक्सर नए पीएम को आश्चर्यचकित करता है जो केवल "90% फ़ीचर पूरा" करने के लिए तट को महसूस करते हैं कि वे "किए गए प्रोजेक्ट" के लिए केवल आधे रास्ते पर हैं।