मुझे लगता है कि अन्य लोगों ने पहले से ही अच्छे जवाब दिए हैं, लेकिन मैं केवल इसलिए जोड़ दूंगा क्योंकि मुझे लगता है कि आपकी टीम सिर्फ स्क्रेम से संक्रमित है और अब आप लोग बहुत समान स्थिति में हैं जब हम शुरू हुए थे।
सबसे पहले, चंचल और अधिक विशेष रूप से स्क्रम से हमारा परिचय बहुत सहज नहीं था। मूल रूप से प्रबंधन नीचे आया और कहा, इस दिन से आप स्क्रैम करेंगे और यह एक प्रक्रिया है जिसका आप सभी पालन करेंगे। प्रोसेस के लिए लोगों के लिए बहुत कुछ ।
जिस प्रक्रिया का हम मूल रूप से पालन करते थे (नेत्रहीन, मैं जोड़ सकता हूं) आपने जो वर्णित किया था, उसके समान ही समाप्त हो गया। लोगों को असाइन किए गए कार्य मिलते हैं, हर कोई बुक हो जाता है और हम सभी अपने डेस्क पर वापस जाते हैं और दूर जाते हैं। फिर हम हर दिन एक उबाऊ स्टैंड अप मीटिंग करते हैं।
एहसास करने की कुंजी यह है कि एजाइल, और स्क्रैम शामिल हैं, वास्तव में लोगों के बारे में है। जब टीम पुनरावृत्ति नियोजन में जाती है, तो अपने स्क्रेम मास्टर (जो शायद आपके प्रबंधक हैं) को आपको घंटे, कहानी और कार्य सौंपने न दें। यह टीम के लिए पूरी तरह से यूपी है। मुझे लगता है कि बहुत से लोगों के लिए यह एक बहुत ही कठिन अवधारणा है क्योंकि इससे पहले कि वे काम पर आएंगे और उनके पास एक बॉस (प्रबंधक, तकनीकी नेतृत्व ...) होगा जो बस काम सौंपेंगे। वे स्क्रम में गोता लगाते हैं, लेकिन सभी (स्क्रम मास्टर सहित) उसी मोड में काम करना जारी रखते हैं।
एक दिन, आप इससे बीमार हो जाएंगे, इसलिए आप किताबें, ब्लॉग पढ़ना शुरू कर देंगे और स्टैक एक्सचेंज पर इस तरह के सवाल पूछते रहेंगे। आपको जो अहसास होगा वह यह है कि आप डेवलपर के रूप में और आपके टीम के साथी कहानियों के लिए प्रतिबद्ध होने और कार्यों को असाइन करने के पीछे प्रेरक शक्ति होनी चाहिए। यदि आप लोग महसूस करते हैं कि आप जोड़ी प्रोग्रामिंग से लाभान्वित होंगे, तो हर तरह से इंजीनियरों में से प्रत्येक के लिए एक 2 कार्य बनाएं और दोनों को एक घंटे में असाइन करें। केवल एक चीज जो स्क्रेम मास्टर कर रहा है, वह पूर्ण कहानियों के खिलाफ वेग को माप रहा है जो आपने पिछले पुनरावृत्ति में AS TEAM के रूप में दिया था।
इसके अलावा एक और बात जो मुझे बकवास करती है कि कैसे लोगों को बताया जाता है कि उनकी क्षमता कुल घंटों का 75% है, इसलिए वे जो करते हैं और उसके बाद पुनरावृत्ति की पूरी अवधि के लिए वे शिकायत करते हैं कि क) वे नहीं कर सकते आपकी मदद करेंगे या ख) वे सही काम नहीं कर सकते क्योंकि उन्हें बहुत अधिक घंटे दिए गए हैं। लोगों को यह नहीं बताया जाना चाहिए कि कितने घंटे प्रतिबद्ध हैं और उन्हें निश्चित रूप से पीछे धकेलना चाहिए अगर स्कैम मास्टर ऐसा कुछ खींचने की कोशिश कर रहा है! हर किसी को ठीक उसी तरह से काम करना चाहिए, जिसमें वे सहज हों। उदाहरण के लिए, मैं एक टीम का नेतृत्व कर रहा हूं और अक्सर मैं एक यादृच्छिक अनियोजित डिजाइन चर्चा में समाप्त होता हूं, या किसी को कोड के साथ, या अजीब सामान की समस्या निवारण में मदद करता हूं, इसलिए मेरी क्षमता कभी भी 50% से ऊपर नहीं होती है।
हमारी टीम ने 4 रिलीज़ साइकल लीं, जो मैंने अभी-अभी बताई गई चीजों को नहीं करने के लिए सीखी हैं और भले ही हमने निश्चित रूप से सुधार किया है, अगर आप विशेषज्ञों से पूछें कि हम आधी फुर्तीली भी नहीं हैं। इसलिए अभी भी बहुत कुछ करना बाकी है।
अद्यतन 1: क्लिफ की टिप्पणी के जवाब
वैसे आप अपने कान इसलिए यहाँ यह है की पेशकश की ...
आप सही हैं, सांस्कृतिक बदलाव महत्वपूर्ण है, लेकिन कार्यकारी स्तर पर इस बदलाव की आवश्यकता नहीं है। आपका अपना समूह प्रबंधक आपकी टीम के भीतर की संस्कृति को बदल सकता है और आप लोगों को कॉरपोरेट बीएस से अलग कर सकता है जिससे उसे निपटना है। आप जो वर्णन कर रहे हैं वह वास्तव में 2007 से 2010 के बीच था। हमारी टीम (और अन्य टीमों के साथ) रिलीज के बाद फ्लॉप हो गई। प्रबंधन की "चुस्त होने की प्रक्रिया" का उपयोग करते हुए एक रिलीज में, हम 9 लोगों के काम का प्रबंधन करते हैं जो आमतौर पर एक ही व्यक्ति द्वारा किया जाएगा और इसमें हमें दोगुना समय लगा। मेरे पास इतना खाली समय था, कि मैंने अपना रिज्यूमे भी अपडेट कर दिया था।
फिर, मैंने अपने बॉस के साथ एक बातचीत की और उन्हें ये सारी बातें बताईं कि लोगों के बारे में कितनी चुस्त है और अगर आप चाहते हैं कि हम उत्पाद के बारे में परवाह करें, तो हम निर्णय लें कि हम किस तरह से काम करते हैं और उत्पाद को कैसे वितरित करते हैं। मुझे लगता है कि उसने इसे एक प्रयोग करने का फैसला किया, उसने हर एक बदलाव किया ... ठीक है, ज्यादातर मैं खुद, लेकिन मैं बाकी टीम के साथ बहुत बात करता हूं, इसलिए 50% क्षमता :) ... प्रस्तावित। यह संभव है कि उसने सोचा कि यदि वह उन सभी परिवर्तनों को करता है जो हम पूछ रहे हैं और हम अभी भी असफल हैं, तो वह एक विजयी "मैं आपको ऐसा कहा" के साथ वापस आऊंगा।
इसलिए पिछले 12 महीनों में, हमने इतना "बेवकूफ" समाप्त कर दिया है यह भी अजीब नहीं है। हमारी स्टैंड-अप मीटिंग वास्तव में अब समझ में आती हैं क्योंकि हम एक साथ काम करते हैं, अलगाव में नहीं। हमारे पास अभी भी उत्पाद के विशिष्ट भागों का स्वामित्व (अभी के लिए कम से कम) है, लेकिन हम एक-दूसरे के कोड में बहुत बार पार करते हैं। हम लगातार कोड समीक्षा करते हैं ताकि न केवल टीम के सदस्य अन्य कोड सीखें, बल्कि वे बेहतर कोडिंग और डिजाइन तकनीक भी सीखें। हमने 3 अलग-अलग टीमों में अखंड, विशाल "फुर्तीली" टीम को तोड़ दिया है, इसलिए योजना और अन्य बैठकें बहुत कम हैं और लोग वास्तव में उनकी परवाह करते हैं क्योंकि वे आसपास नहीं बैठते हैं और उन चीजों के बारे में सुनते हैं जिनके बारे में वे परवाह नहीं करते हैं। मैं' देखा रातें जब हमारे दोस्तों में से 5 (टीमों में से एक) में से 4 रात में 11 बजे ऑनलाइन होंगे और किसी ने भी हमें वास्तव में नहीं बताया कि हमें कड़ी मेहनत करनी है या कभी हमें 40 घंटे से अधिक काम करने के लिए दबाव डाला है। जो लोग आधे साल पहले कम देखभाल नहीं कर सकते थे, वे अचानक लगे हुए हैं और उस काम के बारे में उत्साहित हैं जो वे कर रहे हैं। और यह सब हमारे प्रबंधक के लिए था कहने के लिए था, "आप लोग तय करते हैं कि क्या सही है और आपको क्या करने की आवश्यकता है और मैं जितना हो सके कॉरपोरेट बीएस को टीम से बाहर रखूंगा।"
यह प्रयोग के रूप में शुरू हुआ (मेरा संदेह, उसने मुझे कभी नहीं बताया), लेकिन अब हमारा समूह विभाग के अन्य विकास समूहों की तुलना में बट किक कर रहा है और हमारे पास अन्य डेवलपर्स भी हैं जो अब हमारे साथ आने और हमारे साथ जुड़ने की कोशिश कर रहे हैं।
यह परिवर्तन हुआ (और आज भी एक समस्या है) हमारे लिए सबसे बड़ी बाधा यह थी कि सामान्य कॉर्पोरेट वातावरण में इंजीनियर एक पिंजरे में प्रयोगात्मक चूहों की तरह होते हैं। यहां तक कि जब आपका प्रबंधक वास्तव में "फुर्तीली" जाने और पिंजरे को हटाने का फैसला करता है, तो हर कोई इतने लंबे समय के लिए उस पिंजरे में रहा है, उन्हें यह भी एहसास नहीं है कि वे स्वतंत्र हैं। इसलिए सभी स्वतंत्रता के साथ, वे अभिनय जारी रखते हैं जैसे कि वे अभी भी विवश हैं। मुझे लगता है कि टीम में कम से कम कुछ लोगों (जैसे खुद) की मदद करने में क्या होगा, जो समूह की सीमाओं के बाहर जाते हैं और चीजों को करने के बेहतर तरीकों की तलाश करते हैं। फिर उस समूह में वापस आएं और इसे थोड़ा हिलाएं।
आपके मामले में, शायद युग्मित प्रोग्रामिंग एक समाधान नहीं है यदि आप टीम में नीचे आने के लिए किसी अन्य बाहरी बल की तलाश कर रहे हैं और उन्हें बताएं कि कैसे काम करना है। इसके बजाय, नियमों को बाहर फेंक दें, बिना प्रबंधन के उनके साथ बैठें, और उनसे पूछें कि वे क्या करना चाहते हैं? क्या उन्हें खुश कर देगा? उत्पादक? सबसे बड़ी समस्याओं की पहचान करें और फिर टीम से पूछें कि उन्हें क्या लगता है कि समाधान होना चाहिए।