स्क्रम क्यों: परिभाषित प्रक्रिया बनाम आधारभूत प्रक्रिया

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

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

परिभाषित प्रक्रिया — एक पारंपरिक योजना-आधारित दृष्टिकोण

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

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

आधारभूत प्रक्रिया — एजिल वैल्यू-ड्राइवन दृष्टिकोण

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

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

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

सॉफ्टवेयर प्रोजेक्ट्स की विफलता दर

2015 काCHAOS रिपोर्टहाल ही में जारी की गई हैस्टैंडिश समूह। CHAOS रिपोर्ट्स 1994 से हर वर्ष प्रकाशित की जाती हैं और सॉफ्टवेयर विकास उद्योग की स्थिति का एक स्नैपशॉट प्रदान करती हैं। इस वर्ष रिपोर्ट दुनिया भर के 50,000 प्रोजेक्ट्स का अध्ययन करती है, जो छोटे सुधारों से लेकर विशाल प्रणाली पुनर्डिजाइन अनुप्रयोगों तक फैली हुई हैं। इस वर्ष रिपोर्ट में सफलता की एक बेहतर परिभाषा शामिल है, जिसमें पिछले सर्वेक्षणों में शामिल कुछ अतिरिक्त कारकों को भी शामिल किया गया है।

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

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

पारंपरिक दृष्टिकोण की समस्या क्या है?

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

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

परिभाषित प्रक्रिया बनाम आधारभूत प्रक्रिया

तालिका पढ़ने के बाद, यह आसानी से स्पष्ट हो जाता है कि सॉफ्टवेयर विकास निश्चित रूप से एक आधारभूत प्रक्रिया है, एक परिभाषित प्रक्रिया नहीं। समस्या यह है कि हम वर्षों से सॉफ्टवेयर विकास को एक परिभाषित प्रक्रिया के रूप में देख रहे हैं — और यह दृष्टिकोण काम नहीं करता है।

संदर्भ

स्टैंडिश समूह 2015 चॉस रिपोर्ट
एक अपूर्ण दुनिया में एजिल बनना — ग्रेग स्मिथ और अहमद सिदकी द्वारा

अन्य स्क्रम पठन

यह पोस्ट Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 और 繁體中文 में भी उपलब्ध है।