सात स्क्रैम कार्यान्वयन के मुद्दे जिनके बारे में हमें जानकारी नहीं थी

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

कुछ कर्मचारियों को बदलने के लिए मौलिक रूप से विरोध किया जाता है

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

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

इस मामले में सबसे उचित समाधान लोगों को अन्य परियोजनाओं में स्थानांतरित करना है। यह आवश्यक रूप से किया जाना चाहिए, क्योंकि नकारात्मक विकिरण करने वाला व्यक्ति सभी को प्रभावित कर सकता है। हमारे इतिहास में, यह वही है जो हमारे सामूहिक ने ठीक किया है - सामान्य तनाव गायब हो गया है, और हर कोई नई जानकारी की धारणा के लिए तैयार है।

परिवर्तनों की एक नकारात्मक प्रतिक्रिया उम्र पर निर्भर नहीं करती है। जिन डेवलपर्स के बारे में हमने ऊपर बात की, वे 30 साल से थोड़े ज्यादा थे। उसी समय, एक व्यक्ति जो पहले से ही 50 से अधिक है, हमारी टीम में पूरी तरह से काम कर रहा है - उसे स्क्रम के साथ कोई समस्या नहीं थी।

यह उन लोगों के साथ बातचीत करना कठिन है जो स्क्रम द्वारा नहीं जीते हैं।

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

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

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

"हम स्प्रिंट के लिए समय में नहीं होंगे!"

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

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

यह दृष्टिकोण प्रेरणा को बढ़ाता है, असफल नियोजित डेमो के बाद, काम की जिम्मेदारी बढ़ती है। यदि पहले डेवलपर्स ने पांच मिनट में डेमो के लिए स्टैंड तैयार किया था, तो अब वे इसे डेमो से एक दिन पहले करते हैं, और फिर वे सब कुछ सुपर बनाने के लिए शेष बंप्स को पॉलिश करते हैं।

"हमें दैनिक स्टैंड-अप की आवश्यकता क्यों है?"

सबसे पहले, सहकर्मी हर दिन स्टैंड-अप बैठकों में अपने सामान्य काम से विचलित होने के बारे में उलझन में थे। भले ही वे ऑनलाइन आयोजित हों और केवल 10 मिनट की आवश्यकता हो।

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

बहुत से लोग सोचते हैं कि स्क्रैम मीटिंग में बहुत समय लगता है। यहां यह गणना करना पर्याप्त है कि क्या वास्तव में ऐसा है। हमें 40 में से सप्ताह में दो घंटे मिलते हैं। काम को व्यवस्थित करने और सभी चीजों के साथ अद्यतित रहने के लिए ऐसा नहीं है।



यदि पूरी टीम स्टैंड-अप मीटिंग्स में नहीं जाना चाहती है, और मीटिंग्स स्वयं बहुत सक्रिय नहीं हैं, तो यह एक संकेत है कि काम गलत हो रहा है। जैसे कि बैठक में 15-20 मिनट से अधिक की देरी हो। एक व्यक्ति में उसकी गतिविधियों और योजनाओं के बारे में एक कहानी को एक या दो मिनट से अधिक नहीं लेना चाहिए।

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

असंगत बैकलॉग

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

अनुचित micromanagement

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

लगभग कुछ भी कभी नहीं लिखा है

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

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

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