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% की छूट दर अक्सर स्वीकार्य होती है। निरंतर उच्च छूट दर एक प्रणालीगत योजना समस्या का संकेत है।
आमतौर पर नहीं। स्प्रिंट रोकना पहले से बिताए गए समय को बर्बाद करता है। यह बेहतर है कि जो कुछ भी पूरा किया जा सकता है, उसे पूरा करें और अगले चक्र के लिए रीसेट करें।
हां, यदि आपकी वेलोसिटी ओवरकमिटमेंट के कारण कृत्रिम रूप से बढ़ी हुई है। इसे वास्तविकता के अनुरूप कम करने से सटीकता और पूर्वानुमान बेहतर होता है।
संक्षिप्त अवधि के निवारण संभव हैं, लेकिन दीर्घकालिक ठीक करने के लिए प्रक्रिया में बदलाव की आवश्यकता होती है। वरना, विफलता दोहराई जाएगी।
एजाइल अनुकूलन की यात्रा है। एक विफल स्प्रिंट रास्ते का अंत नहीं है; यह बेहतर अभ्यास की ओर इशारा करने वाला संकेत है। विफलता का गहन विश्लेषण करने और संरचनात्मक बदलाव लागू करने से टीमें मजबूत और अधिक लचीली बन सकती हैं।