बेहतर अनुमान लगाने के लिए कैसे सीखें? [बन्द है]


42

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

मैं बेहतर अनुमान लगाना कैसे सीख सकता हूं? यह मेरी यूनी में नहीं सिखाया गया है, और भले ही हमारे पास सभी परिश्रमों की समय सीमा हो, लेकिन मैं कभी नहीं सोचता कि वास्तव में कुछ कितना समय लगेगा। जो मुझे चाहिए। हर किसी के लिए (विशेष रूप से मेरा)।



जवाबों:


28

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

मुझे लगता है कि यह एक अनुभव की बात है और कुछ भी नहीं है।


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

3
यह एक बेहतरीन जवाब है। मैं यह जोड़ना चाहूंगा कि आपके अनुमानों के नोट्स लेने के अलावा, यह किसी प्रकार का "डे-स्लॉग" लिखने में मददगार हो सकता है, जहाँ आप महत्वपूर्ण निर्णयों, समस्याओं का सामना करते हैं और हल किए जाते हैं, आदि। यदि कोई अनुमान निकलता है। 50% या उससे अधिक होने के लिए, फिर यह जांचने के लिए उपयोगी हो सकता है कि क्यों, और फिर ये "दिन" बहुत मदद करेंगे (इस पर अधिक विवरण के लिए "द प्रोगामेटिक प्रोग्रामर" में पेज 64-69 देखें)। इसके अलावा, सावधान रहें कि आप अपना नंबर किसको दिखाते हैं; जो लोग समझ नहीं पा रहे हैं कि आप क्या कर रहे हैं, वे आपके खिलाफ इस्तेमाल करने की कोशिश कर सकते हैं।
लीफ

मैं वही करता हूं जो आप करते हैं - मैन्युअल रूप से। यह मूल रूप से एविडेंस बेस्ड शेड्यूलिंग ( en.wikipedia.org/wiki/Evidence-based_Scheduling ) है, जोएल द्वारा बीड़ा उठाया गया है और fogcreek.com/fogbugz
Mawg

18

समय प्रबंधन की मर्फी की विधि: पता लगाने के लिए कितनी देर तक कुछ होगा ले, बाहर कितना समय आंकड़ा चाहिए लेने के लिए और यह दोगुनी हो।

फिर, समय की अगली उच्च इकाई तक बढ़ें। इस प्रकार, हम एक दिन की परियोजना के लिए दो सप्ताह आवंटित करते हैं।


2
मुझे यह कहने से नफरत है, लेकिन यह शायद सबसे सरल और सबसे प्रभावी मीट्रिक है जिसे मैंने यहां देखा है।
glenatron

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

9

आप उन्हें सामूहिक रूप से करके सीख सकते हैं ।

मैं प्लानिंग पोकर का उपयोग करता हूं । यह अनुमान लगाने की सर्वसम्मति-आधारित तकनीक है।

आपके अनुमान को ट्रैक किया जाना चाहिए और इसकी तुलना में कि आपने क्या प्रभावी ढंग से किया है। आपको वेग मिलेगा ।

हर बार जब आप कुछ अनुमान लगाते हैं, तो सटीक अनुमान प्राप्त करने के लिए अपने हाल के वेग से गुणा करें ।


पोकर बात वास्तव में दिलचस्प लगती है, क्या आप वास्तव में इस IRL को अपने लिंक में वर्णित करते हैं? क्या इससे आपको अधिक सटीक अनुमान बनाने में मदद मिली?
हेंनिबल लेक्चरर

हाँ। यह बात अनुमान को मजेदार बनाती है! और गंभीरता से सटीक। बेशक, आपको थोड़ा अभ्यास करना होगा, लेकिन एक बार जब आप इसे प्राप्त कर लेंगे, तो आप अन्य तरीकों से अनुमान नहीं लगा सकते।

यह वास्तव में मजेदार लगता है! :) बुरा करने के लिए मैं अपनी कंपनी में इसे कभी नहीं बेच पाऊंगा: - /
dr हैनिबल लेक्टर

@ डॉ। हन्नीबल लेक्चरर: पालतू जानवरों की दुकान की चाल का उपयोग करें। उन्हें बताएं कि यह निश्चित नहीं है, कि आप इसका इस्तेमाल सिर्फ इसका परीक्षण करने के लिए करेंगे। मेरा विश्वास करो, यह निश्चित होगा;)

9

स्टीव मैककोनेल (एमएस प्रेस) द्वारा सॉफ्टवेयर अनुमान एक अच्छा पढ़ा गया है।

सॉफ्टवेयर अनुमान के साथ मुख्य बात निम्नलिखित द्वारा संक्षेपित है

ऐतिहासिक जानकारी के बिना, आपके अनुमान बेकार हैं।

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

ध्यान रखने के लिए कुछ अन्य बिंदु:

  1. यह केवल धीमी हो जाएगी । 80/20 नियम को लागू करने का मतलब है कि कठिन परिश्रम बाद में आएगा जब तक कि आपका परियोजना प्रबंधन बहुत अनुशासित न हो।
  2. अनुमान! = योजना। अनुमान कुछ प्राप्त करने के लिए आवश्यक प्रयास का अनुमान लगाने की प्रक्रिया है। नियोजन एक अनुसूची में इसे फिट करने की प्रक्रिया है।
  3. 60% दक्षता उन सभी के बारे में है जिनकी आप उम्मीद कर सकते हैं। 70% यूटोपिया है। यदि आप दिनों में अनुमान लगा रहे हैं, तो इसे बनाएं। यदि आप घंटों में अनुमान लगा रहे हैं, तो इसे बाद में लागू करना न भूलें।
  4. लंबी पूंछ याद है । अनुमान एक मोटा अनुमान है कि यह "संभवतः" कब तक जोखिम और अज्ञात के कुछ स्तर के लिए समायोजित हो जाएगा। लंबी पूंछ खेलने में आती है क्योंकि आवश्यक कार्य की मात्रा कभी भी 0. ओटीओएच से कम नहीं होगी, इसे लेने में अधिकतम समय केवल यह सीमित होगा कि आप कितना समय देने से पहले इस पर खर्च करना चाहते हैं। जैसा कि मेरे एक पूर्व बॉस ने कहा "सभी अनुमान +/- x% हैं और यह कभी भी शून्य नहीं है"।

क्या आप बता सकते हैं कि यह 60% संकेतक (और 70% -टोपिया) कहां से आता है? क्या इस विषय पर कोई लेख कहीं उपलब्ध हैं?
krokodilko

7

मुझे आश्चर्य है कि किसी ने PERT- शैली आकलन तकनीक का उल्लेख नहीं किया है जो रॉबर्ट मार्टिन के द क्लीन कोडर में वर्णित है । उस पद्धति में, आप अनुमान लगाते हैं कि 3 परिदृश्यों में कितना समय लगेगा: आशावादी ( O), नाममात्र ( N), और निराशावादी ( P)। फिर अपेक्षित अवधि = (O+4N+P)/6और आपको एक मानक विचलन मिलता है (P-O)/6

यह बहुत अच्छी तरह से काम करने लगता है, और मैंने इसे कुछ समय का उपयोग किया है जब प्रबंधन वास्तव में परवाह करता है कि संभवतः कितना समय लगेगा।

जैसा कि अन्य लोगों ने टिप्पणी की है, मैंने भी ऐतिहासिक डेटा की जांच करके अनुमान लगाया है ("इस तरह का काम करने में कितना समय लगा?")।

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

घंटे का अनुमान सही ढंग से प्राप्त करने के लिए दृढ़ता से कठिन है, और उन्हें प्रभावी ढंग से मापने के लिए छोटे पर्याप्त मात्रा में चीजों को तोड़ने के लिए बहुत काम की आवश्यकता होती है। और फिर भी वे शायद ही कभी सही होते हैं क्योंकि बहुत अधिक चर होते हैं और हम बीमारी, छुट्टी, या यहां तक ​​कि ध्यान भंग होने जैसी चीजों के लिए जिम्मेदार होते हैं।

अगर मुझे घंटे का अनुमान लगाना है, तो मैं केवल एक पुनरावृत्ति के भीतर छोटे कार्यों के लिए उन्हें करने की कोशिश करता हूं। मैं आधे दिन के अनुमानों (4, 8, 12 घंटे) में सब कुछ मापता हूं जब तक कि मुझे नहीं पता कि यह कम हो सकता है। लेकिन मैं शायद ही कभी 1 घंटे से कम समय में किसी भी चीज का अनुमान लगाता हूं।


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

5

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

दूसरा, किसी तरह का डिज़ाइन करना। डिजाइन योजना बनाने का पहला कदम है, आप बिना ड्राइंग के घर नहीं बनाते हैं।

तीसरा, ट्रैक टाइम (प्रयास)। आपको कम से कम अंतर करना चाहिए:

  • विश्लेषण
  • डिज़ाइन
  • कोड
  • इकाई परीक्षण (दोषों को ठीक करना शामिल है)
  • एकीकरण परीक्षण (दोषों को ठीक करना शामिल है)
  • उपयोगकर्ता के साथ स्वीकृति परीक्षण, (दोषों को ठीक करना शामिल है)

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

चौथा, आकलन के लिए प्रमुख आधार वस्तुओं की पहचान करें। उदाहरण के लिए:

  • स्वचालित होने की प्रक्रियाओं की संख्या (विश्लेषण)
  • डोमेन मॉडल संस्थाओं की संख्या (डिज़ाइन)
  • प्रपत्र और रिपोर्ट की संख्या (कोड)

पांचवां, आधार वस्तुओं और प्रयासों को सहसंबंधित करना। उदाहरण के लिए:

  • विश्लेषण का प्रयास = एक्स मैन-घंटे / प्रक्रिया स्वचालित होने के लिए
  • डिजाइन प्रयास = Y मानव-घंटे / डोमेन मॉडल इकाई
  • कोड प्रयास = जेड मैन-घंटे / फॉर्म (या रिपोर्ट); प्रपत्रों की संख्या = A * डोमेन मॉडल इकाइयाँ
  • इकाई परीक्षण प्रयास = M% * कोड प्रयास
  • एकीकरण परीक्षण प्रयास = एन% * कोड प्रयास
  • स्वीकृति परीक्षण प्रयास = P% * कोड प्रयास

छठा, प्रत्येक परियोजना के लिए अनुमानों से प्रदर्शन और विचलन का ट्रैक रखें। तो आप अपने सहसंबंध कारकों को ठीक कर सकते हैं।

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

Http://en.wikipedia.org/wiki/Personal_Software_Process पर एक नज़र डालें , यह वास्तव में काम करता है।


3

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

कुल समय की आवश्यकता व्यक्तिगत टुकड़ों के योग से अधिक होगी, क्योंकि आपको एकीकरण और परीक्षण के लिए कुछ समय चाहिए।

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

इसकी तरह एक लक्ष्य की शूटिंग। अनुमान पर पिछले शॉट्स आपको बताएंगे कि आप कैसे निशान से दूर हैं, ताकि आप इसे सही कर सकें।


3

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

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

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


1

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


1

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


1

इस पर एक किताब लिखने के बजाय, मैं अनुमान लगाने की "ब्रेक डाउन" विधि का उपयोग करने के बारे में थोड़ी सलाह दूंगा:

  • अपने असाइनमेंट को छोटे घटक कार्यों में तोड़ दें। यथासंभव प्रत्येक कार्य का अनुमान लगाएं।

  • योजना और डिजाइन के लिए एक कार्य जोड़ें (जिसमें आप अभी जो कर रहे हैं, उसमें शामिल हैं।) इसका अनुमान लगाएं।

  • यदि आपके पास पहले से एक नहीं है, तो "कार्यों को एक साथ लाने के लिए" एक कार्य जोड़ें। यह कार्य पहली बार में उपयोगी नहीं लग सकता है। हालाँकि, जब आप अनुमान लगाने के इस "ब्रेक डाउन" विधि का उपयोग करते हैं, तो हमेशा ऐसा करने के लिए चीजों का सेवन करना पड़ता है कि "कार्यों के बीच में" और "कार्यों को एक साथ खींचें।" यह अनुमान लगाने के लिए मुश्किल हो सकता है। अपने सर्वोत्तम प्रयास कीजिए।

  • परीक्षण और प्रलेखन के लिए एक कार्य जोड़ें। आपके असाइनमेंट को बहुत परीक्षण और प्रलेखन की आवश्यकता नहीं हो सकती है, लेकिन आपको इसके बारे में सोचने में कम से कम समय बिताना चाहिए।

  • समग्र अनुमान प्राप्त करने के लिए कार्य अनुमान जोड़ें।

  • आगे बढ़ें और उस कुल अनुमान को दो that से गुणा करें। इससे आपको निम्न समय मिलेगा:

    1. उन चीजों को समाप्त करें जिन्हें आपने अपनी मूल कार्य सूची में अनदेखा किया था
    2. उन चीजों को समाप्त करें जिनके बारे में आप नहीं जान सकते थे
    3. अन्य लोगों से प्रतिक्रिया शामिल करें, और बदलाव करें
    4. अपने आस-पास चल रही अन्य चीज़ों, जैसे मीटिंग्स, से बाधित हों
    5. अनुमान के आगे खत्म करो इसके पीछे से अधिक बार

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

†† जैसा कि आप अधिक से अधिक अनुभव प्राप्त करते हैं, इस "ठगना कारक" को आपकी व्यक्तिगत शैली, और आपके कार्य वातावरण के अनुरूप बनाया जा सकता है।


1

वह सूत्र जो स्वयं काम करते समय काम करता है:

  1. 1 - 4 घंटे की ग्रैन्युलैरिटी के लिए टूडू का ब्रेक डाउन करें। मुझे लगता है कि मैं आमतौर पर इन के साथ सटीक हूँ

  2. 'अज्ञात कारक': 2 के कारक से गुणा करके अज्ञात की संख्या को बढ़ाया। यानी यदि आप एक काउचडब ऐप्लिकॉन विकसित करना चाहते हैं, लेकिन अब जावास्क्रिप्ट और http के बारे में कुछ भी जानते हैं .. 2 ^ 2 को मल्टी फैक्टर के रूप में जोड़ें।

  3. संदर्भ-स्विच-कारक: 1.5 से कई यदि आप सही वातावरण (अध्ययन के कोने आदि में घर पर) में काम करेंगे, या 2.5 यदि आप अभेद्य वातावरण (कार्यालय / भीड़ वाली जगह आदि) में काम करेंगे

मुझे यह वास्तविक समय में +/- 20% के भीतर लगता है !!


0

अपने खुद के पूर्वाग्रह जानें। यदि अगली बार आपके अंतिम अनुमान को कारक दो से बहुत कम कर दिया गया है, तो अपने प्रारंभिक अनुमान को दोगुना करें। (ज़ाहिर है, हॉफ़स्टैटर के नियम से यह सही करना मुश्किल है ...)

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


0

सलामी बल्लेबाजों के लिए, "सॉफ्टवेयर इंजीनियरिंग इकोनॉमिक्स", बैरी बोहम और "कंट्रोल्डिंग सॉफ्टवेयर प्रोजेक्ट्स", टॉम डेमको द्वारा पढ़ा गया। बैरी बोहेम द्वारा आपके द्वारा उन दोनों को पढ़ने और पचा लेने के बाद, "सॉफ़्टवेयर कॉस्ट एस्टिमेशन विद COCOMO 2" पढ़ें।

मुझे आगे क्या कहना है, इसके लिए आपको एक एलओटी की संभावना और सांख्यिकी वर्ग, यहां तक ​​कि एक बुनियादी रसोई की किताब भी लेने में मदद मिलेगी।

कोई भी अनुमान सही नहीं है। जल्दी आने की कुछ संभावना है, और देर से आने की कुछ संभावना है। बोहम के मूल विस्तृत COCOMO मॉडल ने ऐसी भविष्यवाणियां कीं जो वास्तविक परिणाम के 30% के भीतर हुईं, जो 60% से बेहतर थीं। जब उन्होंने किताब लिखी और प्रकाशित की थी, तो जो कुछ आम था, उससे बहुत बेहतर था।

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.