चुस्त कार्यप्रणाली क्या है? [बन्द है]

Question

क्या कोई सरल वाक्यों में चुस्त कार्यप्रणाली के बारे में समझा सकता है?

Comments

कॉलेज में मेरे CompSci शिक्षक के अनुसार, "झरना विधि, बस तेज"

— Malfist

@ मालफिस्ट उम्मीद करते हैं कि वह एकेडेमीया में रहे, जहां नुकसान दिमाग तक सीमित हो ;-)

— स्टीवन ए। लोवे

@Steven A. Lowe, दुखद बात यह है कि, हमारी पाठ्यपुस्तक का तीसरा अध्याय "एजाइल सॉफ्टवेयर डेवलपमेंट" है और उन्हें अभी भी इस बात का कोई पता नहीं है कि यह क्या है।

— मालफिस्ट

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

— स्टीवन ए। लोव

चंचल कार्यप्रणाली चीनी भाषा की तरह है - जब तक आप इसे सीख नहीं लेते, तब तक आप इसे प्राप्त नहीं करते;)

— अय्यूब

Answer 1

चंचल बहुत सी चीजें और अभ्यास हैं, लेकिन मुझे लगता है कि इसका मूल सिर्फ पुनरावृत्ति विकास है।

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

यह आपको परियोजना के पाठ्यक्रम को तेजी से बदलने की अनुमति देता है अगर यह पता चलता है कि आप जो कर रहे हैं वह ग्राहक नहीं चाहते हैं, या व्यवसाय को बदलने की जरूरत है, या जो भी हो। इसलिए शब्द "फुर्तीली।"

Comments

यह वास्तव में सही जवाब नहीं है। चंचलता एक पद्धति नहीं है, यह एक दर्शन है।

— रिबॉल्डएड्डी

Answer 2

मुझे लगता है कि कुछ भी नहीं यह केवल एजिल मेनिफेस्टो से बेहतर है:

हम
सॉफ्टवेयर के विकास के बेहतर तरीकों को उजागर कर रहे हैं और इसे करने में दूसरों की मदद कर रहे हैं।
इस काम के माध्यम से हम मूल्य पर आए हैं:

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

यही है, जबकि
दाईं ओर की वस्तुओं में मूल्य है, हम बाईं ओर की वस्तुओं को अधिक महत्व देते हैं।

से http://agilemanifesto.org/

Comments

एकमात्र गोचा यह है कि जब तक आपने खराब प्रक्रिया को नहीं देखा है, तब तक घोषणा पत्र केवल न्याय नहीं करता है। यह वास्तव में प्राप्त करने के लिए बुरे के साथ तुलना करता है कि घोषणापत्र कितना कह रहा है। फिर भी, +1 क्योंकि बहुत से लोग इन दिनों चुस्त और भ्रामक हैं। और फिर भी, वे SCRUM को Scrum + XP के साथ भ्रमित कर रहे हैं।

— MIA

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

— 2388 पर user8865

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

— NoChance

Answer 3

मेरे लिए सबसे महत्वपूर्ण विचार यह है:

आवश्यकताओं में परिवर्तन होने जा रहा है क्योंकि हमें ज्ञान की नादिर पर सॉफ़्टवेयर डिज़ाइन करने के लिए मजबूर किया जाता है जो आवश्यक है (परियोजना की शुरुआत) और आवश्यकताओं को केवल परियोजना के पाठ्यक्रम पर स्पष्ट हो जाएगा।

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

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

Answer 4

एक वाक्य में यह इस तरह दिखता है:

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

यह विकिपीडिया परिभाषा से आ रहा है, और मुझे यह बहुत पसंद है। मैंने मुख्य सिद्धांतों पर प्रकाश डाला।

Answer 5

मैं सिर्फ यह भी जोड़ना चाहूंगा कि एजाइल क्या नहीं है। वहाँ बहुत सारी दुकानें हैं जो दावा करती हैं कि फुर्तीली हैं लेकिन एक तरह से इसका मतलब है कि वे अपनी परियोजनाओं की योजना बनाने में रुचि नहीं रखते हैं और अनुचित रूप से कम समय में किए गए कामों की अपेक्षा करते हैं।

फुर्तीली! = कोई परियोजना योजना नहीं। उन लोगों को संभालना मुश्किल है जो यह सोचते हैं कि कथन गलत है क्योंकि वे प्रबंधन प्रकार के होते हैं और हमेशा विरोधाभास करना आसान नहीं होता है।

Comments

आज तक सवाल पूछने के बाद से मैं ऐसी कुछ कंपनियों का हिस्सा रहा हूं और मैं आपसे सहमत हूं।

— चण्डी पाठक

माना। बहुत से लोग चुस्त सिर्फ चीजों को करने का एक सस्ता तरीका है।

— स्मालचेयर

Answer 6

एंडी पहले ही एजाइल मेनिफेस्टो से जुड़ा हुआ है, जो मुझे लगता है कि इसे कवर करता है।

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

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

Answer 7

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

कंट्रास्ट / वाटरफॉल डेवलपमेंट एप्रोच के साथ जो अप-फ्रंट डिज़ाइन, डॉक्यूमेंटेशन और इंटरफ़ेस डेफिनेशन पर जोर देता है, जबकि कार्यान्वयन से प्रोडक्ट को रिलीज़ करने और डेवलपमेंट से रिलीज़ करने पर ज़ोर देता है।

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

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

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