जब ग्राहकों की आवश्यकताएं बिल्कुल नहीं बदलती हैं तो क्या फुर्तीली का उपयोग करना गलत है?


12

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

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

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

मेरा सवाल है: क्या इसे बुरा, चरवाहा कोडिंग, विरोधी पैटर्न, आदि के रूप में माना जाएगा? क्या हमें कोडिंग शुरू करने से पहले महान विवरणों में जितना संभव हो सके, झरना नियोजित करना चाहिए और जब इस पर ध्यान देना चाहिए तो आइए, 'आइए इसे करते हैं?'

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


2
@randomA: वास्तव में, IMHO आपको कभी भी शुद्ध जलप्रपात की कोशिश नहीं करनी चाहिए, यदि आप एक कार्यशील उत्पाद बनाना चाहते हैं, जिसे एक सप्ताह के प्रयास से अधिक की आवश्यकता हो।
डॉक्टर ब्राउन

10
कृपया मुझे अपने ग्राहक दे
razethestray

7
मैं 2 गुणा अधिक अपने ग्राहकों के लिए @razethestray से दे देंगे
जश्न

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

3
@randomA: आप कुछ भी नहीं पूछकर कुछ समय के लिए आपको ग्राहक को खुश रख सकते हैं, और फिर, जब आप अंतिम चीज़ वितरित करते हैं, तो उसे बहुत दुखी करें क्योंकि यह पता चला है कि आप आवश्यकताओं को इतना याद करते हैं कि आप अपने कार्यक्रम को दूर फेंक सकते हैं और शुरू कर सकते हैं शुरुआत से (जो ग्राहक भुगतान करने के लिए तैयार नहीं होगा)। या आप उसे सही प्रोग्राम बनाने के लिए बीच-बीच में उससे पूछकर कुछ समय के लिए उसे थोड़ा लेकिन दुखी कर देते हैं, लेकिन अंत में बहुत खुश होता है जब प्रोग्राम वास्तव में वही करेगा जो वह चाहता है और उसे वह मिलता है जिसका उसने भुगतान किया है। अपनी पसंद चुनें।
डॉक ब्राउन

जवाबों:


16

क्या इसे बुरा, काउबॉय कोडिंग, पैटर्न-विरोधी माना जाएगा।

संक्षिप्त उत्तर: नहीं। "फुर्तीली" सही ढंग से करने का मतलब "नो प्लानिंग" नहीं है, इसका मतलब है कि चीजों को अधिक करना नहीं है।

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

यह एक बड़ा बयान है। "आवश्यकताओं को बदलना" इस बारे में भी है कि आवश्यकताओं की टीम की समझ कैसे बदलती है। और यह इस बारे में है कि आवश्यकता के बारे में ग्राहक की प्राथमिकताएं कैसे बदलती हैं जब वह वास्तव में सॉफ्टवेयर के कुछ रिलीज देखता है।

वास्तव में, "फुर्तीली" IMHO में आपके द्वारा वर्णित स्थिति में सबसे अच्छा काम करती है - ग्राहक को उसकी समग्र आवश्यकताओं के बारे में अच्छी जानकारी है, आप इसमें से एक सामान्य योजना लिख ​​सकते हैं, बहुत सारी "उपयोगकर्ता कहानियों" के साथ अपना बैकलॉग भरें, और पहले से ही सही सिस्टम आर्किटेक्चर चुनने के लिए पर्याप्त जानकारी। यदि आप अभी भी सही दिशा में जा रहे हैं, तो प्रतिक्रिया के बहुत से, "चुस्त आवश्यकताओं" को और अधिक सटीक बनाने में मदद मिलेगी। यह आपको वास्तविक प्रयास और लागतों के बारे में शुरुआती प्रतिक्रिया भी देगा (जो कुछ ऐसा है जो आप अभी भी एक झरने के दृष्टिकोण में विफल हो सकते हैं, भले ही आप विस्तार से हर एक बिट की आवश्यकता को जानते हों)।


3
"झरना" को सही ढंग से करने का अर्थ "सब कुछ योजना" नहीं है, इसका मतलब चीजों को कम करना नहीं है।
जियोर्जियो

1
@ जियोर्जियो: "वॉटरफॉल" करने का सही मतलब है कि इसे तब लागू न करना जब आवश्यकताएं "थोड़ा अस्पष्ट" हो और "सॉफ्टवेयर पर्याप्त जटिल हो कि इसमें विवरण, समस्याएं हों जो मैं तब तक नहीं पहचान पाऊंगा जब तक मैं वास्तव में उनका सामना नहीं करता" मूल प्रश्न)।
डॉक्टर ब्राउन

6

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

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

ए) ग्राहक को साबित करता है कि आप वास्तव में डेमो के माध्यम से लगभग वहां हैं ("ये सभी कहानियां की जाती हैं, हम आखिरी कुछ कर सकते हैं यदि आप चाहते हैं") और कुछ और समय बिल्कुल वही मिलेगा जो वे चाहते हैं।

बी) संभावित रूप से उनके लिए अच्छा है कि वे वैसे भी खुश रहें और रिलीज करें।

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


मुझे समझ में नहीं आता कि ए) आपके उत्तर की शुरुआत में आपके द्वारा बताई गई समस्या को हल करता है: आपको कैसे पता चलेगा कि पिछली कुछ कहानियों में कुछ दिन या दो साल लगेंगे? आप केवल वास्तव में जानते हैं जब आप वास्तव में उन्हें करते हैं, है न?
जियोर्जियो

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

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

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

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

3

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

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


1
मैं अक्सर सोचता हूं कि क्या क्लाइंट जो बहुत ज्यादा शामिल नहीं होना चाहते हैं, उनके पास वास्तविक व्यवसाय की आवश्यकता है। मैंने अक्सर यह उन परियोजनाओं में देखा है जहां एक मौजूदा एप्लिकेशन एक नई तकनीक के लिए 'अनुवादित' है। आप कोड की जांच कर सकते हैं यदि आपके पास प्रश्न हैं जो वे आपको बता रहे हैं। रीमेक का इंतजार किसी को नहीं है।
user99561

@ user99561: आप सही हैं, लेकिन ऐसी स्थितियों में आवश्यकताएं अधिकतर अस्पष्ट नहीं होती हैं, वे क्रिस्टल स्पष्ट होती हैं - जब तक कि नया कार्यक्रम बिल्कुल पुराने जैसा ही व्यवहार करेगा । ऐसी स्थिति में "फुर्तीली" दृष्टिकोण वास्तव में आवश्यक नहीं है। एक पुनरावृत्त, मील-पत्थर आधारित दृष्टिकोण (बहुत ग्राहक बातचीत के बिना) वास्तव में पर्याप्त होगा।
डॉक ब्राउन

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

0

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

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


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