कौन सी प्रोग्रामिंग कार्यप्रणाली हमारे लिए एक अच्छी फिट होगी?


11

दुर्भाग्य से, किसी ने हमारे ऊपरी प्रबंधन को "एजाइल" शब्द सिखाया है और अब वे चाहते हैं कि हम इसकी ओर बढ़ें। मुझे फुर्तीली (सिद्धांत रूप में) की एक परिधीय समझ है लेकिन व्यवहार में इसका इस्तेमाल कभी नहीं किया है। जो मैं जानता हूं, वह हमारे संगठन के लिए अच्छा नहीं होगा। अभी, चीजें बहुत गंभीर हैं। यहाँ है कि यह कैसे है;

हम एक बहुत छोटी टीम हैं - दो डेवलपर्स, एक डीबीए, एक डिजाइनर। जिस कंपनी के लिए मैं काम करता हूं, वह अपने आकार के सापेक्ष काफी बड़ी रकम कमाती है, और इसका लगभग 95% शुद्ध ऑनलाइन बिक्री है।

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

मुझे पूरा यकीन है कि चंचल हमारे लिए नहीं है। अब, यह देखते हुए कि (और मैंने कोशिश की है) यह कंपनी अपने तरीके नहीं बदलेगी , और केवल देव टीम को बदलने के लिए तैयार है, क्या कोई विकास पद्धति है जिसे हम अपना सकते हैं जो सिर्फ कुछ विवेक को बचाने के लिए एक अच्छा फिट है?


आप मेरे एक पुराने कार्यस्थल का इतना सटीक वर्णन कर रहे हैं कि यह असुविधाजनक है।
जॉन एन

2
पहला वाक्य दिलबर्ट पट्टी को ध्यान में लाता है। :)
मेटलमेस्टर

@MetalMikester - मुझे लगता है कि मौवे में सबसे अधिक रैम है। उस लाइन को पढ़ने के बारे में भी मेरा यही विचार था।
jfrankcarr

1
दुर्भाग्य से, मैं इनमें से कुछ छोटी-छोटी "सुविधाओं" से परिचित हूँ। मुझे लगता है कि उन्होंने "तेज" के लिए "एजाइल" को गलत समझा।
मिस्टर स्मिथ

1
@jfrankcarr का मेरा अर्थ था कि ये दो: dilbert.com/strips/comic/2007-11-26 और dilbert.com/strips/comic/2005-11-16 (सोचा कि
मौवे जैसी

जवाबों:


10

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

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

क्या mangement और बिक्री एहसास होना चाहिए कि चुस्त है विकास दल से अधिक सख्त नियंत्रण करने के लिए एक रास्ता नहीं है, यह टीम में सहायता करते हुए व्यापार वास्तविक पर विचार पर क्या वे अच्छा करने के लिए अधिक स्वायत्तता देता है सब जब भी करने के लिए काम बताए अपनी प्राथमिकताओं दल।


1
"यदि प्रबंधन ने वास्तव में खरीदा है और प्रक्रिया को विकृत नहीं करेगा" <- किसी भी अंतिम सफलता के लिए एक महत्वपूर्ण बिंदु है। काश उस वास्तविकता को बनाने के लिए कुछ जादुई मंत्र होता। यह कुछ ऐसा देखने के लिए बदबू आ रही है जो अच्छी होने लगती है बुरी तरह से मुड़ जाती है।
anon

मुझे लगता है कि यह आपके उत्तर के साथ अच्छी तरह से चला जाता है ... joelonsoftware.com/articles/DevelopmentAbstraction.html
जो इंटरनेट

आपके तर्क प्रेरक हैं, लेकिन दुख की बात है कि मुझे लगता है कि मूल पोस्टर की कंपनी में प्रबंधन चांदी की गोली की तलाश में है। मुझे यकीन नहीं है कि वे चुस्त समर्थन करेंगे जब एहसास होगा कि वे विकास प्रक्रिया के पहलुओं पर कुछ नियंत्रण खो सकते हैं। शायद क्या होगा, वहाँ चुस्त होंठ का एक बहुत चुस्त करने के लिए भुगतान किया जाता है, कुछ चीजों को पुनर्व्यवस्थित किया जाता है, और फिर अंततः चीजें बहुत अधिक जारी रहती हैं जैसे वे पहले थीं।
एंटोनियो २०१ ए ०

10

मैं कहूंगा कि आपके प्रबंधन का लाभ उठाएं! लगता है कि वे आपको एक एहसान कर रहे हैं और आपको अपने काम करने के तरीकों में सुधार करने के लिए कुछ लाभ दे रहे हैं।

उनसे कहना ठीक है कि हम अन्य चीजों के बीच चुस्त रहेंगे।

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

यदि वे इसे स्वीकार नहीं करते हैं, तो उन्हें बताएं कि आप चुस्त नहीं हो सकते।


वे उत्कृष्ट सुझाव हैं, लेकिन उन्हें एक संस्कृति परिवर्तन की आवश्यकता होती है और संस्कृति परिवर्तन बस तब नहीं होता है जब पैसा और आसान होता है।
मेपल_शफ्ट

1
हां, लेकिन बिंदु यह है कि प्रबंधन ने उन्हें एक उद्घाटन दिया है! वे फुर्तीली विधियों के लिए कहते हैं टीम को एक ध्वनि प्रस्ताव के साथ वापस आना चाहिए जो कि चुस्त प्रक्रियाओं की उच्च संरचित प्रकृति पर जोर देता है।
जेम्स एंडरसन

8

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

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

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


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

और ऊपर से शुरू होने वाले एजाइल का एक उदाहरण वास्तव में उस विधि को चुनना होगा जिसमें वे उपयोग करना चाहते हैं!
स्नोरबकल

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

5

कोई सॉफ्टवेयर विकास और परियोजना प्रबंधन कार्यप्रणाली एक ऐसे संगठन में मदद नहीं कर सकती है जहां बिक्री के लोग दिन के समय निर्धारित करते हैं। इस तरह की अराजक और व्याकुलता वाले काम के सप्ताह के बीच आपको एक परियोजना का प्रबंधन कैसे करना चाहिए?

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

क्या संस्कृति में यह बदलाव संभव है? हां, लेकिन आपके मामले में लगभग निश्चित रूप से नहीं।

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

पैसा आसान होने पर कंपनियां कभी भी भीतर से नहीं बदलती हैं। वे क्यों चाहिए, वे सॉफ्टवेयर विकास विफलताओं के बावजूद सफल हैं, सॉफ्टवेयर विकास सफलताओं के कारण नहीं।

मेरी अंतिम सलाह है कि अगर मैं तुम होते तो मैं कुछ बेहतर खोजता। यहां के लोगों ने बहुत सलाह दी है, लेकिन मैंने इस गीत और नृत्य को पहले देखा है और यह आपकी स्थिति में काम नहीं करता है।


2
मेपल_शफ्ट सही है: भागो! अभी!
लैंडेई

योग्य, मुझे डर है कि वह सही हो सकता है :)
मिकी होगर्थ

1

extremeprogramming.org पर देखें - XP आसानी से समझ में आने वाले पहलुओं के साथ एजाइल का एक रूप है जिसे आप चुन सकते हैं और एक ला कार्ट चुन सकते हैं; शुरू करने के लिए एक बहुत अच्छी जगह है

ग्राहक की प्रतिबद्धता एक हस्तक्षेप के दौरान अपने मन को बदलने के लिए नहीं है, यह आपके वातावरण के लिए एक अच्छी शुरुआत होगी ;;


IMHO उनकी सबसे बड़ी संकट आवश्यकताओं को संभालने के तरीके से संबंधित है और कार्यों का अनुमान है, अर्थात परियोजना प्रबंधन। XP उस तरफ बहुत मजबूत नहीं है, और इसमें बहुत सी चीजें (जैसे जोड़ी प्रोग्रामिंग) शामिल हैं जो स्वीकार किए जाने के लिए अधिक कठिन हो सकती हैं, और सीधे उनकी समस्याओं को हल करने में मदद नहीं करती हैं। इसलिए उदाहरण के लिए स्क्रम शुरुआत के लिए एक बेहतर विकल्प हो सकता है। बेशक, एक्सपी और स्क्रैम अच्छी तरह से मिश्रण करते हैं, लेकिन एक्सपी को केवल बाद के चरण में माना जाना चाहिए।
Péter Török

मुझे नहीं लगता कि किसी नए व्यक्ति के लिए एक ला कार्ट को चुनने और चुनने के लिए चुस्त होना बहुत अच्छा विचार है। XP काम करता है क्योंकि अभ्यास एक साथ वांछनीय व्यवहार को प्रोत्साहित करते हैं और बढ़ावा देते हैं। सर्वोत्तम परिणामों के लिए, टेलरिंग केवल तभी की जानी चाहिए जब टीम के पास थोड़ा और अनुभव हो।
माइकल

@Michael: कुछ वातावरणों में, आप धीरे धीरे मेंढक उबालने के लिए ;-) है
स्टीवन ए लोव

@ StevenA.Lowe: यह सच है - लेकिन खरीदार समय से पहले सिलाई से सावधान रहें। यहाँ "स्क्रम-लेकिन" जैसे शब्द आते हैं, जैसे कि, "हाँ, हम स्क्रम कर रहे हैं, लेकिन हम [यहाँ अभ्यास नहीं करते हैं]" जो अगर आपको पता नहीं है तो गंभीर समस्याएँ पैदा होती हैं। कर रहे हैं।
माइकल

1

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

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

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

फिर भी, चुस्त की योग्यता यह है कि यह सुव्यवस्थित प्रक्रियाओं को प्रोत्साहित करती है और निष्पादन योग्य कोड पर ध्यान केंद्रित करती है - जो अनिवार्य रूप से आपका अंतिम वितरण है।

अब, सीधे आपके प्रश्न का उत्तर देने के लिए:

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

  • उपयोगकर्ता से अनुरोध प्राप्त करें;

  • उपयोगकर्ता के अनुरोधों को प्राथमिकता दें;

  • मौजूदा प्रणाली पर वृद्धि का प्रभाव (शायद आपके दैनिक / साप्ताहिक स्टैंड-अप मीटिंग के दौरान);

  • प्रत्येक एन्हांसमेंट के विकास के समय का अनुमान लगाएं - और विभिन्न अनुरोध करने वाले उपयोगकर्ताओं को इन वापस संचारित करें;

  • मौजूदा प्रणाली (यानी कोडिंग) पर वास्तविक वृद्धि (ओं) का प्रदर्शन करें।

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

यह कुछ संरचना (और आदेश) प्रदान करना चाहिए, साथ ही एक चुस्त दृष्टिकोण के कुछ झलक को बनाए रखना चाहिए।

उपरोक्त के साथ, याद रखें कि भाषण का पुराना अंग्रेजी आंकड़ा, "एज एज़ाइल ए मंकी", बिना कारण के गढ़ा नहीं गया था!


0

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

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

एक गुप्त नोट पर भी अगर वे तकनीकी परामर्श के बिना अनुमान के साथ आपके पास आते हैं, तो बस उन्हें रिक्त बिंदु से मना करें।


1
मैं सहमत हूं कि एजाइल उनके संकटों का संभावित समाधान है, हालांकि, ए) इसे निश्चित रूप से समझ, मजबूत प्रतिबद्धता और प्रबंधन से समर्थन की आवश्यकता है, बी) धक्का और इनकार केवल प्रतिकूल प्रतिक्रियाएं पैदा करता है जो समाधान के अवसर को कम करता है (और संयोगवश वृद्धि हो सकती है) मौका निकाल दिया गया :-()
Péter Török

0

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

बेशक, आपको यूनिट / सिस्टम / प्रतिगमन परीक्षण, स्वचालित बिल्ड, डॉगफूडिंग आदि में निवेश करने की आवश्यकता है, अगर आप पहले से ही वहां नहीं हैं।


0

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

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

सबसे बड़ी बाधा पैसा एक है। यदि सब कुछ हरी ग्रेवी है, तो यह कहना बहुत मुश्किल है कि कुछ गलत है और इसे बदलने की आवश्यकता है।

शुभकामनाएँ।


0

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

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

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

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

मैं निम्नलिखित को पढ़ने के लिए बहुत कम से कम सिफारिश करूंगा:

और अतिरिक्त क्रेडिट के लिए (क्योंकि मुझे लगता है कि यह मेरे द्वारा उल्लिखित अन्य पुस्तकों के लिए एक महान साथी है):

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.