तीव्र विकास

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

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

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

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

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

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

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

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