Visual Paradigm Desktop | 
Visual Paradigm Online
एजाइल पद्धति लचीलापन, प्रतिक्रियाशीलता और निरंतर सुधार की गारंटी देती है। हालांकि, वास्तविकता में अक्सर विफलताएं शामिल होती हैं। एक विफल स्प्रिंट एक असामान्य घटना नहीं है; यह एक डेटा बिंदु है। एक टीम के विफलता के माध्यम से गुजरने के तरीके को समझना, पूर्ण चक्रों के उत्सव की तुलना में लंबे समय तक सफलता को निर्धारित करता है।
यह लेख एक विशिष्ट परिदृश्य का अध्ययन करता है जहां एक विकास टीम पूरी तरह से अपने स्प्रिंट लक्ष्यों को प्राप्त नहीं कर पाई। हम शामिल तकनीकी और मानवीय कारकों, समस्या के निदान के लिए उपयोग किए गए रिट्रोस्पेक्टिव प्रक्रिया और गति और गुणवत्ता को वापस लाने के लिए उठाए गए ठोस कदमों का अध्ययन करेंगे।
विफलता को समझने के लिए, हमें पहले संरचना को समझना होगा। संगठन एक अंतर-कार्यक्षेत्रीय टीम मॉडल के साथ काम करता है। समूह में पांच विकासकर्मी, एक उत्पाद मालिक और एक समर्पित परीक्षक शामिल हैं। कार्य को दो सप्ताह के चक्करों में व्यवस्थित किया जाता है।
टीम ने प्रवाह को प्रबंधित करने के लिए एक भौतिक और डिजिटल ट्रैकिंग बोर्ड का उपयोग किया। कहानियों को बैकलॉग से प्रगति में और अंततः पूरा। लक्ष्य मूल्य के निरंतर वितरण करना था बिना कोड गुणवत्ता को कमजोर किए।
स्प्रिंट 42 के उच्च गति से शुरू हुआ। टीम ने बैकलॉग से 30 कहानी बिंदु निकाले। तीसरे दिन तक गति स्थिर लग रही थी। पांचवें दिन तक घर्षण दिखने लगा। दसवें दिन टीम को एहसास हुआ कि वे निर्धारित कार्य पूरा नहीं कर पाएंगे।
विफलता एक एकल विनाशकारी घटना के कारण नहीं थी। यह क्षमता को कम करने वाली एक बढ़ती श्रृंखला थी।
संख्याएँ भावनाओं की तुलना में स्पष्ट कहानी बताती हैं। निम्नलिखित तालिका योजित प्रयास और वास्तविक डिलीवरी के बीच अंतर को दर्शाती है।
| श्रेणी | योजित | वास्तविक | विचलन |
|---|---|---|---|
| पूरे किए गए कहानी अंक | 30 | 12 | -18 |
| खोजे गए बग (स्प्रिंट के दौरान) | 2 | 14 | +12 |
| हैंडल किए गए सपोर्ट टिकट | 0 | 3 | +3 |
| बाहरी निर्भरता में परिवर्तन | 0 | 1 | +1 |
यह डेटा संसाधनों के महत्वपूर्ण विचलन को उजागर करता है। जो विकास कार्य के रूप में शुरू हुआ, वह रखरखाव और संकट प्रबंधन में बदल गया।
व्यक्तियों को दोष देने से प्रणालीगत समस्याओं का समाधान नहीं होता है। टीम ने निर्दोष मूल कारण विश्लेषण किया ताकि मूल समस्याओं को पहचाना जा सके।
गहराई में जाने के लिए, टीम ने 5 कारण लक्ष्य तिथि के निर्धारण में विफलता के मुद्दे पर तकनीक का उपयोग किया।
मूल समस्या योजना सटीकता नहीं थी; यह स्थायी इंजीनियरिंग प्रथाओं के बारे में थी।
एक प्रतिस्मरण एजाइल सुधार का इंजन है। हालांकि, एक विफल स्प्रिंट के लिए एक विशिष्ट प्रकार का प्रतिस्मरण आवश्यक है। मानक प्रारूप अक्सर एक चेकबॉक्स अभ्यास की तरह लगते हैं। इस सत्र के लिए मनोवैज्ञानिक सुरक्षा और गहन जांच की आवश्यकता थी।
मीटिंग से पहले, प्रोडक्ट ओनर ने डेटा एकत्र किया। टीम से यह कहा गया कि वे अपने आप में यह विचार करें कि क्या अच्छा चला और क्या नहीं चला। इससे यह सुनिश्चित हुआ कि शांत सदस्यों को विचार विकसित करने के लिए समय मिला।
टीम ने अवधारणा के बारे में चर्चा की क्षमता योजना। उन्हें एहसास हुआ कि वे नए फीचर्स के लिए अपने समय का 100% प्रतिबद्ध कर चुके थे। लाइव वातावरण में होने वाले अपरिहार्य बाधाओं के लिए कोई ढील नहीं थी।
उन्होंने उसके बारे में भी चर्चा की काम पूरा होने की परिभाषा। वर्तमान में, “पूरा” का अर्थ था “कोड लिखा गया।” इसमें “कोड की समीक्षा” या “परीक्षण लिखे गए” शामिल नहीं थे। इस अंतर के कारण स्प्रिंट के अंत में एक बाधा उत्पन्न हुई।
समस्या को जानना केवल लड़ाई का आधा हिस्सा है। पुनर्स्थापना योजना में प्रवाह, अपेक्षाओं और तकनीकी मानकों में परिवर्तन की आवश्यकता थी।
टीम ने अपने उपलब्ध घंटों के 100% के प्रतिबद्ध होने की प्रथा बंद कर दी। उन्होंने अपनाया बफर रणनीति.
इस परिवर्तन ने आदर्श संख्या देने के दबाव को कम कर दिया और बाधाओं के वास्तविक प्रबंधन की अनुमति दी।
टीम ने अपने DoD चेकलिस्ट. एक कहानी को आगे नहीं बढ़ाया जा सकता था पूराइन मानदंडों को पूरा किए बिना:
इसने तकनीकी देनदारी के चुपचाप बढ़ने से रोका। यह सुनिश्चित करने में मदद की कि जो डिलीवर किया गया वह वास्तव में उपयोगी था।
बाहरी विक्रेताओं के साथ संचार चैनलों को औपचारिक बनाया गया। अब टीम को आवश्यकता है:
टीम ने हर तिमाही में एक स्प्रिंट को विशेष रूप से तकनीकी देनदारी कम करने के लिए समर्पित करने के लिए सहमति जताई। यह बुरे कोड के चक्रीय ब्याज प्रभाव को रोकता है। यह स्टेकहोल्डर्स को संकेत देता है कि स्थिरता एक विशेषता है, एक बाद में विचार नहीं।
परिवर्तनों को स्प्रिंट 43 में तुरंत लागू किया गया। रिकवरी तुरंत नहीं हुई, लेकिन दिशा बदल गई।
टीम ने पुराने 30 अंक के वेग पर वापस आने का लक्ष्य नहीं रखा। उनका लक्ष्य था पूर्वानुमान। कम प्रतिबद्धता करना और निरंतर डिलीवर करना अधिक प्रतिबद्धता करने और विफल होने से बेहतर है।
रिकवरी को सुनिश्चित करने के लिए, टीम ने अगले तीन महीनों तक विशिष्ट मापदंडों को ट्रैक किया।
| हफ्ता | स्प्रिंट लक्ष्य पूरा | बग काउंट | टीम का मानसिक स्तर (1-5) |
|---|---|---|---|
| महीना 1 | हाँ | 12 | 3 |
| महीना 2 | हाँ | 8 | 4 |
| महीना 3 | हाँ | 5 | 5 |
डेटा दर्शाता है कि प्रक्रिया में बदलाव और टीम के स्वास्थ्य के बीच स्पष्ट संबंध है। कम बग ने कम तनाव का कारण बनाया, जिससे मानसिक स्तर में सुधार हुआ।
असफलता एक शिक्षक है। इस केस स्टडी से सीखे गए पाठ जो किसी भी एजाइल परिवेश में लागू होते हैं, वे यहाँ दिए गए हैं।
स्थिरता के बिना गति एक भ्रम है। टीमों को कच्चे निर्गम की तुलना में निरंतर डिलीवरी को प्राथमिकता देनी चाहिए। स्टेकहोल्डर्स उन टीमों पर भरोसा करते हैं जो अपने वादों को पूरा करती हैं, भले ही वे वादे छोटे हों।
हमेशा अप्रत्याशित के लिए योजना बनाएं। यदि आपके पास 100 घंटे उपलब्ध हैं, तो 70 घंटे के काम की योजना बनाएं। शेष समय सॉफ्टवेयर विकास के अनिवार्य घर्षण को सोख लेगा।
DoD एक सुझाव नहीं है। यह टीम और प्रोडक्ट ओनर के बीच एक अनुबंध है। यदि कोई कहानी DoD को पूरा नहीं करती है, तो वह रिलीज के लिए तैयार नहीं है।
जब कुछ गलत होता है, तो टीम को बोलने के लिए सुरक्षित महसूस करना चाहिए। यदि सदस्यों को दंड के डर हैं, तो वे समस्याओं को छिपाएंगे जब तक वे संकट नहीं बन जाती हैं।
सॉफ्टवेयर एक निर्जीव वातावरण में नहीं होता है। तीसरे पक्ष की सेवाओं पर निर्भरता को आंतरिक कोड के समान दक्षता के साथ प्रबंधित किया जाना चाहिए।
बहुत से टीमें असफलता को अधिक मेहनत करके ठीक करने की कोशिश करती हैं। यह एक आम गलती है। निम्नलिखित कार्रवाइयों को रिकवरी अवधि के दौरान बचना चाहिए।
एजाइल का लक्ष्य केवल कोड डिलीवर करना नहीं है, बल्कि एक ऐसी प्रणाली बनाना है जो अनंत काल तक कोड डिलीवर कर सके। स्थायी गति इस प्रणाली की नींव है।
रिकवरी के बाद, टीम ने एक स्थापित कियानिरंतर सुधार की गति। हर दो हफ्ते में, वे स्प्रिंट के अलावा वर्कफ्लो के स्वास्थ्य की भी समीक्षा करते हैं। वे ऐसे सवाल पूछते हैं:
इस निरंतर जांच से छोटी समस्याओं को बड़ी असफलताओं में बदलने से रोका जाता है।
स्टेकहोल्डर्स के साथ पारदर्शिता निर्णायक है। जब कोई स्प्रिंट असफल होता है, तो जल्दी से संचार करें। प्रभाव, कारण और योजना की व्याख्या करें। इससे विश्वास बनता है।
स्टेकहोल्डर्स अक्सर असफल स्प्रिंट को अक्षमता के रूप में देखते हैं। जब इसे सुधार के लिए एक डेटा बिंदु के रूप में समझाया जाता है, तो यह पेशेवर परिपक्वता का प्रदर्शन बन जाता है। वे एक ऐसी टीम को पसंद करते हैं जो समस्या को मानती है और उसे ठीक करती है, बजाय इसके कि समस्या को छिपाने वाली टीम को।
असफलताएं सामान्य हैं। क्षेत्र के अनुसार 10% असफलता दर अक्सर स्वीकार्य होती है। निरंतर उच्च असफलता दरें प्रणालीगत योजना में समस्या का संकेत देती हैं।
आमतौर पर नहीं। स्प्रिंट रोकना पहले बर्बाद किए गए समय को बर्बाद कर देता है। बेहतर है कि जो कुछ भी पूरा किया जा सकता है, उसे पूरा करें और अगले चक्र के लिए रीसेट करें।
हाँ, यदि आपकी वेलोसिटी ओवरकमिटमेंट के कारण कृत्रिम रूप से बढ़ी हुई है। इसे वास्तविकता के अनुरूप कम करने से सटीकता और पूर्वानुमान में सुधार होता है।
स्थायी समाधान संभव हैं, लेकिन लंबे समय तक ठीक करने के लिए प्रक्रिया में बदलाव की आवश्यकता होती है। वरना, विफलता दोहराई जाएगी।
एजाइल अनुकूलन की यात्रा है। एक विफल स्प्रिंट रास्ते का अंत नहीं है; यह बेहतर अभ्यास की ओर इशारा करता है। विफलता का गहन विश्लेषण करने और संरचनात्मक बदलाव लागू करने से टीमें मजबूत और अधिक लचीली बन सकती हैं।