एजाइल के साथ सफल होने के लिए आपको क्या चाहिए?

Question

चंचल दत्तक ग्रहण कुछ संगठनों में विफल हो सकता है, मैंने यहां तक ​​कि एक ऐसी कंपनी के लिए काम किया जहां झरना एकमात्र (सच्चा) तरीका था, लेकिन केवल इसलिए कि उन्होंने एक परियोजना पर चंचलता की कोशिश की और असफल रहे।

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

मुझे नहीं पता कि परियोजना विफल क्यों हुई। वेब पर ऐसे संसाधन पाए जाते हैं कि एगाइल विफल क्यों है कुछ कंपनियां हैं लेकिन इसका कारण ज्यादातर आर्थिक हैं। तो मैंने सोचा कि मैं यहाँ कुछ प्रतिक्रिया पूछ रहा हूँ।

कुछ संगठनों में एजाइल अपनाने के क्या कारण हैं? या, इसे लगाने का एक और तरीका .. आपको एजाइल के साथ सफल होने के लिए क्या चाहिए?

Comments

इन सभी प्रश्नों को पढ़ें: stackoverflow.com/search?q=agile+failure । फिर अपने प्रश्न को और अधिक विशिष्ट होने के लिए परिष्कृत करें। यह कवर किया गया है। अच्छी तरह से। स्टैक ओवरफ्लो पर।

— सल्ट।

मेरे पास इस तथ्य के अलावा कोई जवाब नहीं है कि नीचे दिए गए उत्तर सभी जीत से भरे हुए हैं ।

— maple_shaft

आपको एजाइल जाने के लिए वास्तविक मूल्य दिखाना है, एजाइल में नहीं जाना है क्योंकि यह एजाइल है। अन्यथा, आप इस वीडियो में CIO के रूप में मूर्खतापूर्ण दिखते हैं ।

आपको अडिग धार्मिक कट्टरता की जरूरत है और यह स्वीकार करने का साहस कि हर असफलता को अधिक फुर्ती से रोका जा सकता था ।

— हारून

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

— जियोर्जियो

Answer 1

आपको चिन्तन और चंचल तरीकों के बारे में समझने और समर्थन करने के लिए प्रबंधन, क्लाइंट और डेवलपर्स की आवश्यकता है। विस्तृत रूप में:

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

मेरे अनुभव में, यह पहला बिंदु है जो सबसे अधिक बार असफल फुर्तीली परियोजनाओं के पीछे है, लेकिन अन्य दो भी समस्याएं पैदा कर सकते हैं।

अपडेट करें

"प्रबंधन" से मेरा मतलब है कि न केवल प्रत्यक्ष परियोजना प्रबंधक, बल्कि उच्च स्तर भी। जैसा कि @Michael ने बहुत ही सही ढंग से उल्लेख किया है, कुछ अधिक या कम बाहरी पक्ष (जैसे QA या बाहरी कार्य असाइनर) भी फुर्तीली परियोजनाओं की सफलता / विफलता को प्रभावित कर सकते हैं, लेकिन मुझे लगता है कि यह तभी संभव हो सकता है जब उनके संबंधित नेता उन्हें अनुमति दें, और / या यदि जिम्मेदारियों और आदेशों की रेखाएँ संगठन के भीतर स्पष्ट नहीं हैं।

Comments

+1: प्रबंधन चुस्त तरीकों का एकल सबसे बड़ा प्रतिद्वंद्वी है। विशेष रूप से, यह लेखांकन है। "जिम्मेदार" प्रबंधन का मतलब है कि एक शेड्यूल और बजट होना चाहिए जो अप्रत्याशित भविष्य में योजनाबद्ध हो। हमेशा असंभव।

— सल।

Answer 2

आप की जरूरत है:

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

ऐसा लगता है कि सरल है, लेकिन इनमें से बहुत से इस उद्योग में बहुत बड़े हैं।

Comments

[phone] अगर मैं "ग्राहक और प्रबंधक जो वास्तव में सच सुनना चाहते हैं" पर!

— maple_shaft

... वसीयत पर फिर से माहौल बनाने और व्हाइटबोर्डिंग के महत्व पर उत्कृष्ट टिप्पणी। यदि प्रति वर्ष सूखी मिटा मार्करों के लिए कंपनी बजट तो सैकड़ों में नहीं है कि आपके पास पर्याप्त व्हाइटबोर्डिंग नहीं कर रहे हैं :)

— maple_shaft

अभी-अभी मेरा घर का ऑफिस खत्म हुआ। एक दीवार सफेद बोर्ड पेंट में कवर की गई। यह वास्तव में कमरे को एक साथ जोड़ता है।

— जेएफओ

Answer 3

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

उदाहरण:

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

Answer 4

मैं केवल अपने निजी अनुभव से अपनी सलाह दे सकता हूं।

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

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

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

ऐसा लगता है कि एजाइल को किसी कंपनी में सफल होने के लिए, आपको निम्नलिखित चीजों की आवश्यकता है:

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

EDIT: यह सुनिश्चित करने के लिए भी महत्वपूर्ण है कि आपके पास -why की अच्छी समझ है- दैनिक स्टैंड-अप और लघु पुनरावृत्तियों जैसी चीजें उपयोगी हैं।

Answer 5

चंचल असफलता के साथ मेरे अनुभवों का अर्थशास्त्र के साथ लेकिन कॉर्पोरेट / विभागीय / व्यक्तिगत राजनीति से कोई लेना-देना नहीं है।

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

इसके बाद, वहाँ विकास प्रबंधन है। मैंने देखा है कि यह दो अलग-अलग तरीकों से गलत है।

सबसे पहले 'कार्गो पंथ एजाइल' है, जहां प्रबंधक घोषणा पत्र का पालन करने पर जोर देता है और जो भी वर्ग / पुस्तक / वेबसाइट है, वह बिना कारण को समझने के लिए कि उन्हें कब और कब और कैसे उपयोग करना है। यह ऐसा है मानो चंचल प्रबंधक जादू होने की प्रतीक्षा कर रहा है क्योंकि वे वास्तव में जादू का अनुसरण कर रहे हैं। एजाइल के इस सर्वव्यापी कार्यान्वयन से कई समस्याएं हो सकती हैं जो परियोजना की विफलता का कारण बनेंगी।

दूसरा 'एगाइल इन नेम ओनली' है, जहां स्प्रिंट और स्क्रैम जैसी शब्दावली का इस्तेमाल किया जाता है, लेकिन वास्तव में माइक्रो-मैनेजमेंट, बेईमानी, जैसे दोनों और कमांड के चेन में ऊपर जाने के लिए लेबल होते हैं, बेकार की स्टेटस मीटिंग और दूसरे ऐसे सामान। । परियोजनाएं वैसे ही विफल हो जाती हैं जैसे वे करते थे, लेकिन अब एजिले को इसके लिए खराब प्रबंधन के बजाय दोषी ठहराया जा सकता है।

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

Answer 6

IMO "फुर्तीली" तब विफल हो जाती है जब प्रथाओं का थोक खरीद नहीं होता है। मेरा मतलब यह है कि एजाइल "ग्राहक" (आमतौर पर किसी अन्य विभाग या प्रबंधक) पर निर्भर करता है:

1. वे 100% नहीं जानते कि वे क्या करना चाहते हैं सॉफ्टवेयर, भले ही वे सोचते हैं कि वे करते हैं
2. उन्हें नहीं पता कि इसे पूरा करने में कितना समय लगेगा, भले ही उन्हें लगता हो कि वे ऐसा करते हैं
3. उन्हें बताया जाएगा कि कितना समय लगेगा और इसे स्वीकार करना होगा या समय सीमा को पूरा करने के लिए सुविधाओं को कम करना होगा
4. उन्हें प्रत्येक पुनरावृत्ति की विशेषताओं को चुनना होगा और एक शॉट में पूर्ण, 100% पूर्ण आवेदन नहीं मिलेगा।

उन सभी में से अधिकांश प्रबंधकों को निगलने के लिए बहुत मुश्किल चीजें हैं, और आईएमओ # 1 कारण है कि यह चुस्त करने के लिए कठिन है - प्रबंधकों को यह कहने के लिए उपयोग किया जाता है कि "यह x तारीख तक किया जाएगा" और इसे "जादुई रूप से" उस तारीख तक किया जाएगा। (डेवलपर्स ने 80 घंटे के हफ्तों में डाल दिया) और यह महसूस करने के लिए 180 है कि विकास टीम आपको यह बताने जा रही है कि यह परियोजना 3 महीने में हो जाएगी, और आपके पास एकमात्र विकल्प इसे स्वीकार करना है या प्राप्त करने के लिए आवश्यकताओं को कम करना है। यह जल्द ही किया।

दूसरा, विकास टीम में विश्वास होना चाहिए। ऊपर # 1 के साथ हाथ से जाना, बहुत कम प्रबंधक वास्तव में विशेषज्ञों के रूप में काम पर रखे गए लोगों की राय पर भरोसा करते हैं; यदि कोई डेवलपर कहता है कि एक परियोजना में x राशि लगेगी, और x प्रबंधन की सोच से अधिक है, तो यह कभी नहीं होगा "मुझे सॉफ्टवेयर लिखने का तरीका नहीं पता है, इसलिए डेवलपर शायद सही है" यह अधिक है " उन अच्छे-से-कुछ भी नहीं डेवलपर्स काम से दूर जाना चाहते हैं, इसलिए उन्होंने कहा कि इसमें 3 महीने लगेंगे ”।

तीसरा, आपकी विकास टीम को एजाइल के पीछे रहने की जरूरत है; इसका मतलब है कि कोनों को नहीं काटना और लगातार प्रतिक्रिया और "क्या यह सही है? के सवालों को अनदेखा नहीं करता; जब x होता है तो Y क्या करना चाहिए?"। यहां तक ​​कि अगर आप टीडीडी या पेयर प्रोग्रामिंग का पालन नहीं करते हैं, तो आपकी विकास टीम को फुर्तीली प्रक्रियाओं (जैसे स्प्रिंट, पुनरावृत्तियों) का पालन करने के लिए पर्याप्त सक्षम होना चाहिए। इसमें एक लीड / मैनेजर शामिल होता है जो कार्यों का ठीक से अनुमान लगा सकता है और समझता है कि आपको हर सुविधा को प्राथमिकता बनाने की आवश्यकता नहीं है, काम का एक बैकलॉग होना ठीक है, और आपको लोगों को ओवरवर्क नहीं करना चाहिए।