वहाँ स्प्रिंट के बीच एक काम कर निर्माण के अलावा अन्य चुस्त प्रथाओं के फायदे हैं?


9

मुझे हाल ही में सॉफ्टवेयर विकास में चुस्त प्रथाओं में दिलचस्पी हो गई और मैंने तब से बहुत सारे लेखों को देखा है कि ये अभ्यास समग्र लागतों को कम करने की अनुमति देते हैं।

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

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

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

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

क्या कोई मुझे यह बताने की कृपा कर सकता है कि मैं यहां गलत कहां जा रहा हूं, क्योंकि जाहिर है कि बहुत से लोग उत्पादन वातावरण में चुस्त-दुरुस्त रहते हैं, इसलिए मुझे कहीं न कहीं गलत होना चाहिए।


तुम्हारी बात तथ्य पूर्ण है। मैं यह बताना चाहता हूं कि 'झरना' शब्द में 1 सार्वभौमिक परिभाषा नहीं है (आईटी में कई अन्य शब्दों की तरह)। अधिकांश लोगों को लगता है कि आपको तब तक कोड करने की अनुमति नहीं है जब तक कि आवश्यकताओं के पूर्ण 2000 पेज लिखे और हस्ताक्षर नहीं किए जाते हैं। ऐसा बिल्कुल नहीं होना चाहिए।
NoChance

हाँ, "झरना" से मेरा मतलब है (सबसे मूल रूप से) कार्यात्मक ऐनक की एक रैखिक प्रक्रिया -> डिजाइन -> मील के पत्थर के बीच कोड, स्प्रिंट नहीं। और, निश्चित रूप से, 2000 पेज की आवश्यकताएं और तकनीकी चश्मा एक जरूरी नहीं हैं, कक्षाओं की बुनियादी जिम्मेदारियां और एक-दूसरे के साथ उनके संबंध अक्सर एक शीर्ष-स्तरीय डिजाइन के रूप में पर्याप्त हैं।
tux91

3
@EmmadKareem: वास्तव में, झरना में उचित, यह बिल्कुल मामला है। डिज़ाइन के हर विवरण के अंतिम होने तक आप कोडिंग शुरू नहीं करते हैं। सौभाग्य से, वास्तविक झरना सॉफ्टवेयर विकास में शायद ही कभी लागू होता है - ज्यादातर क्योंकि यह वास्तव में काम नहीं करता है।
तदमर्स

1
@ टिप्पणीकार, आपकी टिप्पणी के लिए धन्यवाद। हालांकि ऐसा कुछ ही बार हुआ। झरने की विधि का कोई मालिक नहीं है और इसे अलग तरीके से लागू और व्याख्या किया जा सकता है। Thee कोई नियम नहीं है जो कहता है कि जब तक कोड न हो .... या फिर ..., ऐसा इसलिए है क्योंकि यह एक कार्यप्रणाली नहीं है। जब अच्छी कार्यप्रणाली में लिपटे हुए, मुझे लगता है कि यह विशेष रूप से उन परियोजनाओं में बहुत मायने रखता है जहां उपयोगकर्ता एक प्रणाली से जरूरी चीजों के मूल को जानते हैं।
NoChance

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

जवाबों:


7

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

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

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

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

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

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


बहुत धन्यवाद। हर कोई जो इस विषय पर पढ़ना चाहता है कि कैसे डिजाइन चुस्त
दुरुस्त

8

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

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

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


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

2
झरना परियोजनाओं के साथ मेरा अनुभव यह है कि वे हमेशा नियोजित समय के पहले 90% के लिए समय पर होते हैं, जिस बिंदु पर वे अचानक महीनों पीछे होते हैं। हर स्प्रिंट डेमो पर जोर देने के एजाइल का मॉडल इसकी बहुत कम संभावना बनाता है। जब लोग जानते हैं कि वे एक और डेढ़ सप्ताह में जवाबदेह होंगे, तो वे आमतौर पर तब प्रेरित होते हैं, जब उन्हें नौ महीने में जवाबदेह ठहराया जाएगा। यह सिर्फ मानव मनोविज्ञान है।
रोबोट

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

2
ज्यादातर सुरक्षा-महत्वपूर्ण हैं, जैसे, रेलवे सिगनल, हवाई जहाज - - जहां ग्राहकों के लिए कुछ क्षेत्र हैं करना बहुत सावधानी से चश्मा पढ़ें। वे बहुत दुर्लभ हैं, और वैसे भी बड़े पैमाने पर विभिन्न विकास विधियों का नेतृत्व करते हैं।
डोनल फेलो

4

सवाल से उद्धरण के जवाब में, जो कि चिर-विरोधी विरोधियों की एक बुनियादी गलत धारणा है

"... जबकि झरना आपको कुछ भी जारी करने से पहले अपनी वास्तुकला को परिपूर्ण करने की अनुमति देता है।" एक गिरावट है, मुझे इसे तुम्हारे लिए ठीक करने दो; "... जबकि झरना आपको अपनी वास्तुकला को पूर्ण करने की अनुमति देता है ताकि आप कभी भी कुछ भी जारी न करें "

निहितार्थ है कि झरना कुछ कैसे उच्च गुणवत्ता वास्तुकला प्रदान करता है मौलिक रूप से गलत है और पूरी तरह से अनुभवजन्य ऐतिहासिक साक्ष्य द्वारा अस्वीकृत है।

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

YouTube, Twitter और अनगिनत अन्य कंपनियों के साथ भी।

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

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


3
"कभी नहीं" शब्द का उपयोग करके, क्या आप कह रहे हैं कि वहाँ कोई सॉफ्टवेयर उत्पाद नहीं हैं जो जलप्रपात का उपयोग करके किए गए थे? इसके अलावा, क्यों "कभी नहीं" कुछ भी जारी करें यदि आपके पास एक विशेष मील का पत्थर के लिए आवश्यकताओं का एक सेट है जिसे आप सफलतापूर्वक लागू करते हैं?
tux91

1
@ tux91 तुम मेरे लिए मेरी बात बनाओ; कुछ भी कभी भी सही नहीं होगा जिसे डिजाइनों को कागज में डालने के तुरंत बाद बदलने की जरूरत है और कोड की एक पंक्ति लिखे जाने से पहले अप्रचलित हैं। इस प्रकार मैंने जो कथन उद्धृत किया है वह एक पतन है, आप कभी भी एक वास्तुकला को परिपूर्ण नहीं करेंगे और इस प्रकार कभी भी कुछ भी जारी नहीं करेंगे।

1
@ tux91 अभी भी समझ के लिए पढ़ा है, मैंने कहा, कि कोई प्रीफेक्ट आर्किटेक्चर नहीं है और यदि आप तब तक रिलीज नहीं करते हैं जब तक कि उद्धरण में जैसा है, तब तक कुछ भी जारी नहीं किया जाएगा। मैंने यह नहीं कहा कि आप क्या दावा कर रहे हैं, अवधि, यह आपके सिर और आपकी व्याख्या में है। मैंने जो कहा, वह तर्क है कि जलप्रपात किसी भी तरह बेहतर गुणवत्ता का आर्किटेक्चर प्रदान करता है, यह एक गिरावट और मौलिक रूप से त्रुटिपूर्ण है। और नासा और झरने के बारे में ये तर्क और क्या नहीं; प्रोग्रामरों से असंबद्ध होने के अलावा , इस मामले के लिए 3 अंतरिक्ष यात्रियों को मार डाला, न कि एक चमकदार सफलता की कहानी।

1
@ tux91 wrt का उपयोग "कभी नहीं" के लिए, मैं यहां जारोद के साथ हूं: सवाल कहता है "झरना आपको परिपूर्ण करने की अनुमति देता है ..." - जिसे वह पूरी तरह से उपयुक्त (इस अवास्तविक "परिपूर्ण" संदर्भ) शब्द "कभी नहीं" में गिनता है। एकमात्र कारण मैंने किया नहीं वोट दें कि मैं नहीं रचनात्मक सवालों के जवाब पर से बचने के मतदान करने की कोशिश है
कुटकी

1
@gnat हाँ मुझे लगता है कि मुझे नहीं लगता कि जब मैंने सही शब्द का इस्तेमाल किया था , तो मैं वास्तव में इसका मतलब नहीं चाहता
tux91

3

स्क्रम अपने आप में किसी भी तकनीकी प्रथाओं को निर्धारित नहीं करता है क्योंकि यह एक सामान्य ढांचा है।

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

इसे इस तरह से करने से परिवर्तन को जल्दी और सुरक्षित रूप से संभालना संभव हो जाता है, जो पहली जगह में फुर्तीली विकास का उपयोग करने का प्राथमिक कारण भी है।

चपलता का एक माप जो मायने रखता है यदि आप नियमित रूप से (साप्ताहिक, द्वैध रूप से) अपने ग्राहक के लिए मूल्यवान, काम करने वाले सॉफ़्टवेयर को जारी करने का प्रबंधन करते हैं। क्या आप यह कर सकते हैं? फिर तुम मेरी किताब में चुस्त हो।


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

@ tux91 मेरा जवाब अपडेट किया। वास्तुकला के लिए, मैं इसे पढ़ने या 26:20 पर इसे देखने के बारे में सलाह देता हूं जिसे हम "वृद्धिशील डिजाइन" कहते हैं।
मार्टिन विकमैन

2

मेरे लिए, फुर्तीले का मुख्य लाभ परियोजना में जोखिम को कम कर रहा है।

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

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


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

1

बहुत सारे मामलों में आर्किटेक्चर को बहुत महत्वपूर्ण रूप से संशोधित करने की आवश्यकता होगी, जिसका अर्थ यह भी होगा कि आपको पुराने आर्किटेक्चर पर निर्भर सभी सुविधाओं को फिर से लागू करना होगा।

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

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


0

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

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.