कार्यस्थल में चंचलता का परिचय देने के प्रभावी तरीके?

Question

आपके अनुभव (उपाख्यान या अन्यथा) में, एजाइल को एक गैर-चुस्त संगठन या कंपनी में पेश करने के कुछ प्रभावी तरीके क्या हैं?

अद्यतन: क्या कोई उन मामलों पर बात कर सकता है जहाँ आपने एजाइल को पेश करने की कोशिश की थी, लेकिन आपको "गोली मार दी गई"? इसके अलावा, क्या अब आपको पूर्वव्यापी समझ है कि आपको "शॉट डाउन" क्यों किया गया था?

Comments

अपने संगठन को बदलें डायरी एक व्यक्ति के नीचे से परिवर्तन को प्रभावित करने का प्रयास करता है।

— सैम हसलर

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

— NoChance

यह "एक आदमी" ( जेम्स शोर ) - इस डायरी को लिखने के वर्षों बाद - एक बहुत ही सफल चुस्त कोच और लेखक

— किमी

Answer 1

यह बहुत महत्वपूर्ण नहीं है। जब तक तुम जन्नत में रहते हो। विशिष्ट चरणों के लिए आप पूरी निष्ठा से फियरलेस चेंज की एक प्रति लेने की सलाह दे सकते हैं

• सबसे पहले मैनेजमेंट बैकिंग लें । यदि आप कुछ नहीं करते हैं, तो इसके लिए कुछ भी नहीं किया जाएगा .. यदि ऊपरी स्तर पर सभी 'अंतिम समय सीमा है ..', 'अगले 3 महीनों के लिए कार्य सप्ताह', 'जब आप होना चाहिए तो आप परीक्षण क्यों लिख रहे हैं कोडिंग? .. हम बाद में परीक्षण कर सकते हैं। ' डोडो बस नहीं उड़ जाएगा।
• देखें कि क्या आपके संगठन की संस्कृति चुस्त है। यह कुछ ऐसा था जो मुझे याद था .. पुस्तक से एक पंक्ति उधार लेने के लिए .. प्रक्रिया आसान हो जाएगी यदि संस्कृति नए विचारों का समर्थन करती है और पोषण करती है, लोगों को सीखने और नई चीजें करने के लिए समय की अनुमति देती है, जो नवाचारों का समर्थन करने के लिए पर्याप्त है दीर्घकालिक लाभ और विफलता को मौत की सजा नहीं मानते
• लोग : इनोवेटर्स को पहचानें: शुरुआती दत्तक: शुरुआती बहुमत: देर से बहुमत: लैगार्ड्स अनुपात। पहले 3 शुरू में आपके लक्षित दर्शक हैं .. लगभग 30-40% होना चाहिए .. जो आपको रोलिंग प्राप्त करने के लिए महत्वपूर्ण द्रव्यमान देता है। परेशानी यह है कि चंचल कमरे में हाथियों पर स्पॉटलाइट को बदल देता है .. कमियां और मुद्दे आसानी से दिखाई देते हैं .. यदि आप एक जगह पर रहते हैं जिसमें "बोजो एक्सप्लोसन" (गाय कावासाकी के पद को उद्धृत करना) है , तो परिवर्तन वास्तव में होगा। धीमी और दर्दनाक .. अगर बिल्कुल। हमारे पास यह मानने की प्रवृत्ति है कि यदि कोई विचार अच्छा है, तो उसे स्वीकार कर लिया जाएगा। सच नहीं। समाजशास्त्रीय कारणों के बहुत सारे अपने सिर उठाते हैं।
• अगला एक बार में बहुत सी चीजों की कोशिश न करें। इसे धीमा लो .. आसान लो । चाल एक रिफैक्टिंग-विरासत-कोड-जैसे दृष्टिकोण का उपयोग करना है। इधर-उधर छोटे-छोटे घाव खोजें और फुर्तीली पट्टी से थपथपाएं। सुनिश्चित करें कि लोग अभ्यास और लाभों को समझते हैं और उन्हें समय के साथ अपनाना चाहिए। सब कुछ चिपक नहीं जाएगा, लेकिन जल्द ही यह पूरी तरह से बेहतर हो जाएगा। कैसे जल्द ही कई चर पर निर्भर करता है, जिनमें से कुछ आपके नियंत्रण से बाहर हैं।
• यह ऐसा करने के लिए एक बहुत बड़ा व्यक्तिगत निवेश है । पुन: जांच करें कि क्या आप यह कमिटमेंट करने के लिए तैयार हैं और यह उतार-चढ़ाव से गुजरता है। इसके अलावा, आप किसी और को या उससे अधिक के लिए बेटन को सौंप सकते हैं .. अधिक से अधिक अच्छे के लिए परिवर्तन स्वामित्व को त्यागने के लिए तैयार रहें। 'इट्स माय बेबी' सिंड्रोम में मत पड़ो।
• फुर्तीली प्रत्येक टीम, प्रत्येक संगठन के लिए अलग-अलग होती है .. जो कुछ भी आप पढ़ते हैं / प्रस्ताव करते हैं वह काम नहीं करेगा .. स्वीकृति को उन चीजों के प्रति मार्गदर्शन करें जो आपके परिदृश्य के लिए काम करेंगे। अन्य तरीके खोजें जो उन प्रथाओं की भरपाई करते हैं जो जड़ नहीं लेते थे।

आशा है कि समझ में आया .. जैसा कि आप अनुमान लगा सकते हैं कि मैं कुछ समय के लिए इस पर रहा हूँ :)

Comments

एक भयानक प्रतिक्रिया। मैंने यह भी पाया है कि उच्च-मूल्य, कम लागत वाले गी-गॉज़ (जैसे निरंतर एकीकरण) को जोड़ने से ध्वज को उड़ने में मदद मिल सकती है।

— जेरेमी मैकगी

Answer 2

टीम, प्रबंधन, हितधारकों को सुनें और सुराग के लिए सुनें। वे कई क्षेत्रों में दर्द महसूस कर रहे हैं जो फुर्तीले सीधे संबोधित करते हैं।

उन सुझावों पर टिकें जो सीधे उन दर्द को कम कर सकते हैं। "आप ऐसा नहीं कर सकते जो आप महसूस नहीं कर सकते" - तो बोलने के लिए।

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

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

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

सौभाग्य!

Answer 3

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

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

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

Answer 4

यह उनके गले नीचे क्रैम, लेकिन उनके बिना देख;)

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

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

Comments

बस उत्सुक। लेकिन "इसे अपने गले के नीचे दबाएं" और "कुंजी इसे धीमी गति से लेना है" बाधाओं पर लगता है :-) मैं सहमत हूं कि प्रिंसिपल को लागू करने से प्रबंधन दिखा सकता है (जिनमें से मैं एक हूं!) कि ये बदलाव फायदेमंद हो सकते हैं।

— मार्क

धीरे-धीरे और धीरे से उनके गले को रगड़ें।

Answer 5

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

Answer 6

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

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

सधन्यवाद

Answer 7

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

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

Answer 8

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

हालाँकि मैं देख रहा हूँ कि प्रमुख मुद्दा यह है कि एजाइल को आपके "ग्राहक" या ग्राहक प्रतिनिधि से चल रही प्रतिक्रिया की आवश्यकता है।

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

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

Answer 9

चरण 1: सुनिश्चित करें कि आपकी परियोजना में एक गोमांस बैकलॉग है, और सुनिश्चित करें कि यह प्राथमिकता है

चरण 2: SCRUM प्रथाओं (प्रबंधनीय पुनरावृत्तियों, दैनिक स्टैंडअप, स्क्रैम-मास्टर, उत्पाद-स्वामी, बर्बर चार्ट) का परिचय दें

चरण 3: प्रत्येक पुनरावृत्ति उपस्थित टीम परिणाम के साथ होती है

उसके बाद ...
TDD / BDD लागू करें, जोड़ी प्रोग्रामिंग, कोड समीक्षा (सभी बहुत धीरे से), और यदि आपके पास एक अच्छी पर्याप्त टीम है, तो सभी को सह-स्थित (यदि संभव हो तो एक टीम-कमरा) प्राप्त करें।

इन सबसे ऊपर, समझें कि प्रतिरोध (WILL BE) होगा, इसलिए इसे प्रबंधित करने के लिए तैयार रहें।

याद रखने वाली एक और बात यह है कि यदि आप किसी संगठन (बड़े या छोटे) का हिस्सा हैं जो कि समग्र रूप में इन सर्वोत्तम प्रथाओं का पालन नहीं करेगा तो आपको यह महसूस करने में थोड़ा समय लग सकता है (यदि कभी भी) आप प्रगति कर रहे हैं।

Answer 10

लोग हमेशा परिवर्तन के लिए प्रतिरोधी होते हैं, और घोटाले के लिए आगे बढ़ना बहुत बड़ा है। प्रेरणा और दिशा प्रमुख हैं।

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

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

एक बार जब लोग प्रेरित होते हैं और उन्हें इस बात का अंदाजा होता है कि उन्हें क्या करने की ज़रूरत है, तो आपको अपनी पहली प्लानिंग मीटिंग करने की ज़रूरत है और स्क्रैम (स्क्रैममास्टर, दैनिक मीटिंग आदि) के ज़रूरी हिस्से सेट करने होंगे।

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

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

सौभाग्य!

Answer 11

• सफलता का प्रदर्शन - मार्क का जवाब देखें
• उन सिद्धांतों / तकनीकों पर विशेष ध्यान दें जो कंपनी में उच्चतम प्रभाव का कारण बनें
• याद रखें कि यह चुस्त सिद्धांतों के बारे में है, न कि एक प्रक्रिया चेकलिस्ट के बारे में

Answer 12

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

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

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

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

1) आप मौजूदा काम कतारों के प्रबंधन के लिए थोड़े कम समय में स्क्रैम का उपयोग करना शुरू कर सकते हैं। लेकिन कंबन में भी देखो।

2) कुछ नए प्रोजेक्ट पर अधिक सख्त रूप में स्क्रम का उपयोग करना शुरू करें, जिसमें नवाचार, प्रारंभिक प्रतिक्रिया और जहां बहुत कुछ अज्ञात है, की आवश्यकता होगी। आप बॉस / उत्पाद स्वामी को सुझाव दे सकते हैं कि इस नई परियोजना के लिए स्क्रैम आदर्श होगा।

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

यह विकास और उत्पाद प्रबंधन से एकजुट प्रयास करने के लिए प्रयास करना चाहिए।

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

मेरे अनुभव में पहले शुद्ध रूप में स्क्रैम को पेश करना आसान है, फिर अधिक रखरखाव प्रकार के काम की कतार के लिए उस पर आसानी। यह दूसरी तरह से कठिन है।

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

Answer 13

कुछ साल पहले, मैं एक बहुत बड़ी कंपनी (लगभग 20,000 कर्मचारी) में सलाहकार था जो कई बड़े उद्यम सॉफ्टवेयर प्रोजेक्ट चला रहा था। मैं उनमें से एक पर था। एक बहुत महत्वपूर्ण एक।

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

मुझे मजबूत अनिच्छा का सामना करना पड़ा, इसलिए मैंने कुछ समय के लिए विचार छोड़ दिया। लेकिन समस्याओं को टीम लीडर के प्रायोजक के साथ जोड़ना जारी रखा, हमने अंततः स्क्रम बनाने का फैसला किया, ourselve द्वारा।

मेरे सहित किसी को भी, स्क्रेम के साथ कोई भी अनुभव था। इसलिए हमने ऐसा करके रूपरेखा की खोज की ...

आज, एक प्रमाणित ट्रेनर द्वारा प्रशासित कार्यक्रम के माध्यम से पूरे उद्यम के लिए स्क्रम को सामान्यीकृत किया जाता है। मुझे नहीं पता कि हमारी पहल ट्रिगर थी या नहीं। उस ने कहा, मुझे पता है कि यह काफी कठोर कंपनी में एक वास्तविक क्रांति थी।

मुझे लगता है कि इस तरह से एक उद्यम में कुछ पेश करना चाहिए, आपको निम्नलिखित सिद्धांतों का सम्मान करना चाहिए:

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

• हमें प्रबंधन की समस्याओं पर ध्यान देना चाहिए और डेवलपर्स की समस्याओं का उल्लेख नहीं करना चाहिए , जब तक कि वे प्रबंधन की चिंताओं का हिस्सा न हों। दूसरे शब्दों में, आपको उनके लिए समाधान लेकर आना चाहिए, न कि आपके लिए। अपने आप को प्रबंधन के जूते में रखो। उनकी चिंताएं क्या हैं?

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

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

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

पुस्तक के बारे में केन के एक ब्लॉग पोस्ट में आप पढ़ सकते हैं:

जेफ सदरलैंड और मैंने इसे किया है। हमने साथ में एक पुस्तक लिखी, 1995 में स्क्रम के प्रारंभिक प्रकाशन के बाद हमारा पहला संयुक्त लेखन। हमें क्या संकेत दिया? जो प्रश्न हम अक्सर पूछे जाते हैं:

हम अपने प्रबंधन को स्क्रैम कैसे बेचते हैं?

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

हमने किताब लिखने के लिए 2011 की अंतिम छमाही बिताई। कोई भी प्रबंधक, ऊपर से नीचे तक, आसानी से उठा सकता है और इस पुस्तक को पढ़ सकता है।

[...]

Answer 14

हम इसे हर समय देखते हैं। (पूर्ण प्रकटीकरण: मैं एक परियोजना प्रबंधन अनुप्रयोग विकसित कर रहा हूं)। समस्या यह है कि चुस्त कार्यप्रणाली पारंपरिक रूप से प्रबंधित संगठनों में एक अंतर्निहित तनाव का परिचय देती है। आमतौर पर, ऊपरी प्रबंधन आगे की योजना बनाने में सक्षम होना चाहता है। वे 3 साल की योजना चाहते हैं; वे ठीक से अनुमानित परियोजनाएं चाहते हैं; वे नए लोगों को काम पर रखने में सक्षम होना चाहते हैं; जब वे भागीदारों / ग्राहकों की बात करते हैं, तो वे महत्वपूर्ण मील के पत्थर के लिए प्रतिबद्ध होना चाहते हैं।

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

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

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

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

ठीक है, मुझे लगता है कि यह बिक्री की पिच में बदल रहा है, इसलिए मैं अभी रुकूंगा। :)