विरासत कोडबेस में अनुमानित समय लागत

Question

हाल ही में मैंने एक ऐसी परियोजना पर काम करना शुरू किया, जहाँ एक बहुत पुराने अखंड अनुप्रयोग को माइक्रो-सर्विस-आधारित वास्तुकला में माइग्रेट किया जा रहा है।

विरासत कोडबेस बहुत गन्दा है ('स्पेगेटी कोड') और अक्सर एक जाहिरा तौर पर सरल फ़ंक्शन (जैसे "मल्टीवैल्यू बाइटेन" के रूप में नामित) बाद में "3 अलग-अलग स्कीमाओं में 10 तालिकाओं के लिए सत्यापन कोड की हजारों लाइनें" के रूप में प्रकट होता है।

अब मेरा बॉस (सही है) मुझसे यह अनुमान लगाने के लिए कह रहा है कि नई वास्तुकला में फीचर एक्स को लिखने में कितना समय लगेगा। लेकिन मैं एक यथार्थवादी आकलन के साथ आने में कठिनाइयों का सामना कर रहा हूं; अक्सर मैंने ऊपर बताए गए कारणों के कारण कार्य को बहुत कम कर दिया है और अपने आप को शर्मिंदा करता हूं क्योंकि मैं समय पर समाप्त नहीं कर सकता।

समझदार बात वास्तव में कोड में मिल सकती है, प्रत्येक शाखा को नोट करें और अन्य कार्यों को कॉल करें और फिर समय की लागत का अनुमान लगाएं। लेकिन पुराने कोड के दस्तावेजीकरण और वास्तव में नए संस्करण को लिखने के बीच वास्तव में एक मामूली अंतर है।

मुझे इस तरह से परिदृश्य कैसे देखना चाहिए?

जबकि मैं पूरी तरह से समझता हूं कि विरासत कोड रीफैक्टरिंग कैसे काम करता है, मेरा सवाल "रिफैक्टर / पुनर्लेखन कैसे करना है?" लेकिन "एक्स / रिफैक्ट्री पार्ट एक्स को फिर से लिखने में कितना समय लगेगा?"

Comments

विस्तृत मार्जिन के साथ अनुमान लगाएं, एकल मूल्यों के साथ नहीं; उदाहरण के लिए 5 से 15 दिन

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

@JuniorDev: आपको क्यों लगता है कि यह "गैर-तकनीकी टीम लीडर के लिए अस्वीकार्य" है? वह आपके उत्तर को पसंद नहीं कर सकता है, लेकिन यदि आप कोई बेहतर अनुमान नहीं दे सकते हैं, तो यह अक्सर व्यक्ति को सीधे बताने के लिए होता है, बजाय उसे बहुत कम अनुमान के अब खुश करने की कोशिश करने और उसे 5 दिनों के बाद बताने के लिए, क्षमा करें, हमने केवल पूरा किया 30% करने के लिए कार्य।

— डॉक ब्राउन

"समझदार चीज़ वास्तव में कोड में मिल सकती है, प्रत्येक शाखा को नोट करें और अन्य कार्यों को कॉल करें और फिर समय की लागत का अनुमान लगाएं। लेकिन पुराने कोड को दस्तावेज करने और वास्तव में नए संस्करण को लिखने के बीच वास्तव में एक मामूली अंतर है।" - हाहहहहहहहहहहहहहहहहहहहहहहहहहहहहहहहहहहहह ha हे। तो, यह ऐसा प्रतीत हो सकता है, लेकिन जब आप कुछ विरासत कोड को साफ करते हैं, तो यह पता चलता है कि जिन मुद्दों को आपने कभी नहीं सोचा था उन मामलों में आपने कभी सुना नहीं था। या कहीं और बग पर पैच। या एक बग हैं, लेकिन बग्स जो कोड के अन्य भागों पर निर्भर हैं।

— याकूब

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

— corsiKa

6 से 8 सप्ताह , जैसा कि हम सभी जानते हैं।

— Matthieu M.

Answer 1

बॉब मार्टिन का "क्लीन कोडर" (और "क्लीन कोड" पढ़ें जब आप उस पर हों)। निम्नलिखित स्मृति से है, लेकिन मैं दृढ़ता से सुझाव देता हूं कि आप अपनी प्रति खरीदें।

आपको जो करने की आवश्यकता है, वह तीन बिंदु भारित औसत है। आप प्रत्येक कार्य के लिए तीन अनुमान लगाते हैं:

• सबसे अच्छा मामला परिदृश्य - सब कुछ सही होने पर (ए)
• सबसे खराब स्थिति - सब कुछ गलत हो जाना (बी)
• वास्तविक अनुमान - आपको क्या लगता है कि यह संभवतः लगेगा (सी)

आपका अनुमान तब (a + b + 2c) / 4 है

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

संपादित करें:

जब मैंने इसका उत्तर दिया तो मेरी धारणाएँ:

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

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

चलो एक काम किया उदाहरण:

• सबसे अच्छा मामला है, सबसे तेज़ अनुभव से मैंने वास्तव में एक सीधा किया है एक सप्ताह शुरू करने के लिए समाप्त (5 दिन)
• सबसे खराब स्थिति, अनुभव से, उस समय था कि हर जगह लिंक थे और यह मुझे 6 सप्ताह (30 दिन) तक समाप्त हो गया था
• वास्तविक अनुमान, यह शायद मुझे 2 सप्ताह (10 दिन) लगेगा

5 + 30 + 2x10 = 55

55/4 = 13.75 जो आप अपने पीएम को बताते हैं। हो सकता है कि आप 14 दिन तक राउंड अप करें। समय के साथ, (उदाहरण के लिए दस कार्य), इसे औसत करना चाहिए।

सूत्र को समायोजित करने से डरो मत। हो सकता है कि आधे काम बुरे सपने खत्म हों और केवल दस प्रतिशत ही आसान हों; इसलिए आप एस्टेमेट को ए / 10 + बी / 2 + 2 सी / 5 बनाते हैं। अपने अनुभव से सीखें।

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

Comments

"वे एक मूर्ख हैं - लेकिन मैं कुछ इस तरह से मिला हूं"। वास्तव में।

— क्रामि

मैं इसे उभारना चाहता हूं, लेकिन मैं एक बिंदु के अनुमान के पीछे नहीं जा सकता।

— रबरडैक

ठीक। आपके अंतिम बुलेट बिंदु के लिए +1।

— रबरडाक

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

— कैट

@mcottle FYI करें यह है नहीं एक मोंटे कार्लो अनुमान। आपने केवल PERT वितरण के लिए अपेक्षित मान (जो केवल 50% समय के आसपास सफल होगा) की गणना की है। मोंटे कार्लो एक ऐसी प्रक्रिया को संदर्भित करता है, जहां सांख्यिकीय मान एक यादृच्छिक संख्या जनरेटर के साथ जानवर बल के माध्यम से अनिवार्य रूप से प्राप्त होते हैं।

— डेविड मिस्टर

Answer 2

अर्ध-चुस्त दृष्टिकोण पेश करने के लिए यह एक अच्छा क्षण हो सकता है। यदि आप घंटों / दिनों के संदर्भ में अनुमान लगाने के बजाय एक प्रकार का पैमाना आवंटित करते हैं और प्रत्येक कार्य को कितना बड़ा है, इसके आधार पर मूल्य दिया जाता है:

• 0 - तुरंत
• 0.5 - त्वरित जीत
• 1 - साधारण परिवर्तन
• 2 - सरल परिवर्तन की एक जोड़ी
• 3 - अधिक चुनौतीपूर्ण
• 5 - के बारे में कुछ सोच की आवश्यकता होगी
• 8 - काम का एक महत्वपूर्ण राशि
• 13 - काम का एक बड़ा हिस्सा जिसे शायद टूटने की जरूरत है
• 20 - काम का एक बड़ा हिस्सा जो निश्चित रूप से टूट जाना चाहिए

फिर एक बार जब आप इस तरह के कार्यों का एक अनुमान लगाते हैं तो आप उन पर काम करते हैं। एक फुर्तीले वातावरण में आप 'वेग' विकसित करते हैं जो एक सप्ताह में आप कितने अंक प्राप्त करते हैं, कहते हैं। एक बार जब आप कुछ हफ्तों का परीक्षण कर चुके होते हैं और सीखते हैं (आप इस प्रक्रिया के हिस्से के रूप में अपने प्रबंधक को बेच सकते हैं - "मुझे कुछ हफ्तों के परीक्षण की आवश्यकता होगी और अनुमान प्रक्रिया को समझने के लिए सीखना होगा") आप होंगे प्रत्येक सप्ताह के माध्यम से आप कितने बिंदुओं पर जोर दे सकते हैं और इसलिए आप अधिक आसानी से अपने अनुमानों का अनुवाद कर सकते हैं।

https://pm.stackexchange.com/questions/4251/why-would-teams-use-the-fibonacci-sequence-for-story-points

https://stackoverflow.com/questions/9362286/why-is-the-fibonacci-series-used-in-agile-planning-poker

यह वास्तव में चुस्त नहीं है क्योंकि इसमें समारोहों में शामिल नहीं होंगे, लेकिन मुझे ओपी से विचार मिलता है कि वह अपने दम पर है। उम्मीद है कि यह दृष्टिकोण कुछ अधिक आत्मविश्वास का अनुमान दे सकता है।

Comments

यह बड़े पैमाने पर परियोजनाओं (एक महीने से अधिक) पर सबसे अच्छा काम करता है। छोटे पैमाने पर परियोजनाओं पर, यह केवल कुछ इसी तरह की परियोजनाओं के बाद काम कर सकता है।

— एमिल बर्जरॉन

@RobP। यह चुस्त कहानी बिंदु प्रगति में एक विचित्रता है: 13, 20, 40, 100 - हालांकि ज्यादातर लोग 20 से अधिक बिंदुओं को सेट करने से परेशान नहीं होते हैं, तब तक आपको वास्तव में इसे तोड़ने की आवश्यकता है

— HorusKol

मैं सहमत हूँ कि कहानी अंक + समारोह = फुर्तीली।

— webdevduck

@webdevduck "असहमत"?

— क्रिलगर

@ क्रिलर डी'ओह! असहमत!

— 14:33 पर webdevduck

Answer 3

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

फिर आप कुछ किताबें खरीदने जा रहे हैं।

1. सॉफ्टवेयर अनुमान: स्टीव मैककोनेल द्वारा ब्लैक आर्ट का प्रदर्शन
2. माइकल पंख द्वारा विरासत कोड के साथ प्रभावी ढंग से काम करना

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

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

अंत में, अपने बॉस को समझाएं कि कुछ समय के लिए चीजें थोड़ी अप्रत्याशित होने वाली हैं। कुछ वर्षों में, लेकिन वह विकास दैनिक आसान हो जाएगा और अनुमान अधिक सटीक हो जाएगा क्योंकि आपके पास अधिक डेटा होगा और कोड बेहतर हो जाएगा। यह कंपनी के लिए दीर्घकालिक निवेश है। मैं हाल ही में इस माध्यम से गया था, ज्यादातर अनुमानित होने में लगभग 2 साल लग गए।

मुझे पता है कि मैंने अनुमान लगाने की तुलना में कोड को बेहतर बनाने के बारे में अधिक बात की थी, लेकिन कठिन सच यह है कि आपके अनुमान तब तक घटिया होंगे जब तक आप विरासत कोड आधार को वश में नहीं कर सकते। इस बीच, ऐतिहासिक प्रदर्शन का उपयोग यह पता लगाने के लिए करें कि कितना समय लगेगा। समय बीतने के साथ, आप अपने अनुमानों में कल्पना करने के लिए कोड प्राप्त कर चुके हैं या नहीं, इस पर ध्यान देना चाहते हैं।

Comments

+1 के लिए "इसे एक परीक्षण दोहन में प्राप्त करें।" जब पुराने कोड को रिफलेक्ट किया जाता है, तो एक टेस्ट-फर्स्ट एप्रोच ( पुराने कोड के महत्वपूर्ण घटकों को सत्यापित करने के लिए ठीक उसी तरह जैसे आप सोचते हैं कि वे आपके कुछ भी करने से पहले करते हैं) अपराजेय है। इस उत्तर ने मुझे "सॉफ़्टवेयर अनुमान" पुस्तक खरीदने के लिए भी आश्वस्त किया, जो मैंने पहले कभी नहीं सुनी थी (मेरे अनुमान खराब हैं)।

— ग्लेनपेटर्सन

Answer 4

अब मेरा बॉस मुझसे सही अनुमान लगा रहा है कि नई वास्तुकला में फीचर एक्स को लिखने में कितना समय लगेगा। लेकिन मुझे यथार्थवादी आकलन के साथ आने वाली कठिनाइयों का सामना करना पड़ रहा है; कई बार मैं ऊपर बताए गए कारणों के कारण काम को कम आंकता हूं और खुद को शर्मिंदा करता हूं क्योंकि मैं समय पर खत्म नहीं कर सकता।

आप शायद एक अनुमान प्रस्तुत करने के बॉक्स में सोच रहे हैं । मुझे विरासत कोड में काम करना है, और जब मैं अधिक औपचारिक अनुमान लगाता हूं, तो मैं आमतौर पर दो या तीन बना देता हूं :

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

सभी तीन अनुमानों में यह ध्यान में रखा गया है कि यह सुविधा अपने आप में कितनी कठिन है, उस सामान्य कोड आधार के साथ मेरे पास कोई भी अनुभव है, और परिवर्तन के बारे में मेरा अनुभव (जो मुझे मिला है वह काफी सटीक हो सकता है)

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

Comments

अंतिम पैराग्राफ के लिए +1 - मेरी इच्छा है कि मैं अपने उत्तर में शामिल करूं

— mcottle

Answer 5

जब मैंने इस तरह की समस्या का सामना किया है, तो मैंने अपने अनुमानों पर सीमा देने पर भरोसा किया है। मैंने अपने आकाओं को यह कहकर दूर कर दिया है "इस कोडबेस पर अच्छा ऑफ-द-कफ अनुमान करना मुश्किल है। यदि आप एक के लिए पूछें, तो यह बहुत व्यापक अनुमान होगा।" मैंने एक बार अनुमान के रूप में "3 दिन से 3 साल" दिए हैं। कहने की ज़रूरत नहीं कि यह एक लोकप्रिय अनुमान नहीं था, लेकिन यह वही है जो मैंने दिया था।

इसके लिए एक समझौता है कि मैं अपने अनुमानों को अपडेट करूंगा क्योंकि काम आगे बढ़ेगा। तो अगर मुझे बताया गया "XYZ लागू करें, तो कितना समय लगेगा?" मेरा उत्तर "एक दिन और 4 महीने के बीच कहीं हो सकता है। हालांकि, अगर आप मुझे वास्तव में कुछ घंटों के लिए कोड को देखने देते हैं, तो मैं उस विंडो में अनिश्चितता को कम कर सकता हूं।" मैं फिर कोड देखता हूं और "2 से 4 सप्ताह" के साथ वापस आता हूं। यह अभी भी एक आदर्श खिड़की नहीं है, लेकिन कम से कम यह कुछ ऐसा है जिसे प्रबंधित किया जा सकता है।

इस के लिए कुछ चाबियाँ हैं:

• बॉस को समझाएं कि इन अनुमानों को बातचीत के रूप में बेहतर माना जाता है क्योंकि आप इस बारे में अधिक जानेंगे कि कार्य करते समय कैसा दिखता है। यह आपके बॉस के लिए एक मौका है कि वे जानकारी न लें यदि वे सिर्फ एक अनुमान के लिए नहीं कहते हैं।
• कैसे आगे बढ़ने के लिए विकल्पों की पेशकश करें जो व्यापार कोड विकास की गति बनाम अनुमानों में सुधार कर रहे हैं। उन्हें एक अतिरिक्त घुंडी दें जो वे मोड़ सकते हैं। कभी-कभी बॉस को पता होता है कि किसी कार्य को करने की आवश्यकता है, और उन्हें केवल एक बॉलपार्क अनुमान की आवश्यकता है। अन्य समय वे एक कार्य के पेशेवरों और विपक्षों को चला रहे हैं, और अनुमानों को परिष्कृत करने की क्षमता मूल्यवान है।
• यदि संभव हो, तो मैं तालमेल बोनस भी प्रदान करूंगा। अक्सर वास्तु सुधार होता है जिससे कई कार्यों को लाभ होगा। अगर मेरे पास 10 कार्य हैं जिनमें से सभी को "1-2 महीने अब लगते हैं, लेकिन अपग्रेड एक्स के साथ 2 सप्ताह लगेंगे," उन्नयन एक्स के लिए 20 सप्ताह बेचने में आसान है।

अगर मेरे पास एक बॉस है जो एक सीमा प्राप्त करने के साथ सहज नहीं है जिसे मैं जाते हुए अपडेट किया जाता हूं, तो मैं उन्हें एक ही नंबर और मेरी पद्धति दे दूँगा। मेरी कार्यप्रणाली अंगूठे के एक नियम का संयोजन है जिसे मुझे एक युवा डेवलपर और हॉफस्टार के नियम के रूप में बताया गया है ।

अनुमान करें कि आपको कितना समय लगता है कि कार्य करना चाहिए, फिर उस संख्या को चौगुना करें और अपने अनुमान के अनुसार दें।

तथा

हॉफस्टैटर का नियम: "जब आप हॉफस्टैटर के नियम को ध्यान में रखते हैं, तो यह हमेशा आपकी अपेक्षा से अधिक समय लेता है।"

Answer 6

समझदार बात वास्तव में कोड में मिल सकती है, प्रत्येक शाखा को नोट करें और अन्य कार्यों को कॉल करें और फिर समय की लागत का अनुमान लगाएं। लेकिन पुराने कोड के दस्तावेजीकरण और वास्तव में नए संस्करण को लिखने के बीच वास्तव में एक मामूली अंतर है।

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

मुझे पता है कि आपका बॉस एक अनुमान चाहता है, लेकिन यह जाने बिना कि इस जानकारी का उपयोग कैसे किया जा रहा है, हम नहीं जानते कि आपके अनुमानों का कितना सटीक होना आवश्यक है। उसके साथ बातचीत करें और पता करें। यदि उसे अपने मालिक को देने के लिए बस एक नंबर की आवश्यकता है, तो आप अनुमानों को थोड़ा बढ़ा सकते हैं और एक संख्या प्रदान कर सकते हैं। ऐसा होने तक आपके कोड का भुगतान करने के लिए इंतजार कर रहे ग्राहकों के लिए, सुनिश्चित करें कि आपको पता चल गया है कि हार्ड लाइन नियत तारीखों से महत्वपूर्ण राजस्व को चलाने जा रहे हैं।

Comments

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

— Thorbjørn रेवन एंडरसन

Answer 7

इस तरह की स्थिति में मुझे विश्वास नहीं है कि अच्छे अनुमान देना संभव है। मूल समस्या यह है कि अक्सर ऐसा करने का एक बड़ा हिस्सा यह पता लगाना है कि क्या करने की आवश्यकता है।

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

Answer 8

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

तकनीकी ऋण आपको अच्छी छोटी चुनौतियां देता है, लेकिन याद रखें कि एक कंपनी / टीम जिसने ऋण का उत्पादन किया था, तब तक कर्ज का उत्पादन जारी रहेगा, जब तक कि टीम की भावना या प्रबंधन में बदलाव न हो। कोड केवल सामाजिक समस्याओं को प्रतिबिंबित कर रहा है, इसलिए वास्तविक मुद्दों पर ध्यान केंद्रित करें।

हम एक ब्राउनफील्ड परियोजना में सुविधाओं आकलन के लिए एक शोध प्रणालियों का इस्तेमाल किया: हम अनुमान कितना समय के बिना एक ग्रीनफील्ड परियोजना में है कि सुविधा को लागू करने के लिए हो गया होता कुछ भी पहले से ही लागू किया। फिर हमने उस अनुमान को 2 से गुणा किया जो कि पहले से मौजूद मलबे की सफाई से संबंधित था।

यह कारक युग्मन की मात्रा और समग्र कोड आकार पर निर्भर करता है, लेकिन यदि आप इस तरह से कुछ विशेषताएं करते हैं, तो आप वास्तविक प्रमाण के आधार पर उस कारक को प्रक्षेपित कर सकते हैं।

Answer 9

मुझे लगता है कि आपको अपने बॉस के साथ बैठना चाहिए, उसे सीधे आंखों में देखें और कहें:

'सुनो बॉस! हम यहां सिर्फ रिफ्लेक्टर कर रहे हैं। वितरित करने के लिए कोई नई कार्यक्षमता नहीं है, और कोई भी ग्राहक उस कार्यक्षमता की प्रतीक्षा नहीं कर रहा है; इसलिए कोई समय सीमा नहीं होनी चाहिए। इसमें जितना समय लगेगा, आपको यह तय करना होगा कि हमें यह करना है या नहीं। '

इशारा करते हुए दृढ़ मुखर कीटनाशक का प्रयोग करें और अपनी कुर्सी पर आगे बैठें।

वैकल्पिक रूप से आप उसे खुश करने के लिए कुछ संख्याएँ बना सकते हैं। लेकिन इसका सामना तब तक करना चाहिए, जब तक कि आप नौकरी से आधा रास्ता निकाल लेते हैं, आपके अनुमान बहुत गलत हैं।

Comments

-1 संभावित कैरियर आत्महत्या की सिफारिश करने के लिए। इसके अलावा, ओपी का कहना है कि वह फीचर काम का अनुमान लगा रहा है, न कि केवल मौजूदा कोड को रीक्रिएट करने का।

— रबरडैक

कैरियर आत्महत्या या बड़े खेल के लिए छलांग बनाना

— इवान

खैर, यह एक उचित बिंदु @ इवान है। मैं यह नहीं कह सकता कि मैंने कुछ ऐसी चीजें नहीं की हैं जो पल में करियर आत्महत्या की तरह लग रही थीं।

— रबरडैक

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

— GlenPeterson

गाल जवाब में अपनी जीभ। लेकिन मेरा मतलब है कि यह एक गंभीर तरीके से है। बॉस अनुमान क्यों लगा रहा है? क्या आप स्थिति का आकलन करके मदद कर रहे हैं? यह सब बहुत अच्छी तरह से इस 'चाचा बॉब पढ़ें' 'फिबोनाची अनुक्रम' शैली जवाब का उपयोग करें। लेकिन वे समस्या की जड़ तक नहीं पहुंचे। बॉस चिंतित है कि यह रिफैक्टिंग समय की बर्बादी है और यह जल्द ही खत्म हो जाना चाहता है

— इवान