मुझे लगता है कि यह सच है, कुछ वातावरण में एजाइल का उपयोग बिना किसी अनुशासन के बहाने के रूप में किया जाता है। असली समस्या यह है कि हम दृष्टि खो चुके हैं कि हमारे पास कोई पद्धति क्यों है। व्यक्तिगत रूप से, मुझे लगता है कि कार्यप्रणाली इस अर्थ में एक वास्तुशिल्प मुद्दा है कि प्रणाली की वास्तुकला गैर-कार्यात्मक, गुणवत्ता विशेषताओं को संबोधित करने के लिए है, कार्यप्रणाली को उन्हीं विशेषताओं में से कुछ को संबोधित किया जाना चाहिए (रखरखाव, विकास उत्पादकता, ज्ञान हस्तांतरण,) और अन्य।)
प्रक्रिया विशेषताओं के नियंत्रण के रूप में कार्यप्रणाली को देखने से कुछ बातों का पता चलता है: 1) मेट्रिक्स के बिना हम एक कार्यप्रणाली की प्रभावशीलता की तुलना दूसरे से नहीं कर सकते हैं, 2) जो महत्वपूर्ण हैं उनके बारे में एक सक्रिय निर्णय लेने की जरूरत है कि क्या विशेषताएं महत्वपूर्ण हैं (वितरण समय बनाम कोड गुणवत्ता बनाम ज्ञान हस्तांतरण)।
मेट्रिक्स और एक मूर्त दोनों लक्ष्य होने के बिना, हम बस अपने "जादू के पंख" के रूप में एक पद्धति का चयन करते हैं कि यदि हम तंग करते हैं, तो हम सॉफ़्टवेयर वितरित करने में सक्षम होंगे।
अब एजाइल, एक्सपी, स्क्रैम, आदि के नाय-कहने वाले उस विशेष श्रेणी की कार्यप्रणाली की नाजुकता के बारे में बात करते हैं। तर्क दिया जा रहा है: सभी नियमों का पालन करने के लिए अनुशासन की कमी वाले व्यक्ति को एक पद्धति का उपयोग क्यों किया जा सकता है? प्रश्न एक वैध है; हालाँकि, यह लक्षण है, कारण नहीं। यदि प्रक्रिया मैट्रिक्स का एक सटीक और अर्थपूर्ण (वह कठिन हिस्सा है) निर्धारित किया जाता है, परीक्षण किया जाता है, और समय पर प्रतिक्रिया दी जाती है, तो मुझे लगता है कि हम खोज लेंगे कि विशेष पद्धति सफलता के साथ बहुत कम है। (विशेष रूप से बोलते हुए मैंने सफल परियोजनाओं को मेथडोलॉजी के उपयोग से देखा है और दो बार समान कार्यप्रणाली का उपयोग करते हुए विफल)
तो मेट्रिक्स क्या हैं? वे प्रोजेक्ट से प्रोजेक्ट, टीम से टीम और समय-समय पर बदलते रहते हैं। जब डिलीवरी शेड्यूल महत्वपूर्ण होता है, तो उपयोगी है कि एक जो मैंने व्यक्तिगत रूप से उपयोग किया है, वह अनुमान कौशल और गुणवत्ता है। अधिकांश डेवलपर्स उन कार्यों का सटीक अनुमान लगा सकते हैं जो एक सप्ताह लंबे या कम हैं। इसलिए एक दृष्टिकोण परियोजना को एक डेवलपर-सप्ताह लंबे और ट्रैक ट्रैक में विभाजित करना है जिसने अनुमान लगाया था। जैसे-जैसे यह परियोजना आगे बढ़ेगी, वे अपने अनुमान बदल सकते हैं। एक कार्य पूरा होने के बाद, यदि 10% से अधिक (1/2 दिन में) हम इसे बग के समान मानते हैं - हम पहचानते हैं कि अनुमान क्यों बंद था (यानी एक डेटाबेस तालिका पर विचार नहीं किया गया था), पहचानें सुधारात्मक कार्रवाई (यानी अनुमान में डीबीए को शामिल करें), और फिर आगे बढ़ें। इस जानकारी का उपयोग करके हम प्रति सप्ताह # अनुमान कीड़ों के #, # डेवलपर के बग के #, जैसे मैट्रिक्स बना सकते हैं,
तो क्या? जब कार्यप्रणाली आती है - यदि आपके पास एक पूर्वानुमानित मॉडल है जो प्रक्रिया गुणों को पूरा करने में विफल रहता है, तो आप कार्यप्रणाली के कुछ पहलू को जोड़ने या हटाने का विकल्प चुन सकते हैं और देख सकते हैं कि यह आपके मॉडल को कैसे प्रभावित करता है। दी, कोई भी विफलता की आशंका के लिए एक विकास प्रक्रिया के साथ खेलना नहीं चाहता है, लेकिन हम पहले से ही लगातार उच्च और अनुमानित दर पर विफल हो रहे हैं। व्यक्तिगत परिवर्तन करने और परिणाम को मापने से आप पा सकते हैं कि एजाइल आपकी टीम के लिए एकदम सही कार्यप्रणाली है, लेकिन आप आदर्श रूप से आसानी से RUP, झरना, या सर्वोत्तम अभ्यासों का एक शौक-पासा पा सकते हैं।
इसलिए मेरा सुझाव यह है कि हम इस प्रक्रिया के बारे में चिंता करना बंद कर दें, हम उस प्रक्रिया की जाँच करते हैं जो हमारे विकास प्रक्रिया के लक्ष्यों के लिए प्रासंगिक है, और उस प्रक्रिया को बेहतर बनाने के लिए विभिन्न तकनीकों के साथ प्रयोग करते हैं।
