झरना सॉफ्टवेयर विकास पद्धति अभी भी व्यवहार्य है?

Question

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

क्या जलप्रपात विकास पद्धति अभी भी समय, लागत और गुणवत्ता के संबंध में सॉफ्टवेयर सिस्टम प्रदान करने के लिए व्यवहार्य है?

Comments

इसलिए, यदि आपने इसे अनुभव नहीं किया है, और इसे अनुभव नहीं करना चाहते हैं, तो यह मृत हो जाता है। ऐसा नहीं है कि मैं इसके लिए वकालत कर रहा हूं, लेकिन यह एक अजीब आधार है।

— थर्सडेजेक

यह मरा नहीं है। यह सिर्फ वर्तमान सनक / प्रवृत्ति / "स्वीकार्य" नहीं है

— पॉल

@GrandmasterB "मृत" से मेरा मतलब था "पर्याप्त रूप से सबसे अच्छा तरीका साबित नहीं हुआ"

— CFL_Jeff

@Rachel कृपया सॉफ़्टवेयर-डेवलपमेंट टैग को पढ़ना जारी न रखें। यह एक मेटा टैग है जिसे भविष्य में सफाई के लिए स्लेट किया जाता है ।

— थॉमस ओवेन्स

यह मरा नहीं है, यह बस आराम कर रहा है। फजरों के लिए पिटाई। ;)

— FrustratedWithFormsDesigner

Answer 1

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

विकिपीडिया लेख से:

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

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

मैं इस अवधारणा में विश्वास करता हूं, लेकिन ऊपर वर्णित कार्यान्वयन जोखिम भरा है और विफलता को आमंत्रित करता है।

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

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

Comments

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

— मिंग-तांग

@ThomasOwens क्या आप इनमें से एक जोड़े का हवाला देते हैं other plan-driven methodologies that lie opposite of agile that can and do work on project?

— लैवि

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

— थॉमस ओवेन्स

Answer 2

लोग पाठ्य-पुस्तक झरना मॉडल का उपयोग नहीं करते हैं और शायद कभी नहीं करते हैं।

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

इस तथ्य के बावजूद कि यह एक प्रक्रिया से अधिक सोचने का एक तरीका है, यह अभी भी बहुत अधिक तरीका है कि कई - शायद अधिकांश संगठन सॉफ़्टवेयर (या घरों, या पनडुब्बियों, या जो कुछ भी ...) के निर्माण के बारे में जाते हैं।

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

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

कार्यप्रणाली बिंदु नहीं है। बिंदु यह सोचने का है कि आप क्या कर रहे हैं और आप इसे इस तरह क्यों कर रहे हैं - और ग्राहक को कम से कम उचित समय में सबसे अधिक मूल्य दिलाने के लिए।

Comments

आपने स्पष्ट रूप से मेरे लिए "लोगों" का एक बहुत ही अलग अनुभव किया है। पिछले 30 वर्षों में, मैंने उन कंपनियों के उत्तराधिकार में काम किया है जो सभी पाठ्य-पुस्तक जलप्रपात विधि का उपयोग करती हैं (और अभी भी उपयोग करती हैं)। अप्रत्याशित रूप से, यह काम नहीं करता है।

— डेविड अर्नो

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

— जोएल ब्राउन

Answer 3

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

Comments

निश्चित नहीं है कि "पौराणिक" जलप्रपात प्रक्रिया और "वास्तविक" एक के बीच क्या अंतर है। क्या आप इसे समझाएंगे?

— CFL_Jeff

अक्सर फुर्तीली समर्थकों द्वारा वर्णित झरना प्रक्रिया एक स्ट्रोमैन en.wikipedia.org/wiki/Straw_man

— jfrankcarr

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

— रॉबर्ट हार्वे

-1 के बयान के लिए, "वे वितरित करने के लिए उत्कृष्ट रहे हैं ..." सच्चाई यह है कि यह एक धोने है। सभी सॉफ्टवेयर विधियों की तरह, कभी-कभी यह काम करता है, कभी-कभी यह नहीं होता है। मैंने दोनों को सच्चे झरने के तरीके के मामले में देखा है।

— रिवाल्क

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

— मलफिस्ट

Answer 4

शायद यह पूछने का एक बेहतर तरीका कि आप क्या कर रहे हैं, "जब कम चलना और अधिक औपचारिक बेहतर हो?"

ऐसी परिस्थितियां हैं जहां यह मामला है:

• जब आवश्यकताएं नहीं बदलेंगी।

• जब नई आवश्यकताओं को पूरा करना मूल लोगों के 100% मारने की तुलना में कम महत्वपूर्ण है।

• जब सभी प्रौद्योगिकी घटक परिपक्व और अच्छी तरह से समझ में आ जाते हैं।

एक मायने में आप चुस्त होने के लिए ड्राइव कर सकते हैं।

हर जगह बहुत कम तकनीकें लागू होती हैं। बहुत कम का कोई उपयोग नहीं है।

Comments

दुनिया में क्या है "कमिट्रेटिव" या "मोरेनफॉर्मल"?

— एरोनियर ने

@Aaronaught - "कम पुनरावृति" और "अधिक औपचारिक" एक iPhone पर वसा अंगूठे द्वारा टाइप किया गया। :-)

— मैथअटैक

मैंने कभी ऐसी परियोजना में काम नहीं किया है जो इन शर्तो में से किसी एक को भी पूरा करती हो। :)

— थियोडोर

Answer 5

हाँ, यह बहुत अधिक जीवित है, हालांकि आज यह अधिक सामान्य " वी मॉडल " है जिसका उपयोग किया जाता है।

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

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

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

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

Comments

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

— डीएनए

Answer 6

किसको? अधिकांश प्रबंधकों ने अभी भी शेड्यूलिंग के लिए वाटरफॉल सॉफ्टवेयर देव प्रक्रिया का उपयोग किया है, और शेड्यूलिंग के लिए यह आसान लगता है।

व्यावहारिक रूप से, बहुत कम डेवलपर्स मुझे पता है कि यह काम करता है या यहां तक ​​कि मान्य है।