सॉफ़्टवेयर शेड्यूल को परिभाषित करना इतना कठिन क्यों है?

Question

ऐसा लगता है कि, मेरे अनुभव में, हमें इंजीनियरों को सही अनुमान लगाने और कार्यों को पूरा करने के लिए निर्धारित करना दांत खींचने जैसा है। केवल 2-3 सप्ताह या 3-6 महीने का स्वैग का अनुमान देने के बजाय ... सॉफ़्टवेयर शेड्यूल को परिभाषित करने का सबसे सरल तरीका क्या है ताकि वे परिभाषित करने के लिए इतना दर्दनाक न हों? उदाहरण के लिए, ग्राहक A 02/01/2011 तक एक सुविधा चाहता है। आप इस सुविधा को लागू करने के लिए समय कैसे निर्धारित करते हैं, यह जानते हुए कि रास्ते में अन्य बग फिक्स की आवश्यकता हो सकती है और अतिरिक्त इंजीनियरिंग समय ले सकता है?

Comments

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

— डैन मैकग्राथ

@ दान मैकग्राथ: आप प्रमाण युक्त लिंक पोस्ट क्यों नहीं करते? रुको, क्या आप Fermat और उनके अंतिम प्रमेय प्रमाण की तरह बनने की कोशिश कर रहे हैं, जो कभी नहीं मिला: |

— शमीम हाफिज

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

— स्टीवन ए। लोव

आपकी रुचि के आधार पर कुछ ऐसा है जो साक्ष्य आधारित निर्धारण है।

— क्रेगे

उन्हें परिभाषित करना मुश्किल नहीं है। बस रखना असंभव है।

— टोनी हॉपकिंसन

Answer 1

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

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

हमें अक्सर उन परियोजनाओं का अनुमान लगाने के लिए कहा जाता है जो नए उपकरण, प्रौद्योगिकियों का उपयोग करते हैं, जहां आवश्यकताएं बदल रही हैं, आदि। यह हमारे पिछले अनुभवों पर प्रक्षेप से अज्ञात में अधिक एक्सट्रपलेशन है। इसलिए यह स्वाभाविक है कि अनुमान लगाना अधिक कठिन होगा।

Comments

बहुत बढ़िया अंक। यह पूछने की तरह है कि आपको कहीं भी ड्राइव करने में कितना समय लगेगा। आप दूरी के आधार पर एक अनुमान दे सकते हैं, लेकिन आप भीड़ के समय यातायात की मात्रा को कम नहीं कर सकते।

— जेफ़ो

@ जेफ़ यह बहुत अच्छी तुलना है। मुझे यह याद रखना होगा कि एक

— डेव मैकक्लेलैंड

@ जेफ ... लेकिन आप यह जान सकते हैं कि यह भीड़ का समय है और उस तथ्य को अपने अनुमानों में शामिल करें ... आप अभी भी बंद हो सकते हैं, लेकिन ज्यादा से ज्यादा नहीं

— पेमदास

@ पेमदास: वास्तव में, आप अपने अनुमानों में सभी तथ्यों को जोड़ने के लिए पर्याप्त नहीं जान सकते हैं । आप यह नहीं जान सकते कि अग्निशमन विभाग कॉल का जवाब दे रहा है या नहीं। आपको पता नहीं चल सकता है कि बिजली का तार गिर गया है और सड़क अवरुद्ध हो रही है। वहाँ अनंत बातें हैं जो आप भविष्य के बारे में नहीं जान सकते हैं। यह भविष्य है। यह भविष्यवाणी करना कठिन है - परिभाषा के अनुसार।

— एस.लॉट

@ पेमदास - जितना अधिक जटिल कार्य, अराजकता के देवता उतना ही अधिक हस्तक्षेप करते हैं। बेशक, शायद कुछ बिंदुओं से अधिक आपकी बात फिट बैठता है - परिचित कार्यों के साथ, आप जानते हैं कि उन pesky देवताओं को कितनी रुचि है।

— स्टीव ३१

Answer 2

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

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

1. यह जानना आसान नहीं है कि किसी उत्पाद को करने के लिए वास्तव में क्या आवश्यक है, और विशेष रूप से यह कैसे करना है । बहुत बार मैंने एक आवेदन के कुछ हिस्सों को शुरू किया, काम के दिनों की तुलना में, यह समझा कि मेरा पहला दृष्टिकोण गलत था, और यह कि चीजों को करने का एक बेहतर और बेहतर तरीका है।

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

3. आवश्यकताएँ अक्सर पर्याप्त स्पष्ट नहीं होती हैं , लेकिन शुरुआत में उन्हें पढ़ने के बाद, आपको लगता है कि वे हैं। कभी-कभी आप समझ सकते हैं कि 'ए' का मतलब है, और, उन्हें लागू करना शुरू करने के बाद, आप देखेंगे कि उनका मतलब 'बी' है।

4. ग्राहक आपकी आवश्यकताओं को तब बदलते हैं, जब आपने संबंधित भाग को अभी-अभी समाप्त किया है , और वे वास्तव में यह नहीं समझते हैं कि आप एक छोटे से बदलाव के लिए दो और सप्ताह और $ 2000 का अनुरोध क्यों कर रहे हैं, क्योंकि वे नहीं देखते हैं कि इस छोटे से परिवर्तन की आवश्यकता है अन्य चीजों को बदलें, जिन्हें दूसरों को बदलने की आवश्यकता होती है, आदि।

5. आप अपनी प्रेरणा का अनुमान नहीं लगा सकते । ऐसे दिन हैं जब आप घंटों काम कर सकते हैं और अच्छी तरह से सफल हो सकते हैं। ऐसे सप्ताह होते हैं, जब कोड की दस पंक्तियाँ लिखने के बाद, आप प्रोग्रामर StackExchange पर स्विच करते हैं, और प्रश्नों का उत्तर देने वाले घंटे पढ़ते हुए बिताते हैं।

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

7. आपका अनुमान आपके ग्राहक पर भी निर्भर करता है । मेरे पास ऐसे ग्राहक थे जो अपने मेल का जवाब देने से पहले हफ्तों बिताते हैं। यह वास्तव में आपके शेड्यूल को प्रभावित कर सकता है जब आपको उनके उत्तर की प्रतीक्षा करनी चाहिए (उदाहरण के लिए यदि आप उन्हें किसी आवश्यकता के बारे में पूछ रहे हैं)।

तुम क्या कर सकते हो?

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

2. स्पष्ट हो । यदि आप एक डिजाइनर, किसी अन्य डेवलपर, आदि पर भरोसा करते हैं, तो यह कहें। यह बताने के बजाय कि "मैं तीन महीने में उत्पाद वितरित करूंगा", यह कहें कि "मैं डिज़ाइनर द्वारा मुझे PSD फ़ाइलें प्रदान करने के बाद दो महीने में उत्पाद वितरित करूंगा।"

3. बता दें कि यदि आवश्यकताओं में हर दिन बदलाव होता है, तो परियोजना को समय पर वितरित नहीं किया जाएगा।

4. अपने शेड्यूल को स्लाइस करें । समय पर एक बड़ी परियोजना के कुछ हिस्सों को वितरित करना आसान है।

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

Comments

@ जेफ ओ: मुझे नहीं पता। मेरे लिए, डिलीवरी की तारीख का मतलब एक समय सीमा है। और एक समय सीमा का मतलब है कि परियोजना को उसके बाद वितरित नहीं किया जा सकता है। इसके अलावा, मनोवैज्ञानिक रूप से, ग्राहक कम नाराज हो सकते हैं जब आपने कहा था कि आप एक महीने में कुछ वितरित करेंगे और आप इसे चार दिन बाद वितरित करेंगे, जैसे कि, 8 जनवरी 2011 को, आप कहते हैं कि आप इसे 8 फरवरी, 2011 को वितरित करेंगे, और आप इसे 12 फरवरी को वितरित करें।

— आर्सेनी मूरज़ेंको 4

@ पेमदास: यह आलस्य का सवाल नहीं है। आप बस उदास हो सकते हैं, या व्यक्तिगत / पारिवारिक समस्याओं पर ध्यान केंद्रित करने, या अन्य ग्राहकों द्वारा या जो भी हो, पर ध्यान केंद्रित करने के लिए अस्थायी कठिनाइयों का सामना कर सकते हैं।

— आर्सेनी मूरज़ेंको

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

— शमीम हाफिज

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

— मैथ्यू फ्रेडरिक

@ 0A0D यदि आप प्रोजेक्ट को उसके सबसे दानेदार उप-प्रकारों में तोड़ते हैं और यह पता लगाते हैं कि उनमें से प्रत्येक कैसे कार्य करेगा, तो यह सुनिश्चित करने के लिए सब कुछ के माध्यम से काम करें कि आप उन टुकड़ों के संयोजन के निहितार्थ को समझते हैं, और किसी भी नए या नए सिरे से पूरी तरह से समीक्षा नहीं करते हैं- इन-द-माइंड टेक्नोलॉजीज शामिल हैं, और हर अज्ञात को रास्ते से हटाते हैं, तो आप बिल्कुल सटीक रूप से सटीक अनुमान लगा सकते हैं। बेशक, आपने लगभग सभी प्रोग्रामिंग की हैं, बस कोडिंग भाग को छोड़ दिया है, और आप पहले से नहीं जान सकते हैं कि अनुमान लगाने में कितना समय लगेगा। ;)

— मैथ्यू फ्रेडरिक

Answer 3

एक बहुत ही समान प्रश्न है "इस पहेली पहेली को हल करने में कितना समय लगेगा?"

आप इसका जवाब नहीं दे सकते हैं कि जब तक आप इस पर एक नज़र नहीं डालते हैं, जैसे कि कई चीजें देख सकते हैं:

• क्या यह एक परिचित भाषा में है? (स्पेनिश बनाम अंग्रेजी बनाम चीनी)
• क्या यह एक प्रकार है जिसे हमने पहले हल किया है? (एक पत्रिका में चल रही श्रृंखला में एक उदाहरण)
• इससे पहले कि हम इसे भी समझ सकें, क्या किसी भी लीड को अतिरिक्त ज्ञान की आवश्यकता है?
• क्या पहेली में कहीं ऐसी चीजें हैं, जो आपके ज्ञान के लिए, अतिरिक्त काम की आवश्यकता होगी?

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

साथ ही इसे यथासंभव सस्ते में करने का एक मजबूत दबाव है, इसलिए जितनी जल्दी हो सके और बहुत कम अनुमान के लिए दोष परियोजना प्रबंधक पर दबाव डालने पर नहीं जाता है, लेकिन डेवलपर अनुमान दे रहा है। यह डेवलपर को इसे पकड़ने के लिए कई पुनरावृत्तियों को नहीं लेता है, और किसी भी निरपेक्ष संख्या को देने के लिए बहुत थके हुए होना सीखता है।

Answer 4

सबसे स्पष्ट कारण है कि आप इंजीनियर आपको सटीक अनुमान क्यों नहीं दे सकते कि यह असंभव है ।

बेशक आप अनुमान लगा सकते हैं कि आपके घर से काम करने में कितना समय + -2 मिनट लगेगा। आप कार चलाना जानते हैं, आप ट्रैफ़िक और कुछ अन्य बाहरी कारकों का मूल्यांकन कर सकते हैं।

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

सॉफ्टवेयर में, यह बदतर है:

1. अनुमान अक्सर एक प्रतिबद्धता बन जाते हैं , इसलिए हमारे निर्णय को संशोधित किया जाता है।
2. एक ही कार्य के लिए बॉब और कार्ल के अनुमान के बीच भारी अंतर हो सकता है ।
3. अनिश्चितताएं बहुत आम हैं, हममें से कितने लोग एक बेवकूफ बग या हार्ड ड्राइव क्रैश पर फंस जाते हैं जो किसी भी स्पष्ट अच्छे अनुमान को नष्ट कर देते हैं।
4. हम आम तौर पर मीटिंग, फोन कॉल, हमारे कॉलगर्ल की मदद करने आदि सहित प्रोग्रामिंग से इतर सभी कार्यों को भूल जाते हैं ।
5. मानव मस्तिष्क सीमित है । इसे लंबे समय तक चलने वाले कार्यों का अनुमान लगाने के लिए नहीं बनाया गया है।

इसलिए अपने ग्राहक को यह बताना असंभव है कि आप 02/01/2011 को अच्छी सटीकता के साथ क्या कर पाएंगे, और 03/01/2011 के बारे में भूल जाएंगे।

उन सभी समस्याओं को दूर करने के लिए, मैं आपको उन्नत अनुमान तकनीकों जैसे कि प्लानिंग पोकर (अस्वीकरण: यह मेरी वेबसाइट में से एक है) और वेग गणना के साथ Iterative Development की सलाह देता है ।

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

Comments

इसलिए अगर कोई किसी सुविधा के लिए 02/01/2011 की डिलीवरी की तारीख पूछता है, तो सबसे अच्छा शर्त यह है कि "जैसे ही मैं इस पर काम कर रहा हूं, मैं आपको बता दूंगा कि आपको कितना समय लगेगा"? मुझे यकीन है कि यह एक प्रमुख गुब्बारे की तरह अच्छा होगा;)

— ब्रायन

0A0D: यह स्थिति पर निर्भर करता है। ऐसी टीम के साथ जो एक-दूसरे को नहीं जानती, मैं किसी भी समय सीमा पर शर्त नहीं लगाता। हालाँकि यदि आप अपने औसत वेग को जानते हैं, सामूहिक अनुमानों का उपयोग करें और पुनरावृत्त विकास का अभ्यास करें, तो आप बहुत अधिक आत्मविश्वास के साथ एक समय सीमा निर्धारित कर सकते हैं।

@ 0A0D, यूरोप में 02/01/2011 का मतलब 2 जनवरी है। 8 जनवरी को पूछे जाने पर कम से कम इसका जवाब आसान हो जाता है: D

Answer 5

सॉफ्टवेयर विकास - परिभाषा के अनुसार - खोज और आविष्कार का एक कार्य है। इसमें हमेशा कुछ अज्ञात होना चाहिए।

सॉफ्टवेयर डेवलपमेंट से जुड़ी हर बात का पता केवल तब चलता है, जब सॉफ्टवेयर पूरा हो जाता है।

केवल एक ही समय में कोई अज्ञात तकनीक या व्यावसायिक सुविधा नहीं है जब यह पूर्ण, पैकेज्ड समाधान डाउनलोड के लिए तैयार हो।

हम नया सॉफ्टवेयर लिखने का कारण यह है क्योंकि हमारे पास एक नई सुविधा या नई तकनीक या दोनों हैं। नए का अर्थ है नया - अज्ञात - अप्रत्याशित।

क्योंकि सॉफ्टवेयर विकास में नवीनता शामिल होनी चाहिए, विकास के प्रयास की भविष्यवाणी नहीं की जा सकती है।

Answer 6

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

Comments

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

— मैथ्यू फ्रेडरिक

मैं एक ही उत्पाद पर काम करता हूं, लेकिन समस्या कभी भी रिलीज के साथ बदल जाती है। मैं यह स्वीकार करूंगा कि मुझे कभी भी किसी ऐसी चीज का अनुमान नहीं लगाना चाहिए जिसे पूरा करने में 6-8 महीने से अधिक समय लगा हो।

— पेमदास

Perndas, बस इसके मज़े के लिए: C # या Java में आपके उत्पाद को फिर से लिखने में कितना समय लगेगा? Google क्लाउड में चलने के लिए? OpenGL में लाइव डेटा की कल्पना करने के लिए? Wii पर चलने वाला एंड-यूज़र क्लाइंट होना चाहिए?

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

— पेमदास

Answer 7

यह कभी आसान नहीं होता। आप बस इसे बेहतर बनाने की कोशिश करें।

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

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

उम्मीद है कि आपके पास एक साथ काम करने का पर्याप्त इतिहास है और खुद को विश्वसनीय होने के लिए पर्याप्त रूप से स्थापित किया है। आप उनसे विकास प्रक्रिया को पूरी तरह से समझने की उम्मीद नहीं कर सकते हैं, लेकिन आप उन्हें यह महसूस करा सकते हैं कि आप एक ईमानदार प्रयास कर रहे हैं और उनके ज्ञान की कमी का फायदा नहीं उठा रहे हैं।

Comments

मैंने वृद्धिशील रिलीज के बारे में भी नहीं सोचा था। ग्राहक को कुछ समझदारी देने के लिए यह एक बढ़िया उपकरण है। हालाँकि, मैं "बाहरी" क्लाइंट्स के साथ काम नहीं करता, लेकिन घर में यह अभ्यास करते हैं, यह विकास के साथ पाइपलाइन परीक्षण का एक शानदार तरीका है।

— पेमदास

Answer 8

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

Answer 9

मैंने इस पुस्तक से बहुत कुछ सीखा है:

सॉफ्टवेयर अनुमान: ब्लैक आर्ट को डीमिस्टिफाई करना

बेहतर अनुमान परिणाम प्राप्त करने के लिए हम यह करते हैं:

1. सभी लेकिन तुच्छ कार्यों का अनुमान एक व्यक्ति (हमारे मामले में दो) से अधिक है
2. हम कार्य को छोटे कार्य में विभाजित करते हैं। यदि आपके पास जितने अधिक कार्य हैं, तो आपके अनुमान अच्छे होंगे - बड़ी संख्या का कानून यदि मैं बू से सही तरीके से याद करता हूं
3. हम सबसे खराब, सबसे अच्छा और सबसे अधिक संभावना परिदृश्य का अनुमान लगाते हैं। कभी-कभी हम में से प्रत्येक उन पेड़ों के परिदृश्यों को पूरी तरह से अलग तरह से अनुमान लगाता है। इसका मतलब है कि हमें बात करनी होगी और आमतौर पर यह पता चलता है कि हम में से एक ने कार्य को नहीं समझा। अगर कोई व्यक्ति अकेले कार्य का अनुमान लगाता है तो यह गलत होगा।
4. हम 3 अंक ऊपर से समीकरण में डालते हैं और अनुमान (एक्सेल) k प्राप्त करते हैं

कार्य कार्य समाप्त होने के बाद और हमारा अनुमान गलत था कि हम कारणों को खोजने की कोशिश करते हैं। और हम इस ज्ञान को अगले अनुमान प्रक्रिया में शामिल करते हैं। अब तक यह सबसे बड़ी प्रक्रिया है जिसका उपयोग मैंने बड़े कार्यों के आकलन के लिए किया है। जब मैं कहता हूं कि मुझे नौकरी से मतलब है तो लगभग 50-500 घंटे लगते हैं।

Answer 10

नोट: यह वास्तव में केवल उन परियोजनाओं पर लागू होता है जहां आप एक निश्चित / सपाट दर से घंटे के हिसाब से बिल देते हैं।

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

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

Answer 11

नामित सभी चीजों के अलावा, मैं इन दो चीजों को कुछ सबसे बड़ी समस्याओं के रूप में देखता हूं। पहले आप अनुमान लगाते हैं कि प्रत्येक डेवेलपर के आधार पर अंतिम तारीख सप्ताह में 5 दिन पूरे 8 घंटे उपलब्ध है। यह गलत है और वस्तुतः 100% गारंटी होगी कि अंतिम तिथि किसी भी परियोजना पर छूट गई है जो तुच्छ नहीं है। लोग समय निकालते हैं, कंपनी (या गैर-परियोजना-आधारित) बैठकों में भाग लेते हैं, स्वास्थ्य बीमा दावों पर एचआर के साथ लड़ाई करते हैं, ब्रेक लेते हैं, आदि प्रति दिन प्रति डेवलपर 6-घंटे की उपलब्धता से अधिक कभी नहीं मानते हैं।

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

Comments

मैं लेखन इकाई परीक्षण को गैर-विकास कार्य नहीं कहूंगा;) और हमारे मालिक हमें प्रतिदिन 6 घंटे गिनते हैं। अगर मैं 60 घंटे कहता हूं तो वे 10 दिन कहते हैं।

— पियोट्र पर्क

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

— HLGEM

Answer 12

जब यह उन कार्यों के लिए समय के आकलन के लिए आता है जो अधिक समय ले सकते हैं तो कुछ घंटे मैं इस नियम का उपयोग करने की पूरी कोशिश करता हूं:

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

शायद उससे अधिक नियम हैं, लेकिन मेरी दीवार पर इस नियम के साथ वास्तव में एक पोस्टर नहीं है। मैंने अभी उन्हें तैयार किया है, लेकिन वे मेरे अनुभव से आते हैं (इसलिए यह आपके काम नहीं आ सकता)।

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

Answer 13

कर रहे हैं "में जाना जाता अज्ञात" और "अज्ञात अज्ञात।" :-)

1. अनुमान अक्सर समय सीमा बन जाते हैं।

   • कोई भी एक समय सीमा याद नहीं करना चाहता है और शीर्षक बन सकता है!

2. आवश्यकताएँ बदल जाती हैं (अक्सर तर्कसंगत रूप से) और प्रोग्रामर इसे वीटो नहीं कर सकता है।

3. प्रोग्रामर करते हैं जैसे कारकों पर नियंत्रण नहीं हो सकता है

   • कोड की उपलब्धता वह पर निर्भर है
   • कोड की गुणवत्ता वह पर निर्भर है
   • कुल मिलाकर वास्तुकला और प्रणाली का डिजाइन
   • सिस्टम के अन्य भागों तक पहुंचने के लिए एपीआई