जब एजाइल गलत हो जाता है [बंद]

Question

मैं कुछ नए लोगों के लिए एक एजाइल पाठ्यक्रम लिख रहा हूं जो हम हाल ही में ऑन-बोर्डिंग कर रहे हैं, और मैं एक सावधानी कथा जोड़ना चाहता हूं ताकि वे समझें कि एजाइल सभी परियोजनाओं के लिए नहीं है।

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

जब एक फुर्तीली परियोजना गलत हो जाती है तो किन चीजों को देखना है?

Comments

चंचल के बारे में मैंने सुना है कि डरावनी कहानियों में से अधिकांश उन लोगों के बारे में थे जो उस तरह की परियोजना से जुड़े थे, जिस पर वे काम कर रहे थे।

— Matthieu

मुझे कई प्रश्न दिखाई देते हैं जो "संबंधित" खंड में

— फुर्तीले

मैंने कहानी के समय को आमंत्रित नहीं करने के सवाल को संशोधित किया और इसके बजाय व्यक्तिगत ठोस तथ्यों के बारे में पूछा कि एजाइल कहां गलत है।

— maple_shaft

@Oded "कार्यक्षमता पर दिए बिना कठिन समय सीमा" होने पर क्या दृष्टिकोण अच्छी तरह से काम करता है ?

— अतार्किक जॉन

@irrationalJohn - मृत्यु मार्च, ज़ाहिर है;)

— Oded

Answer 1

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

• दैनिक स्टैंडअप (जो एक या एक घंटे तक चलता है)
• स्प्रिंट में काम तोड़ना
• उपयोगकर्ता कहानियां (जो आमतौर पर एक वाक्य से थोड़ी अधिक होती हैं लेकिन एक अनुमान अपेक्षित होता है)

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

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

अन्य प्रमुख वाक्यांश: "मुझे पता है कि ये कहानियां पूरी तरह से परिभाषित नहीं हैं, लेकिन हम चुस्त हैं ताकि हम उन्हें ठीक कर सकें जैसे हम जाते हैं।"

"हम चुस्त विकास कर रहे हैं ताकि आप स्प्रिंट के भीतर जो मुझे पहचानते हैं उसकी आवश्यकता हो।

"हम स्प्रिंट की शुरुआत में अपनी प्रतिबद्ध कहानियों को बंद करने में सक्षम नहीं हैं क्योंकि मध्य-स्प्रिंट को बदलने की आवश्यकता है।"

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

Comments

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

— Péter Török

बस एक तरफ, क्या आप बता सकते हैं कि "बॉयलर रूम की मानसिकता का क्या मतलब है"? मैंने इसे पहले सुना है, बस एक स्पष्टीकरण कभी नहीं सुना है।

— केविन मैककॉर्मिक

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

— नरक

"... प्रोजेक्ट लीड (स्क्रैम मास्टर) ...": मैंने हाल ही में बॉब मार्टिन की एक बात को ध्यान में रखते हुए सुना कि स्क्रैम मास्टर शुरुआत में प्रोजेक्ट लीड नहीं था: यह एक भूमिका थी जिसे बीच में घुमाया जाना था। टीम के सदस्यों (डेवलपर्स परियोजना में शामिल हैं, प्रबंधक नहीं) और केवल यह जांचना चाहिए था कि कुछ चुस्त सिद्धांत पूरे स्प्रिंट में लागू किए गए थे।

— जियोर्जियो

Answer 2

लोगों को समझ में नहीं आया कि फुर्तीली क्या है (?) इसके बारे में और इसे लागू करने के लिए:

• क्लाइंट जो समय सीमा तक टिप्पणी के लिए अनुपलब्ध हैं
  ... और बाद में कानूनी कार्रवाई की धमकी देते हैं ;

• ऐसे प्रबंधक जो डेवलपर्स को ग्राहक से दूर रखते हैं , (शायद इसलिए कि वे थोड़े से कम कर रहे हैं, और जहाज कूद सकते हैं, उक्त ग्राहक के लिए काम करने जा रहे हैं) और हताश (अक्सर सफल, हालांकि) प्रयास में " टूटे हुए टेलीफोन " का एक खेल खेलते हैं। व्यस्त और उपयोगी देख रहे हैं,

  यह भी देखें: मशरूम प्रबंधन , उर्फ "अस्पष्ट, तंग खाद" और नुकीले बालों वाले मालिकों को रखा । :)

• ऐसी टीमें जो कहीं भी जाने के लिए बहुत बड़ी हैं;

• कंपनियों है कि उनके वेतन पर रख रहे हैं एक बार प्रसिद्ध प्रणाली वास्तुकला डिजाइनरों कि सख्त तथ्य वे पूरी तरह से वास्तविक कोडिंग शिल्प की दृष्टि खो दिया है से ध्यान डाइवर्ट कर रहे हैं, द्वारा overdesigning शानदार, अव्यावहारिक, मुश्किल से एहसास, यूएमएल Sagrada familias ।

Comments

वाह, चीनी फुसफुसाते हुए, वास्तव में? लगता है हेला जातिवाद।

— मार्क कैनलास

मैं नस्लवाद के बारे में आपके पाखंडी आक्रोश से सहमत नहीं हूँ। जातिवादी को विषय पर विकिपीडिया प्रविष्टि और ऑक्सफोर्ड शब्दकोश 2008 संस्करण के संदर्भ में बताएं ।

— ZJR

@ कान्लास आप ध्वनि को उत्तर-अमेरिकी कहते हैं।

— ZJR

पृथ्वी पर क्या playing a game of "telephone"मतलब है? वास्तव में यह मत सोचो कि संपादन किसी भी तरह से आवश्यक था ...

— Cocowalla

खेल का वास्तविक नाम "ब्रोकन टेलीफोन" (पहले से ही संपादित) है और जैसा कि ZJR ने नस्लवादी वाक्यांश नहीं बताया है, मैंने वास्तव में विकिपीडिया लेख को "ब्रोकन टेलीफोन" से जोड़ा है और क्या लगता है? यह "चीनी फुसफुसाते हुए" =) को पुनर्निर्देशित करता है

— चेचेक

Answer 3

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

जब आप वृद्धिशील अद्यतन कर रहे हैं और बग फिक्स कर रहे हैं, तो एजाइल पोस्ट-प्रोजेक्ट चरण के लिए बहुत अच्छा है।

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

Comments

इसे पकड़ो। क्या आप वास्तव में सोचते हैं कि अधिकांश फुर्तीली परियोजनाओं को "हमेशा के लिए" जारी रखने का इरादा है?

— user16764

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

— gbjbaanb

औपचारिक रूप से, एक परियोजना कभी भी समाप्त नहीं होती है; किसी प्रोजेक्ट की एकल कुंजी परिभाषित करने वाली विशेषता यह है कि इसकी अंतिम (प्रारंभ) और अंतिम तिथि है। यह ऐसे उत्पाद और सेवाएँ हैं जिन्हें आप दीर्घकालिक बनाए रखते हैं।

— डोनल फैलो

"संचार की खराब लाइनें": जहां तक ​​मुझे पता है, चुस्त द्वारा अच्छे संचार की खोज नहीं की गई है, और फुर्तीली कार्यप्रणाली बहुत कम ही ऐसी टीम कर सकती है जो संवाद करने में सक्षम नहीं हैं।

— जियोर्जियो

Answer 4

यहां कुछ प्रश्न दिए गए हैं जो एक उदाहरण खोजने के संदर्भ में उत्तर की तलाश में उपयोगी हो सकते हैं जहां एजाइल का प्रयास खराब हो सकता है:

• क्या चुस्त नया micromanagement है?
• चंचल प्रक्रिया: कैसे और क्या प्रलेखित किया जाना चाहिए?
• एक नई परियोजना पर योजना और प्रोग्रामिंग का सही मिश्रण

क्या आपने कभी "छद्म फुर्तीली" के बारे में सुना है? यहाँ इसके बारे में ब्लॉग प्रविष्टियों की एक जोड़ी है:

• स्यूडो-एजाइल से वाटरफॉल तक - एक छोटी और नई सॉफ्टवेयर कंपनी का रास्ता
• छद्म फुर्तीली!

कंपनियों के लिए ऐसा कुछ कहा जा सकता है जो कि फुर्तीले और कसाई के लिए कुछ और ही हो।

Answer 5

मैंने एक बहुत सफल चुस्त टीम पर काम किया, साथ ही चंद लोगों ने भी चंचलता का प्रयास किया, लेकिन वह काम नहीं कर पाया।

सफल में निम्नलिखित तत्व थे:

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

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

मैं जिस टीम पर था, वह एजाइल ने अच्छा नहीं किया, उसके कुछ तत्व भी थे:

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

Comments

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

— एमोस कारपेंटर

Answer 6

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

इसका मतलब यह है कि सार्वजनिक कंपनियों (उदाहरण के लिए सरकारें) में, इसे ठीक से काम करना बहुत मुश्किल होगा।

Answer 7

मैं व्यक्तिगत अनुभव से यह नहीं जानता, लेकिन काल्पनिक रूप से, कई परिस्थितियां हैं जब चुस्त सबसे अच्छा विकल्प नहीं है।

• ऐसे प्रोजेक्ट जिनके उत्पाद जीवन या संपत्ति महत्वपूर्ण हैं - उदाहरण के लिए, आप अपने पेसमेकर को चलाने वाले सॉफ़्टवेयर को विकसित करने के लिए फुर्तीली का उपयोग नहीं करना चाहते हैं। क्यूं कर? क्योंकि त्रुटियों के लिए आपके पास शून्य-सहिष्णुता है। थेरैक 25 के संबंध में चिकित्सा के भीतर प्रोग्रामिंग त्रुटि के एक उत्कृष्ट उदाहरण पर विचार करें । दी, यह चुस्त नहीं बनाया गया था, लेकिन मुद्दा यह है: जीवन या संपत्ति के विकास को यह कहने के लिए कोई जगह नहीं है, "हम अगले स्प्रिंट पर साफ करेंगे" या "हमें महान, बस अच्छे की जरूरत नहीं है" पर्याप्त।"

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

• ऐसी परियोजनाएँ जिन्हें पारंपरिक रूप से एजाइल के साथ पेश किए जाने की तुलना में अधिक नियंत्रण या नियोजन की आवश्यकता होती है।

मैं मान रहा हूं कि या तो कोई और इसमें कूद जाएगा और बेहतर उदाहरणों के साथ मदद करेगा, या मैंने जो भी किया है उसका थोड़ा सा ट्रिप डाउन कर दिया है;

बस याद रखें कि जब आपके पास एकमात्र उपकरण हथौड़ा है, तो हर समस्या नाखून की तरह दिखती है। सभी परियोजनाएं नाखून नहीं हैं।

Comments

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

— मैथ्यू फ्लिन

Answer 8

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

मैं जरूरी नहीं कहूंगा कि वाटरफॉल ऐसे वातावरण में काम करेगा, यह एक श्वेत और श्याम स्थिति नहीं है, वास्तव में बहुत कम काला और सफेद है।

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

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

फुर्तीली फुर्तीली कई मायनों में एक सफल सफल झरना टीम से भी बदतर है और शायद कम परियोजना सफलता दर है।

Comments

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

— चेपेक