कार्य प्रणाली की जगह लेने पर चुस्त कैसे काम करता है?


15

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

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

जब आप "सबसे छोटा उपयोगी उपसमूह" "यह सब" है, तो आप एजाइल को कैसे लागू करेंगे?


3
मेरा एक प्रश्न है, क्या यह नई प्रणाली एक मौजूदा फीचर सेट का प्रत्यक्ष दर्पण है, और यदि ऐसा है तो आप इसे क्यों बदल रहे हैं?

उपयोगकर्ता एक रुचि दिखा सकते हैं या नई कार्यक्षमता कभी नहीं प्राप्त कर सकते हैं। यह उनकी पसंद है, लेकिन कुछ व्यावसायिक सेटिंग्स में उनके पास पर्यवेक्षक हो सकते हैं जो अन्यथा सोचते हैं।
जेफओ

जवाबों:


14

फुर्तीली समाधान एक बार में सभी को बदलने के लिए नहीं हो सकता है , लेकिन धीरे-धीरे प्रतिस्थापन को चरणबद्ध करने के लिए हो सकता है ।

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


2
इससे पहले कि मैं व्यावहारिक रूप से एक ही बात कहूं, +1 ने भी आपका जवाब यहां नहीं देखा। महान दिमाग और सभी;)
माइकल ब्राउन

+1 यह प्रदर्शित करने के लिए कि कुछ प्रकार के वास्तविक जीवन के कार्यान्वयन के लिए एजाइल एक आदर्श दृष्टिकोण नहीं हो सकता है।
पापा

@ पीएपी हाँ, चुस्त (टीएम) को बहुत मुश्किल से सम्मोहित किया गया है, अपनी विशिष्ट स्थिति के बारे में सोचने के बिना, एक निश्चित पद्धति का उपयोग करके नेत्रहीन रूप से खतरा है।
मार्कजे

पुरानी प्रणाली के कुछ हिस्सों को रखने का तात्पर्य है पुरानी प्रणाली के साथ एकीकरण पर विकास के प्रयासों को खर्च करना, है ना?
स्टीव बेनेट

1
@SteveBennett: हाँ, यह करता है। यह, ज़ाहिर है, एक व्यापार है। लेकिन अदायगी से जोखिम बहुत कम हो जाता है, और आपको केवल उस हिस्से को फिर से लाने की आवश्यकता होती है, जिसे फिर से तैयार करने की आवश्यकता होती है।
sleske

6

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

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


5

दुनिया में छोटे वेतन वृद्धि जारी करना ग्रीनफील्ड परियोजनाओं के लिए काम कर सकता है लेकिन फिर भी छोटी संख्या में सुविधाएं बहुत उपयोगी नहीं हो सकती हैं।

स्क्रैम ने कहा कि प्रत्येक स्प्रिंट के बाद कि उत्पाद "संभावित रूप से शिपबिल" है। इसे शिप करने की जरूरत नहीं है, लेकिन एक shippable उत्पाद की गुणवत्ता के लिए है।

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

यदि आप उपयोगकर्ताओं से फीडबैक को शामिल कर रहे हैं तो आप पा सकते हैं कि नई सुविधाएँ जुड़ गई हैं और पुराने जुड़ गए हैं।


1
+1 यह ठीक है कि हमने इसे कैसे अपनाया। हालांकि 'स्टार्टिंग ओवर' का पूरा विचार बहुत ही असहनीय है। आपने पुराने समाधान को बिट द्वारा स्थानापन्न करने के लिए कितना कठिन प्रयास किया है?
क्रिस वान बाल

@KrisVanBael यह सैद्धांतिक रूप से बेहतर है (और निश्चित रूप से एक आदर्श) लेकिन यह उन लोगों में से एक है "यह निर्भर करता है" प्रश्न - कुछ पुराने समाधान वास्तव में पुराने हैं (इसलिए कोई प्लेटफ़ॉर्म परिवर्तनों को देख रहा है) या प्रक्रिया वायर्ड है / सिस्टम अंत में एकीकृत और "बिट्स" बड़े हो सकते हैं।
मर्फ़

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

3

मैंने एक प्रमुख राष्ट्रीय केबल टीवी नेटवर्क के लिए व्यावसायिक अनुप्रयोग प्रतिस्थापन की एक विशाल रेखा पर काम किया। नई प्रणाली का विकास SCRUM के साथ किया गया था, यह लगभग सभी प्रमुख उप-प्रणालियों को फिर से लागू करने के लिए 18-24 महीने की विकास परियोजना थी; जो 10 साल पुराने थे।

विकास शुरू होने से पहले 6 महीने की तरह एक नियोजन चरण था, लेकिन इसे SCRUM के रूप में भी संपर्क किया गया था। यह वह जगह है जहाँ उत्पाद स्वामी ने मौजूदा सिस्टम विश्लेषण और ग्राहकों के साक्षात्कार के बाद उच्च स्तरीय स्टोर और महाकाव्यों को लिखा।

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

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

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

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


ठंडा। इस कहानी में महत्वपूर्ण बात दोनों प्रणालियों पर एक साथ काम करने के इच्छुक श्रमिकों की उपलब्धता थी।
स्टीव बेनेट

2

मुझे अभी भी लगता है कि फुर्तीली इस परिदृश्य में बहुत अधिक मूल्य जोड़ता है।

यह सिर्फ इतना है कि आपके पास 'वर्तमान प्रणाली को प्रतिस्थापित करें' का एक बहुत परिभाषित अंतिम लक्ष्य है।

चंचल तकनीक और प्रक्रियाएं अभी भी आपको वहां और अधिक प्रभावी रूप से प्राप्त कर सकती हैं

उदाहरण के लिए:

आप अभी भी सिस्टम पर पुनरावृत्त और छोटे स्प्रिंट में वितरित कर सकते हैं।

आप अभी भी प्रमुख लोगों के साथ संवाद करने के बाद काम को प्राथमिकता देने के लिए चुस्त तकनीकों का उपयोग कर सकते हैं।

आप अभी भी फुर्तीले वेग के आधार पर योजना के लिए चुस्त का उपयोग कर सकते हैं।

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

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


1

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

उन्हें समझाएं कि आप इसे इस तरह से नहीं करना चाहते हैं क्योंकि आपको लगता है कि यह मजेदार होगा और आप एक झरने की प्रक्रिया का उपयोग करके अकेला पड़ जाते हैं। यह लंबे समय में एक बेहतर ऐप बनाएगा।

एक प्रमुख विक्रय बिंदु यह लागू करना हो सकता है कि नए ऐप के निर्माण के दौरान एक बदलाव जो वे हमेशा से चाहते हैं, लेकिन पुराने सिस्टम में कभी नहीं मिल सकते।


0

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

व्यापारी तब विश्वास से बाहर हो जाता है जब तक कि आपके द्वारा ऑर्डर की गई कार नहीं आ जाती है तब तक आपको कार का इंजन ब्लॉक देने का फैसला करता है। आप कार के इंजन के साथ क्या करने वाले हैं? निश्चित रूप से मैं इसे जांचने और काम करने के लिए कुछ घटकों को हुक कर सकता हूं, लेकिन यह वास्तव में मुझे कल काम करने में मदद नहीं करता है जहां पुरानी जंग लगी कार करती है।

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

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

हो सकता है कि जिस कार ग्राहक के रूप में आप बस देखना चाहते हैं और इंजन का मूल्यांकन करें, यह सुनिश्चित करने के लिए कि आप वास्तव में वह प्राप्त करने जा रहे हैं जिसका आपने अनुमान लगाया था। ओह, मैं वास्तव में 4 सिलेंडर इंजन के बजाय 6 सिलेंडर इंजन चाहता था! क्या मैंने आपको पहले नहीं बताया था? कोई बात नहीं, फ़ैक्टरी ऑर्डर में बदलाव करने देता है।

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


हाँ, लेकिन मेरा अनुभव अब तक, रूपक का अनुसरण करने के लिए रहा है, कि कार ग्राहकों को इंजनों के बारे में कुछ भी पता नहीं है, और आपको एक को देखने से उपयोगी कुछ भी नहीं बता सकता है। जब वे काल्पनिक मोड में होते हैं, तो प्रतिक्रिया बहुत ही सतही होती है "ओह, ऐसा लगता है कि यह वही करेगा जो हम चाहते हैं" और आपको बहुत कुछ नहीं मिलता है जब तक कि वे वास्तव में पहली बार किसी वास्तविक समस्या को हल करने के लिए इसका उपयोग नहीं करते हैं।
स्टीव बेनेट
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.