एक फुर्तीली परियोजना में स्थानीय अनुकूलन से बचें

Question

मैं फुर्तीली विकास के प्रति बहुत सकारात्मक हूं, और लगभग 13 वर्षों तक चुस्त परियोजनाओं पर काम कर रहा हूं। लेकिन मुझे चिंता है कि मैं वास्तव में कभी भी संबोधित करने में सक्षम नहीं हूं। यह हमेशा प्रकट नहीं होता है, लेकिन यह मुझे कुछ बार काट दिया है।

Agile कुछ अर्थ में 'लालची एल्गोरिदम' लगता है। उच्चतम मूल्य कहानी से शुरू करें, उस कहानी को ठीक से पूरा करने के लिए सिस्टम को अनुकूलित करें, और दोहराएं।

वास्तविक लालची एल्गोरिदम एक वैश्विक रूप से इष्टतम समाधान खोने के दौरान, स्थानीय रूप से इष्टतम समाधानों में परिवर्तित होने से पीड़ित होने के लिए प्रवण होते हैं।

क्या यह लोगों का अनुभव रहा है?

क्या यह वास्तव में एक समस्या है?

यदि हां, तो आप इस तरह के स्थानीय ऑप्टिमा से बचने के लिए किस तकनीक का उपयोग करते हैं और फिर भी चुस्त रहते हैं?

Answer 1

वास्तविक लालची एल्गोरिदम स्थानीय रूप से इष्टतम समाधान करने के लिए converging से पीड़ित है, जबकि एक विश्व स्तर पर इष्टतम समाधान लापता से ग्रस्त हैं।

यह सच है यदि ईपीआईसी तकनीकी उपयोगकर्ता स्टोरी और दिशानिर्देश सामान्य व्यापार ईपीआईसी उपयोगकर्ता की कहानी के साथ स्थापित नहीं है।

क्या यह लोगों का अनुभव रहा है?

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

क्या यह वास्तव में एक समस्या है?

यह केवल एक समस्या है, यदि आप तकनीकी ईपीआईसी उपयोगकर्ता की कहानी या दिशानिर्देश को अनदेखा करते हैं।

यदि ऐसा है, तो आप इस तरह के स्थानीय ऑप्टिमा से बचने के लिए किस तकनीक का उपयोग करते हैं और फिर भी चुस्त रहते हैं? सिर्फ एक व्यापार महाकाव्य उपयोगकर्ता कहानी के साथ आ के बजाय, चंचल रिलीज योजना के दौरान, यह भी एक तकनीकी महाकाव्य उपयोगकर्ता कहानी के साथ आते हैं:

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

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

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

Answer 2

मैं एक ऐसी परियोजना पर रहा हूं जिसकी समस्या है, और इसका प्रभावी ढंग से निपटारा नहीं हुआ है।

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

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

हम सभी समस्याओं के प्रति सचेत थे, हमारे पास हमारी प्रक्रिया में कुछ भी नहीं था जो हमें उन्हें ठीक करने देता है।

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

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

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

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

Answer 3

मेरे प्रयोगशाला में, यदि आप निश्चित समय/आवश्यकताओं के साथ एक परियोजना संदर्भ काम कर रहे हैं तो हाँ, ज्यादातर बार Agile स्थानीय ऑप्टिमा की ओर जाता है।

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