आप बहुत तेजी से बदलाव की लागतों से कैसे निपटते हैं?


11

अधिकांश आधुनिक डेवलपर्स की तरह मैं ग्राहक सहयोग और परिवर्तन का जवाब देने के लिए एजाइल रियासतों को महत्व देता हूं, लेकिन क्या होता है जब एक उत्पाद-स्वामी (या जो कोई आवश्यकताओं और प्राथमिकताओं को निर्धारित करता है) आवश्यकताओं और प्राथमिकताओं को अक्सर बदल देता है? दिन में कई बार की तरह?

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

क्या कुछ प्रकार के उत्पाद-स्वामी-हैंडलर भूमिका, गहन अध्ययन, रूपक या उद्धरण है जो मुझे व्यर्थ प्रयास की मात्रा को कम करने या कम से कम इस अराजक व्यवहार की लागतों को समझाने में मदद कर सकते हैं?


क्या आपकी टीम किसी प्रकार की चुस्त कार्यप्रणाली का अनुसरण कर रही है?
एरोन कुर्तज़हल

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

आप फुर्तीले कहते हैं, मैं कहूँगा कि चुस्त-
दुरुस्त

जवाबों:


12

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


5
+1 क्या है और इसका सही उत्तर क्या है। आप इसे कैसे कहते हैं - "एक बार एक चलना शुरू हो जाने के बाद, आप इसे बदल नहीं सकते।" 'CANNOT ’का कौन सा हिस्सा आपको समझ नहीं आ रहा है?
मटनज़

+1 का जवाब और मैट्नज़ की टिप्पणी के लिए ("'CANNOT' का क्या हिस्सा आपको समझ में नहीं आता?"): मुझे एक समान समस्या थी: तीन सप्ताह का चलना और तीसरे सप्ताह के दौरान एक सहकर्मी अत्यंत रचनात्मक और बदलना शुरू कर देता है / चीजों को इधर-उधर करना। एजाइल का मतलब बहुत अधिक लचीलापन है लेकिन इसकी कुछ निचली सीमाएँ हैं: आपके द्वारा काम की कुछ न्यूनतम इकाइयाँ तय करने के बाद आपको विचलित हुए बिना उन पर ध्यान केंद्रित करना चाहिए।
जियोर्जियो

मैं इस बात से सहमत हूं कि बैकलॉग यही है, हालाँकि, आपको आइट्रेस से आइटम्स को छोड़ने की अनुमति है, या उन्हें समान प्रयास के आइटम के लिए स्वैप भी कर सकते हैं, जब तक कि आपने अभी तक ड्रॉप / स्वैप की गई चीज़ों पर काम शुरू नहीं किया है।
जोशुआ ड्रेक

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

9

यहाँ बताया गया है कि मैं इसी तरह की समस्या से कैसे निपटता हूँ .. उन दिनों में जब हम एजाइल से पहले चुस्त थे।

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

जब आप ग्राहक को यह बताएंगे कि आप उसके कार्य पर काम नहीं कर सकते, तो आपको दुख होगा क्योंकि आप महत्वहीन कार्य X पर काम कर रहे हैं जिसमें उसकी नवीनतम अनुरोध जैसी ही प्राथमिकता है। फिर आप उसे बताते हैं कि उस प्राथमिकता स्तर पर उसके नवीनतम अनुरोध के आगे 50 तुच्छ और महत्वहीन कार्य हैं। अब असली पकड़ - ये सभी कार्य प्राथमिकता स्तर 1 (उच्चतम) पर हैं, जिनके द्वारा ... HIM ... सेट किया गया है, इसलिए वह आपको उस कार्य से नहीं रोक सकता जो आप कर रहे हैं। अब, जब आपने शायद ही कभी कॉन्फ़िगरेशन कॉन्फ़िगरेशन विकल्प पर आइसलैंडिक अनुवाद में लंबे समय तक शब्द के लिए जगह बनाने के लिए खिड़की के फ्रेम 3 पिक्सल को बाईं ओर ले जाना समाप्त कर दिया हो .....

मैंने एसडी ऑफिस का दरवाजा भी बंद कर दिया, उसे बंद कर दिया और फोन को हुक से निकाल लिया। 10AM, 12PM और 2PM तक ईमेल को नजरअंदाज कर दिया गया। लोगों ने जो सोचा और महसूस किया उसके बावजूद, दुनिया अभी भी सूरज के चारों ओर घूमती है, हमने अपना काम किया और "ग्राहकों" को सॉफ्टवेयर दिया गया जो कि पिछले समय में किसी भी समय की तुलना में तेज और बेहतर था।

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


+1 "कार्य शुरू होने के बाद कार्य प्राथमिकता को बदला नहीं जा सकता।" Agile केवल एक डेवलपर को पुनरावृत्ति से आइटम छोड़ने की अनुमति देता है जो उन्होंने काम करना शुरू नहीं किया है।
जोशुआ ड्रेक

मुझे प्राथमिकता निर्धारित करने वाले ग्राहक का विचार पसंद है, कठिन भाग कानून को गिरा रहा है और कह रहा है 'मैंने कार्य एक्स पर शुरू कर दिया है, नहीं, आप प्राथमिकता को अब नहीं बदल सकते हैं'
sevenseacat

2

एसओपी। मानक संचालन प्रक्रिया (या कम से कम एक ढीला प्रोटोकॉल जो आपकी प्रबंधन टीम द्वारा हस्ताक्षरित है)। आपके विभाग को एक विकसित करने की आवश्यकता है, या एक को विकसित करने के लिए अपनी प्रबंधन टीम के साथ काम करना है। जिन लोगों से आप बात करना चाहते हैं, वे उत्पाद-स्वामी / खाता प्रबंधक से ऊपर हैं।

आपके एसओपी को क्या परिभाषित करना चाहिए, इसके कुछ उदाहरण हैं।

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

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

अंतिम परिणाम आपको नाखुश करता है, और वह आपकी कंपनियों में सर्वोत्तम हित में नहीं है।

एक साइड नोट पर, आपको अपनी स्थिति और कर्तव्य के लिए इस तरह के असम्मानजनक अपमान के कारण किसी को विरासत में मिला हो सकता है। उस स्थिति में लोग गुणवत्ता वाले उत्पाद का उत्पादन करना मुश्किल पाते हैं। क्या यह किसी अचंभे जैसा है? सॉफ्टवेयर इंजीनियरिंग 101।


2

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

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

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

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

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

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


0

ऐसा लगता है कि किसी ने अभी तक इसका उल्लेख नहीं किया है, स्प्रिंट और इसकी उपयोगकर्ता कहानियां ideally should be locked till the next sprint(ठेठ स्प्रिंट 2-4 सप्ताह लगते हैं)। ताला लगाकर - मेरा मतलब है कि पहले से शुरू किए गए स्प्रिंट में कोई अतिरिक्त कार्य नहीं जोड़ा जाना चाहिए।

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

संपादित करें: वसंत के दौरान केवल छोटे बदलाव पेश किए जा सकते हैं। अगर वे आपातकालीन स्थिति में ले जाते हैं। हालांकि, अगर स्प्रिंट के दौरान हमेशा कुछ आपात स्थिति रहती है, तो स्प्रिंट प्लानिंग में कुछ बदलाव करने की जरूरत है।


0

Scrum में Scrum Master भूमिका है, जो वह व्यक्ति होगा जो आपके द्वारा बताए गए मुद्दों को संबोधित करेगा।

अगर टीम लीड, प्रोजेक्ट मैनेजर, स्क्रैम मास्टर, जैसे कोई है जो जिम्मेदार है, तो मैं उस व्यक्ति से बात करूंगा।

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

मुझे लगता है कि आपको बार-बार समझाते रहना होगा। ऐसा लगता है कि आपको यह स्वीकार करने की आवश्यकता हो सकती है कि आपके साथ काम करने वाले कुछ लोगों की आदतें हैं। यदि आप भाग्यशाली हैं, तो आप अंततः एक बदलाव देखेंगे।


0

एजाइल मेनिफेस्टो कहता है कि सबसे मौलिक प्राचार्यों में से एक है:

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

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

फिर से, जबकि किसी उत्पाद की बिक्री का वर्कफ़्लो प्रत्येक सप्ताह बदल सकता है, मुझे लगता है कि प्रत्येक सप्ताह समग्र उत्पाद नहीं बदला जाएगा। मैं एक ऐसे Microsoft की कल्पना नहीं कर सकता, जो आज हमें ऑफिस देता है, लेकिन कल हमें ऑफसोज देगा, और एक हफ्ते बाद ऑफसुओहुइवोस।

नहीं, यह नहीं है कि चुस्त बदलाव से क्या मतलब है। मेरा मानना ​​है कि यह गरीब दृष्टि से आता है, और परिवर्तन की अवधारणा की एक बड़ी गहरी गलतफहमी है।

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

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