टीम में शामिल होने वाले प्रोग्रामर के लिए अनुमान कैसे संभालें?


11

Iteration पहले ही शुरू हो चुका है, नया प्रोग्रामर टीम में शामिल हो गया है, टास्क एक्स का अनुमान पहले से ही एक अलग डेवलपर द्वारा 30 घंटे लगाया गया है।

इस स्थिति में सबसे अच्छा अभ्यास क्या है?

  • नया डेवलपर दिए गए अनुमान के साथ चलता है (विचार यह है कि वेग की गणना होने पर किसी भी विसंगति को ठीक किया जाएगा?)
  • नया डेवलपर कार्य का पुनः अनुमान लगाता है? (यदि ऐसा है, तो क्या होगा यदि यह काफी अधिक है और अब पुनरावृत्ति में फिट नहीं है?)
  • हमारे हाथ फेंक दो और वापस झरने के पास जाओ?
  • पूरी तरह से कुछ और?

जवाबों:


4

मैं क्या कहता हूं:

नए डेवलपर कार्य का पुनः अनुमान लगाते हैं। यदि इसे पुनरावृति से बाहर ले जाना है तो यह बाहर चला जाता है।

आपको नहीं पता कि नया डेवलपर मूल डेवलपर के समय में ऐसा करने में सक्षम है या नहीं। और चुस्त कार्यप्रणाली के साथ डेवलपर वह काम करता है जो कहना चाहिए कि इसमें कितना समय लगेगा।

इसके अलावा, मैं एक गुणक (डेवलपर के आधार पर कितना बड़ा) लागू करूंगा, क्योंकि डेवलपर को टीम / प्रोजेक्ट / कंपनी में फिट होना है।


15

मैं इस व्यक्ति को इस व्यक्तिगत स्प्रिंट से नहीं जोड़ूंगा। इसके बजाय उसे कोडबेस पर गति बढ़ाने के लिए काम करने के लिए एक और काम दें (कम लटकने वाले बगफिक्स शायद?)।

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


6

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

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

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

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


दुर्भाग्य से स्थिति बहुत अधिक थी कि - किसी ने काम का अनुमान लगाया फिर हमने जनशक्ति की अच्छी मात्रा खो दी। अब नई जनशक्ति में वे कार्य हैं जो पुरानी मानव शक्ति द्वारा अनुमानित किए गए थे।

7
यह एक असाधारण मामला है, और उस मामले में मेरे पास नई टीम होगी (सिर्फ नए आदमी नहीं) बैकलॉग का फिर से अनुमान लगाना। मैं स्प्रिंट को रद्द करने पर भी विचार करूंगा; यदि आपकी आधी टीम ने मध्य-स्प्रिंट को छोड़ दिया तो यह अब एक ही टीम नहीं है, और पुराने के लक्ष्यों को पूरा करने की उम्मीद नहीं की जानी चाहिए; उनके पास एक नया स्थिर-राज्य वेग और चीजों को देखने का एक अलग तरीका होगा।
कीथ्स
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.