चंचल रेड का एक संस्करण है?


16

विकिपीडिया का कहना है कि एजाइल एक प्रकार का "राड" है जो मुझे लगता है कि गलत है। मुझे जो पता है, उससे एजाइल को विकसित किया गया था क्योंकि ब्रेड राड खुद 90'S (बदलावों के लिए बहुत कठोर) में सक्सेफुल नहीं था। या मैं गलत हूँ?

(टिप्पणी: जाहिरा तौर पर एजाइल सॉफ्टवेयर विकास पर विकिपीडिया लेख के बीच में सुधार हुआ था, यह सिर्फ आरईडी के पूर्ववर्ती के रूप में रेड को सूचीबद्ध करता है , सुपरसेट के रूप में नहीं)।

एक पुस्तक रेडिकल प्रोजेक्ट मैनेजमेंट (थॉमसन) का एक संदर्भ

"..नव, फुर्तीली, वस्तु उन्मुख जैसे कुछ विकास सनक ..."

CISA प्रमाणित सूचना प्रणाली लेखा परीक्षक:

.. दो वैकल्पिक सॉफ्टवेयर देव से अनभिज्ञ तरीके: फुर्तीली और तेजी से अनुप्रयोग विकास

सॉफ्टवेयर के लिए चुस्त प्रबंधन:

चुस्त तरीके ज्यादातर राड के हल्के दृष्टिकोण से प्राप्त होते हैं।

सॉफ्टवेयर अनुमान सर्वोत्तम अभ्यास:

स्वा की प्रमुख विधियाँ। देव। इस प्रकार संक्षेप किया जा सकता है:
1. झरना ..
4. RAD
5. चंचल

इस सवाल का मुद्दा यह है:
क्या चुस्त या रेड स्टैंडअलोन विकास दृष्टिकोण का एक प्रकार है?


1
रेड = रैपिड एप्लीकेशन डेवलपमेंट। फुर्तीली निश्चित रूप से उस श्रेणी में आती है।
Oded

2
@Oded: बहुत सारे स्रोतों से कैसे आता है ऐसा नहीं कहता है? मुख्य रूप से क्योंकि तेजी से वितरण के उद्देश्य से किया गया था क्यों अनुकूलन क्षमता पर चुस्त, जो "चुस्त" शब्द से दर्शाया गया है
जॉन वी

1
निश्चित रूप से, चुस्त अनुकूलनशीलता के बारे में है, लेकिन साथ ही यह उच्च प्राथमिकता वाली वस्तुओं को तेजी से वितरित करने के बारे में है ।
Oded

1
"विकिपीडिया कहता है" - लेख में , कथन के पास एक संकेत "उद्धरण की आवश्यकता है" जो इस बात के निकट है कि "तीव्र विधियाँ रैपिड एप्लिकेशन डेवलपमेंट के साथ बहुत आम हैं" - यह कथन विकिपीडिया मानकों तक नहीं है
gnat

1
"स्टैंडअलोन डेवलपमेंट एप्रोच" से आपका क्या मतलब है?
थॉमस ओवेन्स

जवाबों:


15

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

तो नहीं, फुर्तीली सॉफ्टवेयर डेवलपमेंट एक प्रकार का RAD नहीं है; वे अमूर्तता के विभिन्न स्तरों पर समस्याओं का समाधान करते हैं।


मुझे लगता है कि वास्तव में, मुझे लगता है कि विकी को अद्यतन किया जाना चाहिए।
जॉन वी

2
वैसे यह संपादन योग्य है ताकि आप ऐसा कर सकें ;-)

11

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

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


1
यही कारण है कि उत्पादों की भाषा से अलग-अलग भाषाओं में प्रोटोटाइप बनाने के लिए चुस्त प्रस्तावित: प्रोटोटाइप आमतौर पर सही ढंग से नहीं किया जाता है। उदाहरण के लिए उत्पाद के लिए प्रोटोटाइप बनाम सी ++ के लिए
मैटलैब

-1

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


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