पारंपरिक गैर-पुनरावर्तक, विशिष्ट सूची, गैंट चार्ट, चरण निर्भर टीम से कॉर्पोरेट वातावरण में एक टीम को अधिक पुनरावृत्ति दृष्टिकोण में बदलने की चुनौतियों क्या हैं?Agile, वाटरफाल, स्क्रम ... एक टीम को पुनरावृत्ति विकास में बदलने के लिए कितना मुश्किल है?
इसके अलावा, एक नई विकास रणनीति का उपयोग करते समय अन्य समूहों के साथ स्वीकृति प्राप्त करने का एक सफल तरीका क्या था?
हम क्या किया:
प्रबंधन करने के लिए समझाया कि एक योजना (जो भविष्य की भविष्यवाणी करने का इरादा रखता है) बस फुलाना, वाष्प, एक तथ्यात्मक आधार के बिना मान्यताओं की एक सूची है।
स्पिंट की एक सूची की योजना बनाई। एक बर्नडाउन चार्ट लिखा है। संक्षेप में अनुमान लगाने के लिए भूल गए।
स्पिंट की सूची पर निष्पादित करना शुरू किया।
के बाद पहले दो या तीन, प्रबंधन को एहसास है कि "योजना" नहीं "दिनांक", "जोखिम", "अनुमान" या कुछ भी एक पारंपरिक झरना परियोजना योजना की तरह साथ सिर्फ एक burndown सूची थी, शुरू कर दिया ।
इस बिंदु पर, ज़ाहिर है, यह बहुत देर हो चुकी है। हम पहले से ही एक स्प्रिंट पूरा कर चुके हैं और दूसरे के माध्यम से सबसे अधिक तरीके से हैं। घोड़ा बार्न से बाहर है। घंटी पहले से ही rung था।
तो प्रबंधन कुछ सामान मांगता है।
कुल बजट। हमने कहा "उन स्पिंट्स को जोड़ें जो आपके लिए महत्वपूर्ण हैं। बस एक यादृच्छिक रेखा बनाएं, कहीं भी आप खुश हों। यह आपका बजट है।" कोई भी इसे पसंद नहीं करता है, क्योंकि यह बहुत अधिक नियंत्रण है। "आप इसे कैसे औचित्य दे सकते हैं?" उन्होंने पूछा। "आसान। जब तक आप परियोजना को रद्द नहीं करते हैं हम प्राथमिकता क्रम में निर्माण करते हैं।"
हमें जो कुछ जोड़ना पड़ा वह प्रत्येक दौड़ के लिए एक क्षणिक अवधि थी। हमारा परिवर्तनीय आकार है: 2 से 4 सप्ताह। 10 स्पिंट्स की एक सूची लगभग 26 सप्ताह थी - 6 महीने। उसके बाद, हमने संख्याओं को डालने से रोक दिया।
"धारणाओं" की सूची। हमने अभी इनकार कर दिया। "खुद लिखिए"। वे किसी के बारे में नहीं सोच सकते थे। वह यह था कि।
"जोखिम" की सूची। फिर, हमने पूछा कि उन्हें से डरा हुआ था। अगर उन्हें किसी चीज़ से परेशान किया गया था, तो शायद उन्हें उस पते को हल करने के लिए बुद्धिमत्ता में प्राथमिकता बदलनी चाहिए।
एक देय तिथि। हमने इसे चारों ओर बदल दिया और उनसे तारीखों और बजट और जोखिमों के आसपास बर्नडाउन को प्राथमिकता देने के लिए कहा जो उनके लिए महत्वपूर्ण थे। हमें बहुत अधिक ध्यान नहीं दिया गया - यह प्रबंधकों के रूप में उनकी कॉल है।
दो और स्प्रिंट के बाद, वे "झरना" अनुरोध कर बंद कर दिया और प्राथमिकता देने और burndown प्रबंध शुरू कर दिया।
दिलचस्प बात यह है कि उन्होंने कभी भी स्कोप रेंगने के बारे में नहीं पूछा। प्रबंधक जो पूछते हैं "आप कैसे दायरे को नियंत्रित करते हैं?" सक्रिय रूप से वृद्धिशील विकास को अस्वीकार कर रहे हैं। वे इसे पाने की कोशिश नहीं कर रहे हैं।
जब प्रबंधकों को यह जानना है कि कैसे एजिल विधियां "रस्सी" को रोकती हैं, वे (ए) सीखने की प्रक्रिया को "रेंगने" (जो खराब है) के रूप में लेबल करते हैं और (बी) इस विचार का विरोध करते हैं कि सीखने से गुंजाइश बदल जाती है । जब आप किसी भी सीखने के बावजूद किसी विशिष्ट दायरे में प्रतिबद्ध होते हैं तो एकमात्र तरीका आपके पास "रेंगना" होता है। Agile विधियां केवल एक अगले स्प्रिंट के लिए प्रतिबद्ध, एक व्यापक दायरा नहीं। यदि आप किसी दायरे पर प्रतिबद्ध नहीं हैं, तो यह रेंग नहीं सकता क्योंकि यह अस्तित्व में नहीं है।
एक महान बिंदु है, "आप बेहतर डिजाइन को लागू करने से खुद को कैसे रोकते हैं" के लिए समानार्थी "स्कोप क्रिप्प को कैसे रोकते हैं" है? –
+1 - मुझे यह पसंद है कि आप क्या कह रहे हैं, मेरा एकमात्र जोड़ यह है कि आपको अपने संगठन की संस्कृति के प्रति संवेदनशील होना चाहिए। यदि आपके पास खरीद-इन प्राप्त करने के लिए पर्याप्त लोग नहीं हैं और उस गेंद को ऊपर से नीचे घुमाते हैं तो यह दृष्टिकोण आपके लिए बहुत अच्छा काम नहीं कर सकता है। –
हमें शीर्ष नीचे से गेंद रोलिंग नहीं मिली। हमने अभी एक समय में एक टीम की है। –
आप लिन मैन्स और लिंडा राइजिंग द्वारा Fearless Change: Patterns for Introducing New Ideas पुस्तक में रूचि रख सकते हैं। यह संगठनों में चुस्त विधियों को पेश करने में अनुभव का एक सारांश है।
+1 - अच्छा लिंक। मैं सब उस पर हूँ। ;) –
याह, यह जल्द ही मेरे बुकशेल्फ़ पर एक नई किताब हो सकती है! अच्छी सिफारिश। –
मैं अभी यह करने की कोशिश कर रहा हूं। हमारे पास एक साइट पर ग्राहक विकास विभाग है और मैं आपको बता सकता हूं कि वे एक पुनरावृत्ति विकास प्रक्रिया के लिए खरीद-इन को पकड़ने की कोशिश में महत्वपूर्ण हैं।
इस here पर कुछ शानदार उत्तर।
यदि आपके पास बड़े और अप्रबंधनीय हिस्सों के कारण होने वाली परियोजनाओं के देर से और अधिक बजट देने का ट्रैक रिकॉर्ड पहले से ही प्राप्त हो चुका है, तो यह आपकी परियोजनाओं के हितधारकों को बदलने की गेंद को बदलने के लिए एक अच्छी शुरुआत है।
प्रक्रिया स्वयं साबित हो सकती है, लेकिन केवल इसके समर्थन में सही पार्टियों के साथ। आप जो भी करने की कोशिश कर रहे हैं उसमें मूल्य देखने के लिए आपकी कुंजी अन्य टीम के खिलाड़ियों को मिल रही है।
हमारे लिए, यह ग्राहकों के नजरिए से चीजों तक पहुंचने के लिए नीचे आता है। हमें यह सुनिश्चित करने के लिए ग्राहक को लगातार वापस आने की जरूरत है कि हम जो भी बना रहे हैं वह वह है जो वे कल्पना करते हैं। हम को हर किसी के समय बर्बाद करने से रोकने के लिए प्रक्रिया को सुव्यवस्थित करना चाहते हैं।
अब निश्चित रूप से, विभिन्न संगठनों के लिए एग्इल काम के विभिन्न हिस्सों और बहुत कम कंपनियां जो वास्तव में एग्इल प्रक्रियाओं का उपयोग करती हैं, एक शुद्ध अर्थ में ऐसा कर रही हैं।
परीक्षण और त्रुटि के माध्यम से पता लगाएं कि आपके व्यवसाय, संस्कृति और टीम के लिए क्या काम करता है। ऐसा कुछ भी नहीं है जो कहता है कि आप धीरे-धीरे समग्र प्रक्रिया को अपनाने नहीं कर सकते हैं और चेरी उन हिस्सों को चुनते हैं जो आपके व्यावसायिक मॉडल के लिए सबसे अच्छा काम करते हैं।
बहुत अच्छी सलाह है, ग्राहकों को यह सोचना मुश्किल है कि यह विकास के अधिक घंटे उन्हें बेचने के लिए सिर्फ एक और बिक्री रणनीति नहीं है। –
हाँ निश्चित रूप से। हम भाग्यशाली हैं क्योंकि हम ऐसे आंतरिक विभाग के साथ ऐसा करते हैं जो ग्राहकों की सेवा करते हैं। वास्तव में लगभग एक बिक्री विभाग की तरह किसी भी अन्य कंपनी में होगा। वे ऐसे उत्पाद को वितरित करना चाहते हैं जो ग्राहकों की अपेक्षाओं को पूरा करता है ताकि वे अंततः बिक्री या बेहतर हो सकें, व्यवसाय दोहराएं। मैं मुख्य रूप से एक Agile दृष्टिकोण को औचित्य देने की कोशिश करता हूं क्योंकि मैं जल्द ही सॉफ्टवेयर के कार्यात्मक हिस्सों को वितरित करने में मदद कर सकता हूं और ज्यादातर समय ग्राहक हमेशा सबकुछ चाहते हैं। –
यहां के आसपास यह एक टीम के साथ शुरू हुआ जो आगे बढ़ना चाहता था और स्क्रम का उपयोग करके अधिक चुस्त हो गया। यह टीम "पायलट टीम" थी और कुछ स्पिंट्स (3 महीने) के लिए गई थी। उन्हें अंदर से किसी के द्वारा प्रशिक्षित किया गया था जो पहले से ही स्क्रम के बारे में पढ़ रहा था और सीख रहा था। एक पूर्ण स्विचओवर के बजाय "पायलट" करने से प्रबंधन और अपवर्तक टीम के सदस्यों से स्वीकृति प्राप्त करने में मदद मिली।
"चलो इसे आज़माएं" रवैया वास्तव में ग्राहकों को प्रक्रिया में लाने में मदद करता है (यहां आंतरिक ग्राहक, लेकिन ग्राहक कम नहीं हैं)।
और इसे छड़ी बनाने के लिए, आपको प्रगति और ध्यान और आपके टीम को लाए जाने वाले फायदों पर ध्यान देना होगा (यह बेहतर प्रदर्शन, टीम के सदस्यों/ग्राहकों के साथ बेहतर संचार, बेहतर परिणाम, खुश ग्राहकों, इत्यादि)
मेरे अनुभव में, टीम को संक्रमण करना समस्या नहीं है। यह संक्रमण प्रबंधन है।
+1: प्रबंधन सिर्फ जानता है (सबूत के बिना) कि ** केवल ** वैध परियोजना योजना पूर्ण परिभाषित सभी कार्यों के साथ एक झरना योजना है। –
याहू, और हमारे लिए यह ज्यादातर हमारे ग्राहकों के बारे में है। मैं उनके दिमाग पर एकमात्र चीज पैसे बचा रहा हूं, और यह जानकर कि "बाहर के दरवाजे" के लिए कितना खर्च किया जा रहा है। –
मेरे (स्वीकार्य रूप से सीमित) अनुभव से, सुनिश्चित करें कि आपके सभी प्रोग्रामर एग्इल/स्क्रम/जो कुछ भी स्विच करने के निर्णय में शामिल हैं, और वे सभी इसके पक्ष में हैं - या कम से कम सक्रिय रूप से नहीं जा रहे हैं इसका विरोध करो। मैंने टीम के सदस्यों से प्रतिरोध देखा है जब एजिल/स्क्रम को उनकी सहमति/इनपुट के बिना ऊपर से अनिवार्य माना गया था। अपनी टीम को लगातार मनाने के बिना प्रबंधकों को प्रशिक्षित करना काफी मुश्किल है।
यह सच है, शायद ही कभी अनिवार्य चीजें उन लोगों में जुनून को प्रेरित करती हैं जिन्हें लगाया जाता है। –
यह प्रश्न ऑफ-विषय है क्योंकि यह इस साइट के दायरे में नहीं है, जैसा कि [मैं यहां कौन से विषय पूछ सकता हूं?] (// stackoverflow.com/help/on-topic) यह भी देखें: [क्या प्रश्नों के प्रकारों से मुझे पूछने से बचना चाहिए?] (// stackoverflow.com/help/dont-ask) आप [अन्य स्टैक एक्सचेंज साइट] (// stackexchange.com/sites#name) पर पूछने में सक्षम हो सकते हैं, उदाहरण के लिए [ pm.se] या [softwareengineering.se]। किसी भी साइट पर किसी प्रश्न को पोस्ट करने का इरादा रखने के लिए सहायता केंद्र में विषय-वस्तु पृष्ठ को पढ़ना सुनिश्चित करें। – Makyen
विचित्र रूप से पर्याप्त, यह एसओ के लिए 8 साल पहले विषय से बाहर नहीं था;) लेकिन यकीन है कि यह आज है! –
हाँ। तथ्य यह है कि स्टैक ओवरफ़्लो पर ऑन-विषय/ऑफ-विषय क्या बदल गया है, यह आपके या नकारात्मक रूप से नकारात्मक रूप से प्रतिबिंबित नहीं होता है। यह समय के साथ साइट विकसित हुआ है। – Makyen