समय आकलन में किसे भाग लेना चाहिए?

9

एक आईटी परियोजना में:

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

2

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

1

आपको पता होना चाहिए कि एक अनुमान एक निर्णय नहीं है, लेकिन एक (अक्सर मुश्किल) भविष्यवाणी है। कोई छलावा नहीं है। वोट नहीं हैं।

— user281377

@ammoQ समस्या यह है कि निर्णय के रूप में कई परियोजना नेता हैं!

— अमीर रज़ाई

2

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

— user281377

@ user281377 मुझे पसंद है कि आपको क्या मिल रहा है: सॉफ्टवेयर विकास के लिए हाइजेनबर्ग अनिश्चितता सिद्धांत।

— केटीफ जूल

8

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

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

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

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

जिनके वोट की गिनती सबसे ज्यादा की जाती है, वह इस तरह से काम नहीं करते हैं। यह एक चर्चा और एक समझौता है। यदि एक प्रबंधक को लगता है कि डेवलपर्स का अनुमान बहुत अधिक है, तो उसे यह समझाने की आवश्यकता है कि क्यों और कैसे (दबाव नहीं) डेवलपर को इसे सही ठहराने के लिए और उन्हें एक आम सहमति तक पहुंचने की आवश्यकता है। इस घटना में आप उस समझौते पर नहीं पहुँच सकते, मैं अनुभव से दो बातें कहूँगा:

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

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

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

— जॉन हॉपकिंस
स्रोत

+1 उस नंबर के लिए जिसे आप "चाहते हैं"। यहाँ देखें ।

— स्पेंसर रथबुन

1

'मैं चाहता हूँ' पर कुछ अधिक पूरी तरह से: अनुमान खेल

— K.Steff

2

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

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

— डीन हार्डिंग
स्रोत

1

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

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

— गूदा
स्रोत

0

एक परियोजना की व्यावसायिक आवश्यकताएं हैं और शीर्ष नीचे से आने वाली समय सीमाएं हैं। पहली पुनरावृत्ति के लिए उन्हें "अनुमान" दिया जाता है।

इन आवश्यकताओं को 100% में जाना जाता लागत ( "लॉगिंग सक्षम" = 2 घंटे = "डाउनलोड की तरह होने की सबसे बड़ी कार्यों को विभाजित किया जाना चाहिए log4j / SLF4J और प्लग में")।

अनुमान उच्चतम संभव स्तर पर किया जाना चाहिए जिसके पास पहले से ही ऐसा करने के लिए पर्याप्त तकनीकी विशेषज्ञता है।

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

— bobah
स्रोत

1

"एक परियोजना की व्यावसायिक आवश्यकताएं हैं + ऊपर से नीचे की ओर आने वाली समय सीमा। वे पहले पुनरावृत्ति के लिए" दिए गए अनुमान "हैं।" - इस तरह के दबाव के लिए दुःखी सही और जिम्मेदार है जो दूसरों को गलत अनुमान लगाने की ओर ले जाता है क्योंकि वे इन समयसीमाओं के भीतर रहने की कोशिश करते हैं, इसके बावजूद कि वास्तव में कितना समय लगेगा।

— जॉन हॉपकिंस

@ जॉन हॉपकिंस - +1, निष्पक्ष बिंदु, लेकिन मैंने आदर्श प्रक्रिया का वर्णन किया, वास्तव में, जैसा कि आपने कहा, तकनीकी प्रबंधक कभी-कभी एप्रीओरी अवास्तविक कार्यक्रम के लिए प्रतिबद्ध होते हैं और इस परियोजना के लिए देरी के लिए "औचित्य" खोजना पसंद करते हैं

— bobah

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

— जॉन हॉपकिंस

1

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

— वेक्टर

कभी ध्यान दें कि कैसे MLB टीमों के पास डगआउट में हमेशा एक पूर्व खिलाड़ी होता है? ऐसा इसलिए है क्योंकि केवल एक पूर्व खिलाड़ी समझता है कि काम पूरा करने के लिए उसे क्या करना पड़ता है और मैदान लेने वाले लोगों का विश्वास है।

— वेक्टर

-1

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

मैं सभी को समय के आकलन में रहना पसंद करता हूं और हम यहां भी ऐसा ही करते हैं

किसे या किसके वोट की गिनती सबसे ज्यादा होनी चाहिए?

डेवलपर लेकिन फिर भी टीम के बारे में इसके सभी काम फिर से

— गोपी
स्रोत

-2

विकासकर्ताओं ने परियोजना के कार्यान्वयन के साथ समझौता किया! और किसी की नहीं!

काम करने वाले और विकास दल के नेताओं को वास्तविक विकास करने वाले डेवलपर्स ही सही तरीके से अनुमान लगाने में सक्षम हैं कि वास्तव में कितना समय लगेगा। केवल वास्तविक कोड आधार से परिचित प्रोग्रामर ही विकास के दौरान आने वाली संभावित कठिनाइयों और नुकसान को समझ सकते हैं। बाकी सब लोग 'दर्शक' हैं।

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

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

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

— वेक्टर
स्रोत

2

कृपया इस उत्तर को सुधारें।

— Ktete