क्या चुस्त विकास पद्धति का एक व्यवहार्य विकल्प है?


47

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

लेकिन असली अंतर कहीं अधिक गहरा है, जिसमें ये प्रथाएं एक दर्शन से आती हैं।

झरना कहता है: परिवर्तन महंगा है, इसलिए इसे कम से कम किया जाना चाहिए।
चंचल कहते हैं: परिवर्तन अपरिहार्य है, इसलिए परिवर्तन को सस्ता बनाओ।

मेरा सवाल यह है कि टीडीडी या कार्यात्मक चश्मे के बारे में आप क्या सोचते हैं, क्या जलप्रपात विकास पद्धति वास्तव में व्यवहार्य है?

क्या कोई वास्तव में सोचता है कि सॉफ्टवेयर में परिवर्तन को कम करना उन लोगों के लिए एक व्यवहार्य विकल्प है जो मूल्यवान सॉफ्टवेयर देने की इच्छा रखते हैं? या क्या वास्तव में यह सवाल है कि अपरिहार्य परिवर्तन को प्रबंधित करने के लिए हमारी स्थितियों में किस तरह की प्रथाएं सबसे अच्छा काम करती हैं?


1
दिलचस्प सवाल। जवाब के लिए आगे देख रहे हैं।
DevSolo


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

1
@ यानिस रिज़ोस: आप अकेले एक समुदाय के वोट के बिना इस दिलचस्प सवाल को बंद क्यों कर रहे हैं?

1
@ Pierre303 इस सवाल के कारण जो यहाँ चर्चा ने इस सवाल को उठाया।
रायथल

जवाबों:


59

बेशक झरना व्यवहार्य है। यह हमें चाँद पर ले आया!

और यह एक चुस्त कोच यहाँ बात कर रहा है!

जब तक आप स्पष्ट रूप से अपनी परियोजनाओं को प्रबंधित करने के तरीके से संबंधित समस्याओं की पहचान नहीं कर सकते, तब तक बदलने का कोई वैध कारण नहीं है।

चंचल और झरने के तरीकों के विकल्प के रूप में , मैं आपकी कार्यप्रणाली का सुझाव दूंगा । आपके विशिष्ट व्यवसाय, आपकी विशिष्ट टीम, आपके उत्पाद, आपके काम करने के तरीके, आपकी कंपनी संस्कृति के अनुकूल है ... इसीलिए Scrum को कार्यप्रणाली के बजाय एक सरल ढाँचा कहा जाता है ।

एक कार्यप्रणाली को लागू करना चाहते हैं क्योंकि किसी ब्लॉग पर जिस व्यक्ति के बारे में आप बात करते हैं वह उतना ही बेवकूफ है जितना कि समस्याओं को बिना कुछ किए जाने देना।


10
+1 आपकी कार्यप्रणाली पर, अगला फुर्तीला कोच जो मुझे बताता है कि
SCRUM

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

5
सिर्फ चांद नहीं। अंतरिक्ष यान के एम्बेडेड सिस्टम में C कोड की ~ 1M लाइनें थीं। ~ 30 से अधिक वर्षों में उनके पास केवल 2 कीड़े थे जो इसे निर्माण बनाता है।
दान नीली

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

4
@ डैनेली स्पेस शटल सॉफ़्टवेयर का उच्च गुणवत्ता स्तर सस्ता नहीं था। स्पष्ट रूप से कीमत $ 1000 प्रति पंक्ति के आकार में थी

21

पहले, मैं आपके बयानों से असहमत होने जा रहा हूं:

झरना कहता है: परिवर्तन महंगा है, इसलिए इसे कम से कम किया जाना चाहिए।
चंचल कहते हैं: परिवर्तन अपरिहार्य है, इसलिए परिवर्तन को सस्ता बनाओ।

मेरी व्याख्या है:

झरना कहता है: ग्राहक जानता है कि उन्हें क्या चाहिए।
एजाइल कहते हैं: ग्राहक को पता नहीं है कि वे क्या चाहते हैं इसलिए हम कुछ अलग संस्करण बनाने जा रहे हैं।

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

या, आप कर सकते हैं कि हम क्या करते हैं, जो चारों ओर चला जाता है और वह करता है जो सबसे हाल की शिकायत / बग रिपोर्ट है, और उस चुस्त को कॉल करें ।



11
यह अधिक पसंद है "झरना कहता है: ग्राहक को पता नहीं है कि वे क्या चाहते हैं ताकि हम बैठ जाएं, इस पर बात करें और इस पर सहमत हों कि वे इससे पहले कि हम इसे हैक करना शुरू करें" ...
11:17 पर

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

6
@scrwtp - और एजाइल अधिक पसंद है "मेरे ग्राहक को पता नहीं है कि वे क्या चाहते हैं, और वह बात नहीं कर सकता / नहीं कर सकता है और इसे सोच नहीं सकता है, और वे हर 5 मिनट में अपना दिमाग बदलते हैं। मुझे उनके चेहरे पर कुछ चमकाना होगा। किसी भी सार्थक जवाब पाने के लिए "। वाह। जब मैं इसे लिखता हूं तो यह वास्तव में दुर्भाग्यपूर्ण लगता है।
माइकल कोहेन

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

21

आप कह कर शुरू करते हैं:

दो प्रमुख सॉफ्टवेयर-विकास दर्शन जलप्रपात और फुर्तीले हैं।

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

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

तो हाँ, निश्चित रूप से चुस्त करने के लिए एक व्यवहार्य विकल्प है।


6
मैं यह समझने में सक्षम नहीं हूं कि उस लिंक से OPEN / Metis क्या है। (आमतौर पर आपको कार्यप्रणाली डाउनलोड करने की आवश्यकता नहीं होती है।) मेरा प्रश्न है: यह दर्शन क्या है, विशेष रूप से परिवर्तन से निपटने में? क्या यह परिवर्तन को कम करने, या परिवर्तन की लागत को कम करने का प्रयास करता है? ध्यान रखें कि मेरा प्रश्न चुस्त दर्शन के बारे में था, न कि चुस्त प्रथाओं के बारे में।
एरिक विल्सन

OPEN / Metis में पुनरावृत्त जीवनचक्र होता है जो सिस्टम को वृद्धिशील रूप से बनाता है। बदलें कुछ है कि न केवल होता है, लेकिन कुछ है कि के रूप में स्वीकार किया है महान के बाद से एक सूचना प्रणाली के विकास का उद्देश्य कुछ परिवर्तन को प्रभावित करने के लिए है, जब ऐसा होता है। परिवर्तन की लागत, हालांकि, एक उपयुक्त जीवनचक्र और संबंधित प्रथाओं के माध्यम से नियंत्रित और प्रबंधित की जाती है।
सीजरगॉन

1
"डाउनलोडिंग मेथडोलॉजी" के बारे में आपकी टिप्पणी के बारे में, अच्छी तरह से ... आप कार्यप्रणाली डाउनलोड नहीं करते हैं, मैं सहमत हूं। आप कार्यप्रणाली का वर्णन करने वाले दस्तावेज़ डाउनलोड करते हैं। अन्यथा, आप उनके बारे में कैसे सीखते हैं? एक्सपी,
स्क्रैम


10

हां, आपकी समस्या डोमेन के आधार पर विभिन्न सॉफ़्टवेयर डेवलपमेंट तकनीक सभी व्यवहार्य हैं। यह "कोर्स के लिए घोड़े" है।

उदाहरण के लिए, आप एक परमाणु ऊर्जा संयंत्र को नियंत्रित करने या नासा के अंतरिक्ष यान को चलाने के लिए सॉफ्टवेयर लिख रहे हैं। इस तरह की समस्या डोमेन शायद एक झरना (या यहां तक ​​कि सख्त) दृष्टिकोण के लिए बेहतर अनुकूल है, आप यदि संभव हो तो सभी मुद्दों को सामने रखना चाहते हैं (या बूम!)।

नवीनतम वेब 2.0 / 3.0 / buzzy मार्केटिंग शब्द UI का निर्माण? एजाइल जाने का एक बेहतर तरीका है (यो को उस त्वरित प्रतिक्रिया और परिवर्तन की आवश्यकता है)।

वहाँ क्या मैं सॉफ्टवेयर शिल्प कौशल सिद्धांतों है कि अभी भी लागू किया जा सकता है कोई बात नहीं कहेंगे पद्धति नहीं है जैसे:

  • स्रोत नियंत्रण
  • निर्माण और CI
  • जोड़ा प्रोग्राम तैयार करना
  • TDD
  • मैं ^% $ $ और देता हूं

और अधिक।

जो कुछ भी आप करते हैं, समीकरण के दोनों ओर के ज़ीलोट्स को न सुनें, आपके, आपकी टीम और आपके समस्या डोमेन के लिए क्या सही है।


यदि आप इसे वहन कर सकते हैं तो झरना काम करता है। ऊपर किसी ने दावा किया कि नासा चंद्रमा परियोजना सॉफ्टवेयर लागत लगभग 1000 डॉलर प्रति पंक्ति कोड थी। अधिकांश दुकानों को $ 1-10 प्रति पंक्ति कोड की तरह कुछ चाहिए और फुर्तीली उस तरह की स्थितियों के लिए बेहतर है। हालांकि, मैं यह ढोंग नहीं करता कि चुस्त समग्र रूप से बेहतर गुणवत्ता प्रदान करता है। यह मूल रूप से उबलता है कि क्या आप बहुत सारा पैसा पृष्ठ पर रख सकते हैं, यह सुनिश्चित करने के लिए कि सॉफ्टवेयर सही है या क्या आपको यह पता लगाना सस्ता है कि सॉफ्टवेयर सही नहीं है।
मिको रानाल्टेन 11

2

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

सॉफ्टवेयर बदलता है। सॉफ्टवेयर तेजी से बदलता है। मूर का नियम कहता है कि चिप पर ट्रांजिस्टर की संख्या हर 18-24 महीनों में दोगुनी हो जाती है। कोरोलरी में, एक प्रोग्राम में कोड की लाइनों की संख्या भी दोगुनी हो जाती है। कोड की उन पंक्तियों के बीच की जटिलता इसलिए 2 ^ (2t) जैसी किसी चीज़ के बिगओ के साथ बढ़ती है।

सॉफ्टवेयर तेजी से बदलता है और इसके साथ जटिलता तेजी से बढ़ती है।

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

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

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

वैसे भी, मेरे 2 सेंट।


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

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

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

1
हाय Stephan, नहीं सभी सॉफ्टवेयर आवश्यकताओं को लगातार बदलते हैं।
पॉल नाथन

1
व्यवसाय हमेशा बदलता रहता है ; एक व्यवसाय जो बदल नहीं रहा है और आदत डाल रहा है वह व्यवसाय है जो मर रहा है। समय एक स्थिर है , जो परिवर्तन के साथ बातचीत नहीं करता है। एक प्रणाली जिसमें दर्शन है जो परिवर्तन को स्वीकार करता है, उम्मीद है कि परिवर्तन को समायोजित कर सकता है, अन्यथा, समय को परिवर्तन को समायोजित करना पड़ता है, और यह एक अविरल स्थिर है!

2

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

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

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

और अगर OPEN / Metis पुनरावृत्त और वृद्धिशील है, तो मेरे लिए, ऐसा लगता है कि इसमें फुर्तीला दर्शन है भले ही यह अन्य सामान्य चुस्त प्रथाओं के साथ खुद को संबद्ध न करता हो।


2
तो अब चुस्त पुनरावृत्ति और वृद्धिशीलता का श्रेय लेने की कोशिश कर रहा है? कभी भी इस बात पर ध्यान न दें कि '92 में विकास शुरू करने के बाद से पुनरावृत्त और वृद्धिशील जलप्रपात विकास के अधिक भाग रहे हैं।
डंक

1

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

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

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

क्या कोई वास्तव में सोचता है कि सॉफ्टवेयर में परिवर्तन को कम करना उन लोगों के लिए एक व्यवहार्य विकल्प है जो मूल्यवान सॉफ्टवेयर देने की इच्छा रखते हैं?

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

या क्या वास्तव में यह सवाल है कि अपरिहार्य परिवर्तन को प्रबंधित करने के लिए हमारी स्थितियों में किस तरह की प्रथाएं सबसे अच्छा काम करती हैं?

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

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

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

  • व्यक्तियों और प्रक्रियाओं और उपकरणों पर बातचीत
  • व्यापक प्रलेखन पर काम कर रहे सॉफ्टवेयर
  • अनुबंध बातचीत पर ग्राहक सहयोग
  • एक योजना के बाद बदलने का जवाब

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


2
वाह। यहाँ सिर्फ इतना अजीब सामान है। झरना लंबे समय तक रहने के आधार पर व्यवहार्य है? रक्षा अनुबंध में उपयोग के आधार पर झरना उचित है? क्या प्रत्येक अवसर को ग्राहक के सर्वोत्तम हित में वास्तव में परिवर्तन को कम करने का अवसर है, या क्या उसे वह पहुंचाने की ओर ले जाता है जो उसने सोचा था कि वह वास्तव में वह चाहता था जो वह चाहता था? चूंकि आप इस बारे में परवाह करते हैं, इसलिए मैंने यह समझने की कोशिश की है कि आप कहां से आ रहे हैं, लेकिन मुझे कुछ याद आ रहा है।
एरिक विल्सन

1
@ EricWilson झरना लंबे समय तक रहा है और चुस्त दर्शन पर चर्चा करने से पहले इसका सफलतापूर्वक उपयोग किया गया था। यह व्यवहार्य है क्योंकि यह मौजूद है और जब इसे ठीक से लागू किया जाता है जो इसका उपयोग करना चाहते हैं। मैंने इसके उपयोग को उचित नहीं ठहराया, लेकिन केवल एक उदाहरण की ओर इशारा किया, जहाँ मुझे व्यक्तिगत अनुभव है जहाँ मैंने इसे काम करते देखा है, और हाँ, मैंने कुछ शानदार असफलताएँ भी देखी हैं। आप परिवर्तन को कम करने के अवसरों की तलाश नहीं करते हैं, आप बदलावों को पेश करने के अवसर चाहते हैं, लेकिन आपको इसे समझदारी से करने की आवश्यकता है, अन्यथा आपके ग्राहक को या तो वे कम चाहते हैं या वे एक समय सीमा समाप्त कर देते हैं।
S.Robins

0

हां, झरना, सर्पिल, Iterative और अन्य संकर प्रक्रिया मॉडल सभी व्यवहार्य हैं, लेकिन परिवर्तन अपरिहार्य है। प्रक्रिया केवल परिवर्तन को संभालने के तरीके के बारे में अधिक है, और (मेरा दावा है कि) सबसे बड़ा निर्धारक है कि आप समस्या को कितनी अच्छी तरह से जानते / समझते हैं, और आप कितनी सही योजना बना सकते हैं और भविष्यवाणी कर सकते हैं।

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

झरना कहता है: परिवर्तन महंगा है, इसलिए इसे कम से कम किया जाना चाहिए।

चंचल कहते हैं: परिवर्तन अपरिहार्य है, इसलिए परिवर्तन को सस्ता बनाओ।

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

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

और जब अनुमान गलत होते हैं, तो अक्सर प्रक्रिया (लोहे के त्रिकोण का चौथा पैर) अनुसूची को पूरा करने के लिए बलिदान किया जाता है।


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

SDLC, en.wikipedia.org/wiki/Systems_development_life_cycle , tutorialspoint.com/sdlc/sdlc_overview.htm , इत्यादि के बारे में कृपया पढ़ें
ChuckCottrun

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

-1

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


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

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