स्क्रम: बैंड से बाहर निकलने वाले डेवलपर द्वारा किए गए काम को कैसे एकीकृत किया जाए?

Question

हमारे पास एक "विशिष्ट" SCRUM टीम है और हम स्प्रिंट के लिए काम करते हैं, और एक बैकलॉग भी बनाए रखते हैं। हाल ही में हम बैंड काम करने वाले एक अतिव्यापी डेवलपर के काम को एकीकृत / संभालने की कोशिश करने की समस्या में चले गए हैं (सामान्य काम के घंटे / स्प्रिंट के बाहर काम करना)।

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

इसे कैसे संभालना है? कुछ समस्याएं ..

• अगले स्प्रिंट के दौरान यह टीम के सदस्यों का कहना है कि प्रोग्रामिंग का काम 99% किया गया है और बस कोड की समीक्षा और परीक्षण की आवश्यकता है। SCRUM और फुर्तीली कार्यप्रणाली में आप इससे कैसे निपटते हैं?
• अन्य डेवलपर्स इन कहानियों से संबंधित डिजाइन निर्णयों में शामिल नहीं होने के बारे में शिकायत करते हैं, क्योंकि काम बैंड से बाहर किया गया था।
• हमारे उत्पाद के मालिक को इस "मुक्त" काम में खींचने के लिए लुभाया जाता है और अति-उत्साही सदस्यों को उत्पाद पर अधिक सुविधाएँ प्राप्त करने के लिए ऐसा करने की संभावना है कि टीम अन्यथा स्प्रिंट (ओं) में पूरा नहीं कर पाएगी। एक दृष्टिकोण है कि यह "प्रक्रिया" को तोड़ रहा है। जाहिर है क्यूए, यूआई और प्रलेखन काम अभी भी इस काम पर किए जाने की आवश्यकता है।

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

सॉफ्टवेयर विकास के लिए SCRUM और चुस्त प्रक्रिया में एक अति उत्साही सदस्य द्वारा किए गए काम को कैसे एकीकृत किया जाए?

Comments

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

— पीडीआर

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

— पीडीआर

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

— रोबोट

उम्मम .... "प्रोग्रामिंग का काम 99% किया गया है और बस कोड की समीक्षा और परीक्षण की आवश्यकता है" - क्या किसी और को इस कथन के साथ कोई गंभीर समस्या दिखाई देती है? यदि आपने कोई समीक्षा या परीक्षण नहीं किया है, तो आपका कोड सबसे आशावादी, 70% पर है। शायद 55% की तरह अधिक।

— जिम गैरिसन

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

— सिम्बैब

Answer 1

ठीक है, इसलिए किसी का उत्साहपूर्वक महान कोड लिखना है जिसे करने की आवश्यकता है, बस क्रम में नहीं। पूरे जोर के साथ:

उन्हें करने दो

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

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

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

Comments

मुझे लगता है कि आपका फ़ॉन्ट बहुत छोटा हो सकता है।

— स्किलिविज़

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

— पीटीएक्स

@ खाली आप इसे nailed। + 1 बबोन

— मेटाफ़ाइट

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

— daveD

@SomeKittens - उचित बिंदु। मुझे अभी भी लगता है कि प्रश्न में देव वास्तव में टीम / प्रक्रिया के हिस्से के रूप में काम नहीं कर रहे हैं। एक अकेला भेड़िया परियोजना को एक ऐसी दिशा में आगे बढ़ा सकता है जो अन्यथा नहीं जाती।

— daveD

Answer 2

दो चीजें हैं जो मुझे लगता है कि आपको यहां पर विचार करना चाहिए:

1. किसी के रचनात्मक प्रवाह में बाधा न डालें।
   • अगर कोई देवता घंटों काम करना चाहते हैं, तो उन्हें करने दें।
2. दूसरों के लिए काम मत करो।
   • यदि कोई देवता घंटों काम करना चाहता है, तो यह निश्चित है कि नर्क बेहतर होना दूसरों के लिए अधिक काम नहीं है ।

बिंदु 2 की संभावना है कि अन्य डेवलपर्स किस बारे में चिंतित हैं।

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

तो आप क्या कर सकते हैं?

महत्वाकांक्षी देव कोड को उसके दिल की सामग्री के लिए दें, लेकिन यह स्पष्ट करें कि उसके अतिरिक्त कोड का उपयोग करने का कोई कारण नहीं है ।

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

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

इस तरह, किसी को NO नहीं बताया जाता है , और किसी के पास उनके लिए अतिरिक्त काम नहीं है।

Answer 3

उसे टीम में वापस लाएं

आपको खुद से पूछना चाहिए (या टीम को बेहतर करना, जिसमें ओवरचाइवर भी शामिल है):

यह व्यवहार एक समस्या क्यों है?

चूंकि आप डेवलपर को ओवरचाइवर के रूप में लेबल करते हैं, मुझे लगता है कि उसका काम अच्छी गुणवत्ता का है, इसलिए मुझे लगता है कि यह कोई समस्या नहीं है।

लेकिन अन्य समस्याएं हैं:

• अतिरिक्त काम का ठीक से परीक्षण नहीं किया जाता है
• यह प्रलेखित नहीं है
• टीम के बाकी लोग यह नहीं जानते
• डेवलपर अगली बात को लागू करने का फैसला करता है, पीओ नहीं
• डेवलपर को अपने काम में शामिल करने के लिए विभिन्न हितधारकों से कोई प्रतिक्रिया नहीं मिलती है।

अगला मैं क्यों हूँ:

डेवलपर ऐसा क्यों करता है?

• यदि स्प्रिंट के अंत में पर्याप्त काम नहीं बचा है, तो आगे क्या करना है, इसके बारे में एक टीम का निर्णय (पीओ सहित) होना चाहिए। डेवलपर इस निर्णय से क्यों बचता है?

एक बार जब आप इन प्रश्नों का उत्तर दे देते हैं, तो आप अपने स्वयं के प्रश्न का उत्तर देना शुरू कर सकते हैं:

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

Answer 4

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

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

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

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

Answer 5

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

हालांकि, आपको अपनी प्रक्रिया में कभी भी कठोर नहीं होना चाहिए। स्क्रैम सिर्फ एक ढांचा है, ताकि आप अतिरिक्त समय को शामिल करने के लिए प्रक्रिया को समायोजित कर सकें (लेकिन फिर से किसी के लिए क्या करना है इसकी योजना बनाना मुश्किल है)।

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

Comments

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

— मैट

यह पोस्ट पढ़ना मुश्किल है (पाठ की दीवार)। क्या आप इसे बेहतर आकार में संपादित करना चाहेंगे ?

— gnat

Answer 6

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

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

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

• यह अधिक PBI लेने का जोखिम लेने के कारण विफल स्प्रिंट के भय को हरा देता है
• यह आपके प्रोग्रामर और टीम के अतिरिक्त काम को स्पष्ट करता है
• यह आपकी टीम के वेग को बढ़ाता है

हालाँकि शायद कम अनुभव वाली टीम के लिए, शायद यह उस पुश को कम कर दे जो प्रतिबद्धता टीम को PBI को खत्म करने के लिए देती है

Answer 7

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

स्क्रम में यह बताने के लिए कुछ भी नहीं है कि लोग कैसे काम करते हैं और अतिरिक्त कुछ भी करते हैं जो स्वाभाविक रूप से टीम के वेग में शामिल होता है।

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

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

अतिरिक्त कार्य करने में आने वाली कठिनाइयों का तात्पर्य है कि आपकी टीम में कुछ उप-इष्टतम (या शायद दुविधापूर्ण) भी है।

यदि यह मामला है, तो आपको अपने आप से पूछना चाहिए कि वह इतना अधिक क्यों प्राप्त कर रहा है, संभवतः थोड़े से अतिरिक्त प्रयास के साथ?

क्या आपके लिए बाकी टीम को अधिक हासिल करने में सक्षम बनाना संभव है?

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

Answer 8

क्या वे भी शिक्षक हैं

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

मैं चुनौती को 'सबसे अनुभवी डेवलपर की उत्पादकता के करीब कम अनुभवी डेवलपर्स कैसे प्राप्त करें' के रूप में चुनौती देखूंगा।

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

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

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

Answer 9

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

असली सवाल यह है कि क्या आप चाहते हैं कि यह देव वही करे जो वह कर रहा है। मुझे लगता है कि कई पहलू उस प्रश्न के उत्तर में महत्वपूर्ण भूमिका निभाते हैं:

1. क्या प्रोग्रामर अच्छा काम कर रहा है।
2. क्या हर कोई उसके साथ अपने काम को करने के लिए ठीक है (यह अच्छा या बुरा हो)। वह डिजाइन प्रक्रिया को चकमा दे रहा है, आखिर!
3. अतिरिक्त घंटे का भुगतान किया जाता है या नहीं।

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

Answer 10

यह स्क्रम के एक किरायेदार का उल्लंघन करता है क्योंकि टीम स्प्रिंट में काम का फैसला नहीं कर रही है। यह एक स्क्रैम टीम है । टीम को इस प्रोग्रामर को अनुशासित करने की आवश्यकता है यदि अनुशासन को सौंपना है।

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

टीम (पीओ या स्क्रममास्टर नहीं) को दुष्ट प्रोग्रामर के साथ संबोधित करना होगा।

Comments

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

— नावक

रुको, मुझे लगा कि चुस्त विकास का मंत्र "लोग, प्रक्रिया नहीं" था?

— चार्ल्स ई। ग्रांट

सौभाग्य इस तरह के दृष्टिकोण के साथ एक वास्तविक, सफल स्टार्टअप उत्पाद का निर्माण करता है।

— केल्सीदह