एक डेवलपर को एक्सेल मैक्रो द्वारा किए गए कार्यभार के आकलन को स्वीकार करना चाहिए?

Question

एक नए प्रोजेक्ट में, एक मित्र को परीक्षण लिखना था जहां उन्हें लिखने के लिए आवश्यक समय की गणना उनके गैर-डेवलपर प्रबंधक द्वारा लिखित एक्सेल मैक्रो द्वारा की गई थी।

ऐसी परिस्थितियों में, क्या एक डेवलपर को परिकलित समय में परीक्षण लिखने और चलाने की जिम्मेदारी स्वीकार करनी चाहिए? क्या इन परीक्षाओं के परिणाम भरोसेमंद हैं?

जानकारी के लिए, मेरे दोस्त ने अपने द्वारा किए गए अनुमानों के लिए जिम्मेदार होने से इनकार कर दिया, एक अन्य परियोजना पर काम करने के लिए सफल होने के लिए कहा, और एक अनुभवहीन आउट-ऑफ-स्कूल हां-आदमी द्वारा प्रतिस्थापित किया गया है।

Comments

"अनुमान" को "स्वीकार" करने का क्या अर्थ है? यदि आप अनुमान लगाते हैं कि मुझे कुछ करने में 30 दिन लगेंगे, तो क्या होगा अगर मैं इसे "स्वीकार" करूँ? मुझे क्या परवाह है कि आप कब तक यह अनुमान लगाते हैं कि यह मुझे कुछ करने के लिए ले जाएगा? आप अनुमान लगा सकते हैं कि मैं एक मिनट में यह सब करूंगा जो मुझे परवाह है, आप गलत होंगे , मैं नहीं।

— डेविड श्वार्ट्ज

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

— थॉमस ओवेन्स

कुछ ऐसा लगता है जिसे दिलबर्ट कार्टून के लिए स्कॉट एडम्स को भेजा जाना चाहिए।

— मेटलमेस्टर

जब तक समीक्षा होती है। मैं इस विशेष उदाहरण वहाँ कोई नहीं थे।

— नेलस्टार

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

— 14

Answer 1

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

आदर्श रूप में, उसे अपने प्रबंधक के साथ चर्चा करनी चाहिए कि किसी से किसी अन्य व्यक्ति द्वारा अनुमानित कार्य की जिम्मेदारी लेने और उसके लिए जिम्मेदारी लेने की उम्मीद नहीं की जा सकती।

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

Answer 2

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

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

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

Comments

परीक्षणों को उप-उप-भागों (लगभग परमाणु) में कटा हुआ है और एक छोटे से अनुमान लगाया जाता है।

— नेलस्टार

मुझे लगता है कि इस पद्धति का उपयोग करके अंतिम परीक्षक बड़ी तस्वीर को नहीं देखता / परीक्षण करता है।

— नेलस्टार

"संभवतः मैक्रो किसी प्रकार के इनपुट डेटा पर काम कर रहा है, यह सिर्फ एक यादृच्छिक संख्या जनरेटर नहीं है" यह यादृच्छिक भी हो सकता है क्योंकि उनके पास हर तरह के चर को पकड़ने का कोई तरीका नहीं है जो इस तरह के एल्गोरिदम को सटीक बना देगा।

— maple_shaft

@maple_shaft: इसलिए वे इसे एक अनुमान कहते हैं - यह सटीक होने की उम्मीद नहीं है (या नहीं होना चाहिए)। चाहे आप एक्सेल में कुछ गणनाओं का उपयोग करके अनुमान लगाते हैं, या पेंसिल और कागज के साथ, कोई फर्क नहीं पड़ता है। अनुमानों के लिए एक्सेल का उपयोग करना कुछ अन्य 'तकनीकों' की तुलना में अधिक समझ में आता है जो मैंने उपयोग में देखा है ...

— Treb

@Treb अनुमान प्रदान किए गए डेटा के रूप में सटीक होना चाहिए और मौजूदा परियोजना की स्थिति, अनिश्चितता की शंका को देखते हुए अनुमति देता है।

— थॉमस ओवेन्स

Answer 3

निश्चित रूप से नहीं।

एक छोटा सा कार्यक्रम, यहां तक ​​कि एक बड़ा, जटिल कार्यक्रम, संभवतः अनुमान नहीं लगा सकता है कि किसी भी प्रोग्रामिंग नौकरी में कितना समय लगेगा। क्यों कारणों के लिए सॉफ्टवेयर आकलन के लिए गणितीय सीमाएं देखें । एक लंबे समय तक, सहकर्मी की समीक्षा की गई पेपर, बड़ी सीमा से सॉफ़्टवेयर अनुमान तक भी उपलब्ध है।

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

Comments

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

— थॉमस ओवेन्स

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

— डंक

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

— ब्रूस एडिगर

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

— डंक

मैंने कल रात वो पेपर पढ़े। वे परियोजना प्रबंधन में 40 से अधिक वर्षों के साक्ष्य और सॉफ्टवेयर परियोजना प्रबंधन में 30 से अधिक वर्षों के सबूतों के खिलाफ जाते हैं। देखें iiasa.ac.at/Admin/PUB/Documents/RM-75-071.pdf और sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html

— थॉमस ओवेन्स

Answer 4

ओह!

यह एक विशाल "नौकरी की गंध" है। यह अविश्वसनीय सूक्ष्म प्रबंधन है।

यदि वे अपने कर्मचारियों को एक अनुमान देने के लिए भरोसा नहीं कर सकते हैं, तो वे आपके साथ और क्या भरोसा नहीं करते हैं?

Comments

99% डेवलपर्स किसी भी उद्देश्य के आधार पर खराब अनुमानों के साथ नहीं आ सकते हैं, अकेले सटीक अनुमान लगाते हैं। इसलिए मुझे "नौकरी की गंध" का संकेत देने के लिए कुछ भी नहीं दिख रहा है क्योंकि कोई और व्यक्ति अनुमान लगा रहा है। विशेष रूप से अगर वे अपनी संख्या को सही ठहराने के लिए वास्तविक डेटा का उपयोग करते हैं। अगर लोगों को हर कार्य का अनुमान पूरा करने के लिए जवाबदेह ठहराया जाता है तो यह एक नौकरी की गंध का मुद्दा है। हालांकि, यदि उपकरण ने सभी कार्यों को बहुत कम करके आंका है, तो सभी डेवलपर्स अनुमान गायब होंगे। OTOH, अगर बाकी सभी अनुमानों को पूरा करता हुआ लगता है और दूसरा डेवलपर कभी ऐसा नहीं करता है, तो यह एक डेवलपर गंध है।

— डंके

@ डंक - मेरी बात यह है कि, विकासशील सॉफ्टवेयर में इस डिग्री के लिए सूक्ष्म प्रबंधन एक "नौकरी की गंध" है और मैं वहां काम नहीं करना चाहूंगा।

— 13

जिसे आप micromanagement कहते हैं, वह कई उद्योगों में व्यापार करने का एकमात्र तरीका है। यदि आप बड़ी परियोजनाओं के लिए उचित लागत और शेड्यूल अनुमान के साथ नहीं आ सकते हैं, तो आपकी कंपनी को अनुबंध प्राप्त करने में बहुत मुश्किल काम होगा। फुर्तीले-आदर्श के विपरीत, कई उद्योगों में ग्राहक लाखों डॉलर के अनुबंधों के दसियों के लिए प्रतिबद्ध नहीं हैं, अगर उन्हें नहीं पता है कि वे अंत में क्या प्राप्त करेंगे। वे इस विचार से खुश नहीं होंगे कि उनका पैसा चला गया है, उनके पास एक काम करने वाला उत्पाद है, लेकिन यह केवल 50% है जो उन्हें चाहिए या चाहिए।

— डंक '

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

— ozz

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

— डंक

Answer 5

बिलकुल नहीं।

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

वास्तव में यहां क्या हो रहा है प्रबंधक इस कथित एक्सेल मैक्रो का उपयोग इस तथ्य को छिपाने के लिए एक पतले पर्दा प्रच्छन्न के रूप में कर रहा है कि वह अपने डेवलपर्स पर अवास्तविक उम्मीदों और अनुचित दबाव के लिए मजबूर कर रहा है।

वह जानता है कि यह बीएस है और परवाह नहीं करता है, यह संसाधनों को ओवरबुक करने का एक बहाना है और अपने सभी "बेकार" डेवलपर्स को हमेशा के लिए "लेट" बनाकर चीजों को तेजी से प्राप्त करने का प्रयास करना है।

यह प्रबंधक एक शोषणकारी झटका लगता है।

Comments

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

— rjzii

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

— मेपल_शॉफ्ट।

यहां समस्या यह थी कि ये अनुमान सीधे ग्राहक के चालान में थे। कुछ प्रबंधक इसे अनुमानित क्यों कहते रहते हैं?

— नेलस्टार

@maple_shaft - यह जानने के बिना कि अनुमान क्या हैं, यह कहना मुश्किल है कि क्या वे अनुचित थे और इसलिए उन पर आपत्ति जताई जानी वैध थी। यदि वे उचित अनुमान थे (यानी "हैलो वर्ल्ड लिखने के लिए आठ घंटे") तो दर्शन से परे उन्हें आयोजित करने में कोई समस्या नहीं है।

— rjzii

Answer 6

एक नए प्रोजेक्ट में, एक मित्र को परीक्षण लिखना था जहां उन्हें लिखने के लिए आवश्यक समय की गणना उनके गैर-डेवलपर प्रबंधक द्वारा लिखित एक्सेल मैक्रो द्वारा की गई थी।

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

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

ऐसी परिस्थितियों में, क्या एक डेवलपर को परिकलित समय में परीक्षण लिखने और चलाने की जिम्मेदारी स्वीकार करनी चाहिए?

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

क्या इन परीक्षाओं के परिणाम भरोसेमंद हैं?

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

Answer 7

लगता है जैसे आप दो अलग सवाल पूछ रहे हैं:

क्या इन परीक्षाओं के परिणाम भरोसेमंद हैं?

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

ऐसी परिस्थितियों में, क्या एक डेवलपर को परिकलित समय में परीक्षण लिखने और चलाने की जिम्मेदारी स्वीकार करनी चाहिए?

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

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

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

Comments

मैं मानता हूं कि इस पद्धति का उपयोग तब तक किया जा सकता है जब तक कि परियोजना के अभिनेताओं के बीच एक संवाद हो।

— नेल्स्टार

@ नेलस्टार - परियोजना प्रबंधन और अनुमान पर मैंने जो कुछ भी पढ़ा है उसमें बहुत कुछ शामिल है जैसे समय चल रहा है एक संवाद और ट्यूनिंग चीजें शामिल हैं। आमतौर पर सबसे अधिक विश्वसनीय अनुमानों में संकेत से टकराने के संकेत (यानी 8 घंटे लगने वाले कार्य का 90% मौका) के संबंध में उनके साथ जुड़ी एक संभावना है।

— rjzii

Answer 8

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

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

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

Comments

अनुमानों के संबंध में कार्यों के माध्यम से काम करते हुए प्रतिक्रिया देने के लिए +1।

— rjzii

Answer 9

आसान और छोटा जवाब:

आप परवाह नहीं करते हैं कि अनुमान कहाँ से आ रहा है।

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

Comments

आपको ध्यान रखना चाहिए कि अनुमान कहाँ से आ रहा है। वैध और उचित इनपुट के साथ एक पैरामीट्रिक मॉडल, एक यादृच्छिक संख्या जनरेटर, एक प्रथम वर्ष के कंप्यूटर विज्ञान के छात्र, 5 साल के अनुभव के साथ एक सॉफ्टवेयर इंजीनियर, जो डोमेन में 6 महीने से कम का अनुभव है, और एक सॉफ्टवेयर इंजीनियर 25 साल के अनुभव के साथ परियोजना प्रबंधक बन गया है डोमेन में सभी एक प्रभावी अनुमान लगाने के लिए एक अलग क्षमता है। यह भी एक टिप्पणी मैं एक सॉफ्टवेयर इंजीनियर का प्रतिनिधित्व करने के लिए नैतिक / व्यावसायिक जिम्मेदारी के बारे में पिछले जवाब पर किया था का प्रतिनिधित्व करता है, बचाव, और उचित रूप से अनुमानों को चुनौती।

— थॉमस ओवेन्स

बिल्कुल सही: अनुमान पर चर्चा करने के लिए सबसे महत्वपूर्ण है। मुझे खुशी से एक्सेल मैक्रोज़ का उपयोग करना मंजूर होगा अगर यह अनुमान लगाया जाए कि 25 साल के अनुभव इंजीनियर की तुलना में अधिक बार सही थे। जो महत्वपूर्ण है वह अनुमान है, और यह व्याख्या जो इसे आगे बढ़ाती है (कार्यभार, लाभ संसाधन, कठिनाई), यह नहीं कि किसने या क्या घोषणा की थी।

— क्लेमेंट हेरमैन 14

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

— थॉमस ओवेन्स

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

— क्लेमेंट हेरमैन 15

आप सटीकता का निर्धारण कैसे करते हैं यदि आप नहीं जानते कि कौन अनुमान लगाता है और उन्होंने किन विधियों का उपयोग किया है? मैं दो लोगों को एक ही डेटा दे सकता हूं - एक प्रथम वर्ष का सॉफ्टवेयर इंजीनियरिंग छात्र है जो वर्तमान में अपना पहला कंप्यूटर विज्ञान पाठ्यक्रम ले रहा है और दूसरा 15 साल के अनुभव और डोमेन में 5 के साथ एक वरिष्ठ सॉफ्टवेयर इंजीनियर है। दोनों समान अनुमान विधियों का उपयोग करते हैं (मत भूलो - अक्सर, इनपुट अनुमान के अनुसार भी होते हैं)। छात्र कह सकते हैं कि 95% आत्मविश्वास के साथ 6 महीने लगेंगे। वरिष्ठ इंजीनियर कह सकते हैं कि 80% आत्मविश्वास के साथ 15 महीने लगेंगे। मुझे सीनियर इंजीनियर पर ज्यादा भरोसा है।

— थॉमस ओवेन्स

Answer 10

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

लोग आम तौर पर प्रोग्रामिंग समय आकलन भी अपने आप में प्रोग्रामिंग की तुलना में कठिन लगता है, इसलिए यदि आपके प्रबंधक एक एक्सेल मैक्रो लिख सकते हैं हल कर सकते हैं कि समस्या, वह शायद किसी मैक्रो कोड (संभावना नहीं) लिखने के लिए निर्माण कर सकते हैं।

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

Answer 11

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

मैं निश्चित रूप से NO । इसलिये:

1. एक गैर-डेवलपर प्रबंधक नौकरी करने के लिए आवश्यक समय का अनुमान नहीं लगा सकता है
2. किसी भी काम को करने के लिए आवश्यक समय का अनुमान लगाने के लिए कुछ मानवीय बुद्धि की आवश्यकता होती है, जो एक्सेल के पास नहीं है
3. इस तरह के काम करने के तरीकों को स्वीकार करके, प्रबंधक उत्तरोत्तर समय में डेवलपर्स को बदलने के लिए उपयोग किया जाता है। इससे तबाही हो सकती है। इस परिदृश्य पर विचार करें जिसमें आपका प्रबंधक कहता है:

मैं ऑनलाइन साइकिल बेचने के लिए एक नई परियोजना शुरू करना चाहता हूं और मुझे पता है कि इसे पूरा करने में आपको और जॉन को 3 सप्ताह का समय लगता है।

Comments

ओपी के पास फुर्तीले तरीकों का उपयोग करके अपने दोस्त की टीम का कोई उल्लेख नहीं है। मुझे नहीं लगता कि चुस्त नियमों का अन्य विधियों (या बिल्कुल भी कोई विधि) का उपयोग करने वाली टीमों के लिए कोई प्रासंगिकता नहीं है। सामान्य ज्ञान, हालांकि :-) इसके अलावा, यह स्पष्ट है कि यह एक्सेल नहीं था जिसने अनुमानों के बारे में फैसला किया था, इसने केवल कुछ (हमारे लिए अज्ञात) मान्यताओं और डेटा के आधार पर कुछ गणना निष्पादित की (जिनमें से प्रत्येक सही या गलत हो सकती है) । यदि हम अपनी टीम के प्रत्येक सदस्य द्वारा दिए गए कार्य के लिए अनुमान दर्ज करते हैं, तो इनमें से औसत की गणना करने के लिए Excel सेट करें, क्या एक्सेल अनुमान लगा रहा है?

— पेटर टॉर्क

1 और 2 स्पष्ट रूप से झूठे हैं। सॉफ्टवेयर प्रोजेक्ट प्रबंधन में पैरामीट्रिक आकलन मॉडल व्यापक रूप से स्वीकार किए जाते हैं और 20 साल से अधिक समय से हैं, और परियोजना प्रबंधन प्रशिक्षण (सॉफ्टवेयर इंजीनियर या नहीं) के साथ किसी को भी इन उपकरणों का उपयोग करने के लिए प्रशिक्षित किया जा सकता है, यह मानते हुए कि वे (या, अधिमानतः, प्रोजेक्ट इंजीनियर) ) आदानों का सटीक अनुमान प्रदान करने में सक्षम हैं।

— थॉमस ओवेन्स

-1 - यह प्रश्न का उत्तर नहीं देता है, इसमें स्पष्ट त्रुटियां हैं ("... नवीनतम सॉफ़्टवेयर डेवलपमेंट मेथोडोलॉजीज़ फुर्तीली हैं"), और प्रासंगिकता के कुछ भी जोड़ने के लिए प्रकट नहीं होता है। मुझे यकीन नहीं है कि upvotes या स्वीकृत उत्तर किस लिए थे।

— मॉर्गन हर्लॉकर

हम निश्चित रूप से इस सवाल से नहीं जानते हैं कि क्या पैरामीट्रिक अनुमान इस कंपनी का आदर्श है और / या यदि यह उनके व्यवसाय के लिए एक अच्छे इतिहास पर आधारित है; अगर ऐसा नहीं है, जितना कि मुझे यह कहने से नफरत है, तो संगठन की स्वीकृत संचालन प्रक्रियाओं के अनुसार किसी का काम करने से इनकार करना (बिना किसी उचित प्रश्न के पथ का अनुसरण करना) अनुचित है।

— स्टीवनवी

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

— 15