क्यों और किन कारणों से डेवलपर्स "दैनिक स्क्रैम" पसंद नहीं कर सकते हैं? [बन्द है]

Question

दैनिक घोटाले को पकड़ने में फायदे हैं, जैसे:

1. टीम एक दूसरे के साथ समन्वित हो जाती है
2. सभी जानते हैं कि किस राशि का कितना कार्य किया गया है
3. Burndown चार्ट अधिक से अधिक पूरा हो जाता है
4. टास्क बोर्ड अपडेट किया गया है
5. यह इतना अधिक नहीं है, 15 मिनट किसी को नहीं मारेंगे

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

मुझे अभी पता नहीं है कि इसमें क्या गलत हो सकता है। क्या किसी टीम के लिए "दैनिक स्क्रैम" के नुकसान के लिए कहीं कारण बताए गए हैं? डेवलपर्स के दैनिक घोटाले से थकने के क्या कारण हो सकते हैं?

Comments

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

— maple_shaft

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

— maple_shaft

ईमानदारी से, मुझे वास्तव में हर दिन एक बैठक में जाने और हर किसी को यह बताने के लिए नफरत होगी कि मैंने क्या किया है। मैं काम करने की कोशिश कर रहा हूं । बैठक के आसपास "वायुमंडलीय" - संदर्भ स्विचिंग, दालान की चैट, कमरे के लिए इंतजार - वोह की तरह समय खाने के लिए जा रहे हैं। बेहतर - IMO - आवश्यकतानुसार जैविक बैठकें करना।

— पॉल नाथन

स्क्रेम को भूल जाइए। sdtimes.com/blog/post/2011/11/11/Agile-slaves.aspx

— थॉमसएक्स

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

— एक्यूमेनस

Answer 1

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

बहुत जल्दी 15 मिनट की बैठकें 45 मिनट की बैठकें बन गईं, अपडेट अप्रभावी थे क्योंकि लोग दूसरों की बात सुनने के बजाय "जब हम पहले से ही जा सकते हैं, तो" जम्हाई लेने और सोचने में व्यस्त होंगे, और यह लोगों की दिनचर्या भी तोड़ देगा (उदाहरण के लिए, मैं हूँ एक उल्लू व्यक्ति, और हर दिन इस बेवकूफ बैठक के लिए सुबह 9 बजे काम करना मेरे लिए नौकरी छोड़ने का एक अच्छा पर्याप्त कारण है)।

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

मुझे यकीन है कि बहुत सारे SCRUM उत्साही होंगे जो कहेंगे "लेकिन यह बहुत अद्भुत है" - ठीक है, इसे बचाओ, मैंने यह सब सुना है।

Comments

जब 'पिछले दिन' पर चर्चा की जाती है, तो इसका मतलब अंतिम बैठक के बाद से होता है और लगभग 24 घंटे का आयोजन होता है। जब आप दिन की शुरुआत करते हैं या कुछ घंटे बाद करते हैं तो कोई कारण नहीं हो सकता है। सभी को एक ही समय में कोड करने के लिए मजबूर नहीं किया जाता है।

— जेफ़ो

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

— ०४:१४ बजे

@littleadv: "मैं एक्स पर काम करना जारी रख रहा हूं। मेरे पास कोई बाधा नहीं है" एक स्क्रैम मीटिंग के लिए पर्याप्त है। टीम के लिए यह महत्वपूर्ण जानकारी है। जैसा कि केवल विज्ञापन-विकास के विकास के लिए अच्छे होने के कारण, मुझे असहमत होना पड़ेगा। मैंने इसे लंबे, निरंतर, सफल परियोजनाओं के लिए इस्तेमाल किया है । यह पूरी ईमानदारी से करने के लिए टीम पर निर्भर है, लेकिन यह चांदी की गोली नहीं है। यह कुछ टीमों के लिए काम करता है, दूसरों के लिए नहीं।

— ब्रायन ओकले

+1 मैं एक दैनिक घोटाले से कभी नहीं मिला, जिसमें 15 मिनट लगे। अधिकांश कम से कम आधा घंटा लेते हैं, और बहुत तेजी से फोकस खो देते हैं :( मुझे लगता है कि शॉर्ट स्टेटस अपडेट में वैल्यू है, लेकिन दुर्भाग्य से किसी भी दुकान में मैंने इसे कम रखने में काम नहीं किया।

— एंड्रेस एफ।

एक और समस्या यह है कि जब "देवों ने हमें बताया है कि" बैठक बन रही है "तो देवों ने अपने विचारों के बारे में हम सभी को बताया कि वे आगे कहाँ जाएँगे।" बहुत अलग है, और अधिक समय लेता है। और फिर प्रबंधन सोचता है, ओह, क्योंकि हम सभी यहाँ वैसे भी हैं, इस बैठक में एक और बैठक करने की अनुमति देता है!

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

Answer 2

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

• साझा की जा रही जानकारी कभी भी किसी भी तरह से मुझे प्रभावित या प्रभावित नहीं करती है।
• टीम के स्वामित्व की अनुपस्थिति और हर कोई हमेशा अपनी परियोजनाओं पर काम कर रहा है।
• स्टैंडअप के बाहर टीम संचार की अनुपस्थिति।
• दिखाई या संचारित प्रगति का अभाव।
• साझा करने के लिए जानकारी की अनुपस्थिति।

ये मेरे सिर के ठीक ऊपर हैं, लेकिन हमेशा अधिक संभावित कारण होते हैं।

शायद आपको डेवलपर्स से सीधे पूछना चाहिए कि वे रुचि क्यों नहीं दिखा रहे हैं? यदि आप अधिक / बेहतर संचार चाहते हैं तो यह आपके साथ शुरू होना चाहिए।

Comments

लेकिन @dietbuddha, यदि यह डेवलपर्स जानकारी या परियोजना के कुछ हिस्सों को साझा नहीं करता है, तो यह कैसा है?

— सईद नेमाटी

" साझा की जा रही जानकारी कभी भी किसी भी तरह से मुझे प्रभावित या प्रभावित नहीं करती है। "

— रेने Nyffenegger

@ सईद नेमाती: एक बात जरूरी नहीं है कि जिसके लिए इसे नाम दिया जाए। इसका मतलब यह नहीं है कि आप स्क्रैम नहीं कर रहे हैं। मैं आपके साथ काम नहीं करता, इसलिए मैं नहीं जान सकता। इस बात में भी अंतर हो सकता है कि चीजों को कैसे किया जाता है और वे वास्तव में कैसे किए जाते हैं।

— डायटबुद्ध

Answer 3

दैनिक SCRUM बैठकों के साथ आने वाली समस्याओं में से कुछ:

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

Comments

@ हॉकिंग: वास्तव में, प्रबंधकों के लिए मीटिंग्स (या स्टेकहोल्डर्स, या सिर्फ किसी की दिलचस्पी रखने वाले) के बारे में होना ठीक है। हालांकि, नियम यह है: केवल डेवलपर्स बात करते हैं। बाकी सब लोग केवल तभी बोलते हैं जब उनसे पूछा जाता है। यह इतना आसान है ... (और हां, हमारे प्रबंधक दैनिक जांच में भाग लेते हैं, और वे उस नियम का पालन करते हैं)।

— 8

यदि आपके प्रबंधक उन नियमों से चिपक सकते हैं जो महान हैं।

— झॉकिंग

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

— mikołak

अपने अंतिम बिंदु के लिए +1 (योजना जब काम में रुकावट नहीं है, यानी वह चीज जो मैं रात को पहले नहीं कर सकता था या घर के बारे में एक शानदार विचार था)।

— सीस टिमरमैन ३०'१५ को

Answer 4

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

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

Comments

+1 मुझे प्रक्रियाओं के साथ एक ही समस्या है जो बहुत सी बैठकों को निर्धारित करती है। Paulgraham.com/head.html , अंक 1 और 2 को भी देखें

— जियोर्जियो

Answer 5

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

उदाहरण के लिए, एक टीम को विभिन्न परियोजनाओं पर शॉर्ट बग फिक्स की श्रृंखला करने के लिए सौंपा गया है। वे वास्तव में एक टीम के रूप में नहीं बल्कि व्यक्तियों के रूप में काम कर रहे हैं। हालाँकि, क्योंकि कंपनी / विभाग की नीति इसे अनिवार्य करती है, टीम लीड / मैनेजर वैसे भी दैनिक स्क्रैम मीटिंग आयोजित करता है। जो कुछ पूरा हो गया है, वह बेकार बैठक के लिए 15+ मिनट निकाल रहा है और बैठक से पहले और बाद में 15-30 मिनट की व्याकुलता और उत्पादकता की कमी से निपट रहा है।

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

Answer 6

सुनिश्चित करें कि कोई भी बैठक का एकाधिकार नहीं करता है।

यदि 5 में से 4 डेवलपर्स को अपना स्पिल आउट मिलता है, और अगले 10 मिनट टीम लीडर को सुनते हुए बिताए जाते हैं , तो उसके द्वारा किए गए अद्भुत , भयानक नए घटनाक्रमों का विस्तार से वर्णन किया जाता है, जिनमें से अधिकांश न तो अद्भुत हैं और न ही उतने ही भयानक हैं। जैसा कि वह सोचता है कि वे हैं, लोग बहुत जल्दी ऊब जाएंगे।

---

एक पल पीछे खड़े होकर अपनी टीम के बारे में सोचें:

• क्या वे प्रभावी ढंग से काम कर रहे हैं?
• क्या कार्य समय पर पूरे होते हैं?
• क्या कोड मजबूत और अच्छी तरह से लिखा गया है?
• क्या टीम यह सुनिश्चित करती है कि दरार के माध्यम से कुछ भी नहीं गिरता है?
• क्या टीम खुद को समेटती है ताकि वे एक दूसरे के पैर की उंगलियों पर काम न करें या न करें?

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

क्या उत्पादकता में गिरावट आई है क्योंकि दैनिक जांच बंद हो गई है, या सब कुछ पहले जैसा ही है? अगर कुछ नहीं बदला है, तो बैठकें क्यों जारी हैं?

Answer 7

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

यदि आप बोर्ड और चार्ट को बार-बार अपडेट करना चाहते हैं, तो ड्राफ्ट कॉपी को विकी पर डालें।

Answer 8

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

मेरा व्यक्तिगत अनुभव:

• उद्देश्य यह जानना है कि हम आज क्या कर रहे हैं और कल हम कहां थे। एजेंडा से चिपके रहने के बजाय, यह 2 व्यक्तियों के बीच अवरोधकों की एक तकनीकी चर्चा में उतर जाता है और अन्य 15 ऊब जाते हैं। समस्या को पहचानें लेकिन बाहर चर्चा करें
• लोग समय पर बैठक कक्ष में नहीं आते हैं, और यह कुछ उद्देश्य से किया गया एक चक्र बन जाता है। तो स्क्रैम मास्टर को बैठक से बाहर उनके साथ एक शांत चर्चा करने की आवश्यकता है ताकि यह सुनिश्चित हो सके कि वे समय पर शुरू और समाप्त हों।
• हम पहले से ही स्क्रैम मीटिंग के बाहर बुंडाउन चार्ट को अपडेट करते हैं ताकि दैनिक स्टैंड-अप का मुख्य उद्देश्य न हो।

Comments

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

— माइकल ड्यूरेंट

Answer 9

प्रतिरोध तब आता है: 1) इनका उपयोग लोगों को सुबह 9 बजे तक दौड़ने के लिए मजबूर करने के लिए किया जाता है। ट्रेन के लेट होने पर यह अतिरिक्त तनाव है। 2) गरीब घोटाला नेतृत्व। नेता को लोगों से यह कहना चाहिए कि वे सामानों को हटाने की बजाय लाइन में लगें ताकि लोग कुछ ऐसा सुनें जो उन्हें प्रभावित न करे। 3) वैधता सामग्री। यह फिर से एक घोटाला नेतृत्व का मुद्दा है। यह अड़चनों, प्रक्षेपवक्र मुद्दों और संभावित सहयोगों को संबोधित करने के लिए एक मंच माना जाता है। वास्तव में क्या होता है, हर कोई बस यही कहता है कि वे उस दिन काम करने की उम्मीद करते हैं जो किसी और के लिए किसी काम या हित का नहीं है। ४) खड़े होना। मैं खड़े होने के लिए खड़ा नहीं होगा। खड़े होने के पीछे तर्क यह था कि यह लोगों को संक्षिप्त होने के लिए प्रोत्साहित करता है। लोग वास्तव में सिर्फ परवाह किए बिना खड़खड़ करते हैं।

Answer 10

मैं प्रबंधित हूं और कई बार स्क्रैम टीमों का हिस्सा रहा हूं। डेवलपर्स को घोटाले पसंद नहीं हैं इसका मुख्य कारण है:

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

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

Answer 11

सच कहूँ तो, मैं चली गई दैनिक स्क्रैम बैठकों के 99% में, बहुत सारी चर्चा / सवाल / जवाब कुछ ईमेल के साथ भेजे जा सकते थे।

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

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

मैं व्यक्तिगत रूप से सोचता हूं कि यदि आपके पास 8 घंटे की अवधि में चार से अधिक बैठकें हैं तो परियोजनाओं को अच्छी तरह से प्रबंधित नहीं किया जा रहा है।

Comments

यह पूछे गए प्रश्न का उत्तर देने का प्रयास भी नहीं करता है: "क्यों और किन कारणों से डेवलपर्स" दैनिक स्क्रैम "पसंद नहीं कर सकते हैं?"

— gnat

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

— एलेक्स एम

दिलचस्प सोचा ... और शायद यह इसलिए है क्योंकि मेरे घोटाले के अनुभव अच्छे नहीं थे। शायद "दैनिक" कुछ मामलों में "साप्ताहिक" होना चाहिए। मुझे पता है कि मेरे लिए एक साप्ताहिक दैनिक की तुलना में अधिक प्रभावी होगा।

— एलेक्स एम।

Answer 12

कई कारक हैं जो बैठकों में तनाव में योगदान करते हैं। इन कुछ महत्वपूर्ण कारणों पर विचार करें कि बैठकें आपकी लागत से अधिक क्यों हो सकती हैं:

• फोकस - सॉफ्टवेयर बनाम मीटिंग्स
• प्रबंधन - प्रबंधकों को माप की आवश्यकता है
• व्यक्तित्व - परिचय बनाम बहिर्मुखता
• समय - व्यवधान, निर्माता और प्रबंधक का समय
• लक्ष्य, प्राथमिकताएँ

उन कारकों में से प्रत्येक को नीचे समझाया गया है,

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

डेवलपर्स को विचलित होने से बचने की जरूरत है, और कई लोग पाते हैं कि देर रात को कोड करने के फायदे हैं (वे शोर, फोन कॉल, व्यस्त कार्यालय और गैर-डेवलपर सहयोगियों को अपने काम में बाधा डालने से बचाते हैं)। और जब आपने 10, 11 या 12 बजे तक काम किया है, तो बाद में काम पर आना अनुचित नहीं है (10, 11, दोपहर?)। क्या डेवलपर्स को रात 9 बजे से आधी रात तक काम करने की उम्मीद करना उचित है?

स्क्रम (और कोई भी) बैठकें डेवलपर को उनके प्राथमिक उद्देश्य से विचलित करती हैं, जो सॉफ्टवेयर का निर्माण कर रहा है।

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

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

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

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

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

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

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

Answer 13

यह सुनिश्चित करने के लिए बैठक को संशोधित करें कि यह लाभ पहुँचाता है:

1. इसे उस समय पर शेड्यूल करें जो कुछ सुविधा प्रदान करता है। काम शुरू होने के 30 मिनट बाद ऐसा क्यों नहीं हो सकता है इसलिए हर कोई ईमेल की समीक्षा कर सकता है और मीटिंग के लिए अपने विचारों को व्यवस्थित कर सकता है। Brevity नियोजन लेता है। बिना तैयारी के हमेशा के लिए घूम सकते हैं।
2. बैठक के दौरान जिन समस्याओं से बचा जा सकता था, उनकी पहचान करें। सभी को समझने की जरूरत है कि बिंदु क्या है।
3. हर किसी के इनपुट को कम से कम रखने के लिए जो भी करना है वह करें। यह बहस का स्थान नहीं है। चर्चा के लिए एक विषय पर केंद्रित दैनिक बैठक के बाहर निजी तौर पर बैठकों का समय निर्धारित करने के लिए लोगों को प्रोत्साहित करें। नियम: एक समय में केवल एक ही व्यक्ति बात करता है।

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