एक्सट्रीम प्रोग्रामिंग

एक्सट्रीम प्रोग्रामिंग में योजना और पुनर्भरण लूप।

एक्सट्रीम प्रोग्रामिंग (XP) एक सॉफ्टवेयर विकास पद्धति है जिसका उद्देश्य ग्राहकों की बदलती आवश्यकताओं के प्रति सॉफ्टवेयर की गुणवत्ता और प्रतिक्रिया में सुधार करना है। एक प्रकार के एजाइल सॉफ्टवेयर विकास के रूप में,^[1]^[2]^[3]यह छोटे विकास चक्रों में प्रायः लोकार्पण की वकालत करता है, जिसका उद्देश्य उत्पादकता में सुधार करना और उन चौकियों को प्रस्तुत करना है जिन पर नए ग्राहक आवश्यकताओं को अपनाया जा सकता है।

एक्सट्रीम प्रोग्रामिंग के अन्य तत्वों में सम्मिलित हैं: प्रोग्रामिंग, युग्मों में प्रोग्रामिंग करना या व्यापक कोड समीक्षा करना, सभी कोड का एकक परीक्षण करना, प्रोग्रामिंग सुविधाओं को तब तक नहीं जब तक कि उनकी वास्तव में आवश्यकता न हो, एक स्पष्ट प्रबंधन संरचना, कोड सहजता और स्पष्टता, समय बीतने के साथ ग्राहक की आवश्यकताओं में परिवर्तनों की आशा करना और समस्या को बेहतर ढंग से समझा जाता है और ग्राहक के साथ और प्रोग्रामर के मध्य लगातार संचार होता है।^[2]^[3]^[4] इस पद्धति का नाम इस विचार से लिया गया है कि पारंपरिक सॉफ्टवेयर अभियांत्रिकी प्रथाओं के लाभकारी तत्वों को "एक्सट्रीम" स्तर तक ले जाया जाता है। उदाहरण के लिए, कोड समीक्षा को एक लाभकारी अभ्यास माना जाता है; एक्सट्रीम सीमा तक ले जाने पर, कोड की लगातार समीक्षा (अर्थात जोड़ी प्रोग्रामिंग का अभ्यास) की जा सकती है।

इतिहास

केंट बेक ने क्रिसलर व्यापक प्रतिकर प्रणाली (C3) पेरोल परियोजना पर अपने कार्य के पर्यन्त एक्सट्रीम प्रोग्रामिंग विकसित की।^[5]बेक मार्च 1996 में सी3 परियोजना प्रबंधन बने। उन्होंने परियोजना में प्रयुक्त विकास पद्धति को परिष्कृत करना प्रारंभ किया और पद्धति पर एक पुस्तक (एक्सट्रीम प्रोग्रामिंग की व्याख्या, अक्टूबर 1999 में प्रकाशित) लिखी।^[5] क्रिसलर ने सात वर्ष बाद फरवरी 2000 में सी3 परियोजना निरस्त कर दी, जब डेमलर बेंज ने उद्योग का अधिग्रहण कर लिया।^[6] वार्ड कनिंघम का एक्सपी पर एक और बड़ा प्रभाव था।

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

उत्पत्ति

1990 के दशक में दो प्रमुख प्रभावों ने सॉफ्टवेयर विकास को आकार दिया:

आंतरिक रूप से, ऑब्जेक्ट उन्मुखी प्रोग्रामिंग ने कुछ विकासक द्वारा अनुगृहीत प्रोग्रामिंग प्रतिमान के रूप में प्रक्रियात्मक प्रोग्रामिंग को प्रतिस्थापित कर दिया।
बाह्य रूप से, इंटरनेट के उदय और डॉट-कॉम बूम ने प्रतिस्पर्धी व्यावसायिक कारकों के रूप में गति-से-बाज़ार और उद्योग के विकास पर जोर दिया।

तीव्रता से बदलती आवश्यकताओं के लिए छोटे उत्पाद जीवन-चक्र की आवश्यकता होती है और प्रायः सॉफ्टवेयर विकास के पारंपरिक तरीकों से विरोध होता है।

क्रिसलर व्यापक प्रतिकर प्रणाली (C3) ऑब्जेक्ट प्रौद्योगिकियों का उपयोग करने का सबसे अच्छा तरीका निर्धारित करने के लिए प्रारंभ हुआ, क्रिसलर में पेरोल प्रणाली को अनुसंधान के उद्देश्य के रूप में, भाषा के रूप में स्मॉलटॉक और डेटा अभिगम पटल के रूप में जेमस्टोन का उपयोग किया गया। क्रिसलर ने प्रणाली पर प्रदर्शन ट्यूनिंग करने के लिए एक प्रमुख स्मॉलटॉक कलाकार केंट बेक को लाया,^[5]परन्तु उनकी भूमिका का विस्तार हुआ क्योंकि उन्होंने विकास प्रक्रिया में कई समस्याओं की व्याख्या की। उन्होंने इस अवसर का उपयोग अपने लगातार सहयोगी, वार्ड कनिंघम के साथ अपने कार्य के आधार पर, विकास प्रथाओं में कुछ परिवर्तनों को प्रस्तावित करने और अनुप्रयुक्त करने के लिए किया। बेक विधियों की प्रारंभिक अवधारणा का वर्णन करता है:^[8]

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

बेक ने इन तरीकों को विकसित करने और परिष्कृत करने में सहायता के लिए रॉन जेफ़्रीज़ को परियोजना में आमंत्रित किया। इसके बाद जेफ़्रीज़ ने सी3 समूह में प्रथाओं को व्यवहारों के रूप में विकसित करने के लिए एक प्रशिक्षक के रूप में कार्य किया।

एक्सपी के पीछे के सिद्धांतों और प्रथाओं के विषय में जानकारी मूल विकी, कनिंघम के विकिविकिवेब पर चर्चा के माध्यम से व्यापक दुनिया में प्रसारित की गई। विभिन्न योगदानकर्ताओं ने विचारों पर चर्चा की और विस्तार किया और कुछ स्पिन-ऑफ पद्धतियों का परिणाम हुआ (एजाइल सॉफ्टवेयर विकास देखें)। साथ ही, एक्सपी अवधारणाओं को लगभग 1999 में एक्सपी^{[by whom?]} वेबसाइट http://www.extremeprogramming.org पर हाइपरटेक्स्ट प्रणाली प्रतिचित्र का उपयोग करके कई वर्षों से समझाया गया है।

बेक ने एक्सपी पर किताबों की एक श्रृंखला संपादित की, जिसके प्रारंभ में उन्होंने अपने एक्सट्रीम प्रोग्रामिंग की व्याख्या (1999, आईएसबीएन 0-201-61641-6) से की और अपने विचारों को बहुत बड़े दर्शकों तक फैलाया। श्रृंखला में लेखक एक्सपी और इसकी प्रथाओं में भाग लेने वाले विभिन्न दृष्टिकोणों से गुज़रे। श्रृंखला में प्रथाओं की आलोचनात्मक पुस्तक सम्मिलित थी।

वर्तमान स्थिति

एक्सपी ने 1990 के दशक के अंत और 2000 के दशक के प्रारंभ में सॉफ्टवेयर समुदायों के मध्य महत्वपूर्ण रुचि उत्पन्न की, जिसे इसके मूल से बिल्कुल अलग वातावरण में अपनाया गया।

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

इस बीच, अन्य त्वरित-विकास प्रथाएँ स्थिर नहीं रही हैं और 2019 तक एक्सपी का विकास जारी है, अन्य प्रथाओं का उपयोग करने के लिए क्षेत्र में अनुभवों से अधिक पाठ को आत्मसात करना है। एक्सट्रीम प्रोग्रामिंग की व्याख्या (नवंबर 2004) के दूसरे संस्करण में, पहले संस्करण के पांच साल बाद, बेक ने अधिक गुणों और प्रथाओं को जोड़ा, प्राथमिक और परिणामी प्रथाओं के मध्य अंतर किया।

संकल्पना

लक्ष्य

एक्सट्रीम प्रोग्रामिंग व्याख्या एक्सट्रीम प्रोग्रामिंग को एक सॉफ्टवेयर-विकास अनुशासन के रूप में वर्णित करता है जो लोगों को उच्च गुणवत्ता वाले सॉफ़्टवेयर को अधिक उत्पादक रूप से तैयार करने के लिए संगठित करता है।

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

एक्सट्रीम प्रोग्रामिंग, तीव्र कार्यप्रणाली के शीर्ष पर कई बुनियादी गुणों, सिद्धांतों और प्रथाओं का भी परिचय देती है।

गतिविधियाँ

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

कोडिंग

एक्सपी के समर्थकों का तर्क है कि प्रणाली विकास प्रक्रिया का एकमात्र महत्वपूर्ण उत्पाद कोड-सॉफ्टवेयर निर्देश है जिसे परिकलक व्याख्या कर सकता है। कोड के बिना, कोई कार्यशील उत्पाद नहीं है।

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

परीक्षण

परीक्षण एक्सट्रीम प्रोग्रामिंग का केंद्र है।^[9] एक्सट्रीम प्रोग्रामिंग का दृष्टिकोण यह है कि यदि थोड़ा सा परीक्षण कुछ खामियों को खत्म कर सकता है, तो बहुत सारे परीक्षण कई और खामियों को खत्म कर सकते हैं।

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

प्रारंभ में, प्रणाली-व्यापी एकीकरण परीक्षण को दिन के अंत की दैनिक गतिविधि के रूप में प्रोत्साहित किया गया था, ताकि असंगत अंतरापृष्ठ का शीघ्र पता लगाया जा सके, ताकि अलग-अलग खंडों को सुसंगत कार्यक्षमता से व्यापक रूप से अलग होने से पहले फिर से जोड़ा जा सके। हालाँकि, प्रणाली में समग्र अंतरापृष्ठ की स्थिरता के आधार पर, प्रणाली-व्यापी एकीकरण परीक्षण को साप्ताहिक या उससे भी कम कर दिया गया है।^{[citation needed]}

श्रवण

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

अभिकल्पन

सरलता के दृष्टिकोण से, निश्चित रूप से कोई यह कह सकता है कि प्रणाली विकास के लिए कोडिंग, परीक्षण और श्रवण से अधिक की आवश्यकता नहीं है। यदि उन गतिविधियों को अच्छी तरह से निष्पादित किया जाता है, तो परिणाम सदैव एक ऐसी प्रणाली होनी चाहिए जो कार्य करती है। व्यवहार में, यह कार्य नहीं करेगा, कोई बिना डिज़ाइन किए बहुत आगे तक आ सकता है परन्तु एक निश्चित समय पर वह फंस जाएगा। प्रणाली बहुत जटिल हो जाती है और प्रणाली के भीतर निर्भरताएँ स्पष्ट होना बंद हो जाती हैं। प्रणाली में तर्क को व्यवस्थित करने वाली रूपांकित संरचना बनाकर इससे बचा जा सकता है। अच्छा डिज़ाइन एक प्रणाली के भीतर कई निर्भरताओं से बच जाएगा; इसका अर्थ यह है कि प्रणाली के एक भाग को परिवर्तित करने से प्रणाली के अन्य भागों पर कोई प्रभाव नहीं पड़ेगा।^{[citation needed]}

मान

एक्सट्रीम प्रोग्रामिंग ने प्रारंभ में 1999 में चार गुणों: संचार, सरलता, प्रतिक्रिया और धैर्य को मान्यता दी। एक्सट्रीम प्रोग्रामिंग की व्याख्या के दूसरे संस्करण में एक नया मान, सम्मान जोड़ा गया। उन पांच गुणों का वर्णन नीचे किया गया है।

संचार

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

सरलता

एक्सट्रीम प्रोग्रामिंग सबसे सरल समाधान से प्रारंभ करने को प्रोत्साहित करती है। अतिरिक्त कार्यक्षमता बाद में जोड़ी जा सकती है। इस दृष्टिकोण और अधिक पारंपरिक प्रणाली विकास विधियों के मध्य का अंतर कल, अगले सप्ताह या अगले महीने की बजाय आज की आवश्यकताओं के लिए डिजाइन और कोडिंग पर ध्यान केंद्रित करना है। कभी-कभी इसे आपको इसकी आवश्यकता नहीं होगी (YAGNI) दृष्टिकोण के रूप में संक्षेपित किया जाता है।^[10] एक्सपी के समर्थक इस हानि को स्वीकार करते हैं कि कभी-कभी प्रणाली को परिवर्तित करने के लिए कल अधिक प्रयास करना पड़ सकता है; उनका अनुरोध है कि इसकी अदायगी संभावित भविष्य की आवश्यकताओं में निवेश न करने के लाभ से की जाती है जो प्रासंगिक बनने से पहले बदल सकती हैं। अनिश्चित भविष्य की आवश्यकताओं के लिए कोडिंग और डिज़ाइनिंग का तात्पर्य किसी ऐसी चीज़ पर संसाधन व्यय करने का जोखिम है जिसकी आवश्यकता नहीं हो सकती है, जबकि सम्भवतः महत्वपूर्ण सुविधाओं में देरी हो रही है। संचार गुण से संबंधित, डिज़ाइन और कोडिंग में सरलता से संचार की गुणवत्ता में सुधार होना चाहिए। बहुत ही सरल कोड वाला एक सरल रूपांकित समूह के अधिकांश प्रोग्रामर द्वारा सरलता से समझा जा सकता है।

पुनर्भरण

एक्सट्रीम प्रोग्रामिंग के भीतर, पुनर्भरण प्रणाली विकास के विभिन्न आयामों से संबंधित है:

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

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

धैर्य

कई प्रथाएँ धैर्य का प्रतीक हैं। एक आज्ञा है कि सदैव आज के लिए डिज़ाइन और कोड करें, न कि कल के लिए।यह डिज़ाइन में उलझने से बचने और किसी अन्य चीज़ को अनुप्रयुक्त करने के लिए बहुत अधिक प्रयास की आवश्यकता से बचने का एक प्रयास है। धैर्य विकासक को आवश्यकता पड़ने पर अपने कोड को दोबारा तैयार करने में सहज अनुभव करने में सक्षम बनाता है।^[5]इसका अर्थ है उपस्थित प्रणाली की समीक्षा करना और उसे संशोधित करना ताकि भविष्य में होने वाले परिवर्तनों को अधिक सरलता से अनुप्रयुक्त किया जा सके। धैर्य का एक और उदाहरण यह जानना है कि कोड को कब प्रक्षेप करना है: अप्रचलित स्रोत कोड को हटाने का धैर्य, चाहे उस स्रोत कोड को बनाने के लिए कितना भी प्रयास किया गया हो। इसके अतिरिक्त, धैर्य का अर्थ है दृढ़ता: एक प्रोग्रामर पूरे दिन एक जटिल समस्या पर अटका रह सकता है, फिर अगले दिन समस्या को शीघ्रता से हल कर सकता है, परन्तु केवल तभी जब वे दृढ़ बने रहें।

सम्मान

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

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

नियम

एक्सपी के नियमों का पहला संस्करण 1999 में डॉन वेल्स^[12] द्वारा एक्सपी वेबसाइट पर प्रकाशित किया गया था। योजना, प्रबंधन, डिजाइनिंग, कोडिंग और परीक्षण की श्रेणियों में 29 नियम दिए गए हैं। उन अनुरोधों का खंडन करने के लिए योजना, प्रबंधन और डिज़ाइनिंग को स्पष्ट रूप से कहा जाता है कि एक्सपी उन गतिविधियों का समर्थन नहीं करता है।

एक्सपी नियमों का एक और संस्करण एक्सपी/एजाइल विश्व 2003 में केन एउर^[13] द्वारा प्रस्तावित किया गया था। उनका मानना था कि एक्सपी को इसके नियमों द्वारा परिभाषित किया गया था, न कि इसकी प्रथाओं (जो अधिक भिन्नता और अस्पष्टता के अधीन हैं)। उन्होंने दो श्रेणियों को परिभाषित किया: "अनुबंध के नियम" जो उस वातावरण को निर्देशित करते हैं जिसमें सॉफ्टवेयर विकास प्रभावी ढंग से हो सकता है और "खेल के नियम" जो अनुबंध के नियमों के रूपरेखा के भीतर मिनट-दर-मिनट गतिविधियों और नियमों को परिभाषित करते हैं।

यहां कुछ नियम (अपूर्ण) दिए गए हैं:

कोडन

ग्राहक सदैव उपलब्ध है,
पहले इकाई परीक्षण को कोड करें,
एक समय में केवल एक युग्म कोड को एकीकृत करता है,
अनुकूलन को आखिरी तक छोड़ दें,
कोई अतिरिक्त समय नहीं।

परिक्षण

सभी कोड में एकक परीक्षण होना चाहिए।
सभी कोड को विमोचन होने से पूर्व सभी एकक परीक्षण ज़ारी करने होंगे।
जब कोई बग पाया जाता है, तो बग को संबोधित करने से पहले परीक्षण बनाए जाते हैं (बग तर्क में कोई त्रुटि नहीं है; यह एक परीक्षण है जो लिखा नहीं गया था)।
स्वीकृति परीक्षण प्रायः चलाए जाते हैं और परिणाम प्रकाशित किए जाते हैं।

सिद्धांत

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

प्रतिपुष्टि

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

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

सरलता मानकर

यह प्रत्येक समस्या का ऐसे उपचार करने के विषय में है जैसे कि उसका समाधान अत्यंत सरल हो। पारंपरिक प्रणाली विकास विधियाँ भविष्य के लिए योजना बनाने और पुन: प्रयोज्य के लिए कोड बनाने के लिए कहती हैं। एक्सट्रीम प्रोग्रामिंग इन विचारों को निरस्त करती है।

एक्सट्रीम प्रोग्रामिंग के समर्थकों का कहना है कि एक बार में बड़े परिवर्तन करने से कार्य नहीं चलता। एक्सट्रीम प्रोग्रामिंग वृद्धिशील परिवर्तन अनुप्रयुक्त करती है: उदाहरण के लिए, एक प्रणाली में प्रत्येक तीन सप्ताह में छोटे विमोचन हो सकते हैं। जब कई छोटे कदम उठाए जाते हैं, तो ग्राहक का विकास प्रक्रिया और विकसित की जा रही प्रणाली पर अधिक नियंत्रण होता है।

परिवर्तन को अपनाना

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

अभ्यास

एक्सट्रीम प्रोग्रामिंग को 12 प्रथाओं के रूप में वर्णित किया गया है, जिन्हें चार क्षेत्रों में बांटा गया है:

बढ़िया पैमाने पर प्रतिक्रिया

युग्म प्रोग्रामिंग^[5]
योजना बनाने का खेल
परीक्षण संचालित विकास
संपूर्ण समूह

सतत प्रक्रिया

निरंतर एकीकरण
पुनर्रचना या डिज़ाइन में सुधार^[5]
छोटे विमोचन

साझा समझ

कोडिंग मानक
सामूहिक कोड स्वामित्व^[5]
सरल डिज़ाइन^[5]
प्रणाली रूपक

प्रोग्रामर कल्याण

निरंतर गति

विवादास्पद दृष्टिकोण

एक्सपी में प्रथाओं पर भारी विवाद हुआ।^[5]एक्सट्रीम प्रोग्रामिंग के समर्थकों का अनुरोध है कि साइट पर ग्राहक^[5]द्वारा अनौपचारिक रूप से परिवर्तन का अनुरोध करने से, प्रक्रिया नम्य हो जाती है और औपचारिक उपरि संक्रिया की लागत बच जाती है। एक्सपी के आलोचकों का अनुरोध है कि इससे पुनर्कार्य महंगा हो सकता है और परियोजना की सीमा पहले की सहमति या वित्त पोषित सीमा से अधिक हो सकती है।^{[citation needed]}

परिवर्तन-नियंत्रण समिति एक संकेत है कि कई उपयोगकर्ताओं के मध्य परियोजना के उद्देश्यों और बाधाओं में संभावित संघर्ष हैं। एक्सपी की त्वरित विधियाँ कुछ हद तक प्रोग्रामर पर निर्भर होती हैं जो एक एकीकृत ग्राहक दृष्टिकोण ग्रहण करने में सक्षम होते हैं ताकि प्रोग्रामर समझौता उद्देश्यों और बाधाओं के दस्तावेज़ीकरण के बजाय कोडिंग पर ध्यान केंद्रित कर सके।^[14] यह तब भी अनुप्रयुक्त होता है जब कई प्रोग्रामिंग संगठन सम्मिलित होते हैं, विशेष रूप से ऐसे संगठन जो परियोजनाओं के शेयरों के लिए प्रतिस्पर्धा करते हैं।^{[citation needed]}

एक्सट्रीम प्रोग्रामिंग के अन्य संभावित विवादास्पद दृष्टिकोणों में सम्मिलित हैं:

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

आलोचकों ने कई संभावित कमियाँ की व्याख्या हैं,^[5]जिसमें अस्थिर आवश्यकताओं वाली समस्याएं, उपयोगकर्ता संघर्षों का कोई दस्तावेजी समझौता नहीं होना और समग्र रूपांकित विनिर्देश या दस्तावेज़ की कमी सम्मिलित है।

मापनीयता

थॉटवर्क्स ने साठ लोगों तक वितरित एक्सपी परियोजनाओं पर उचित सफलता का अनुरोध किया है।^{[citation needed]}

2004 में, औद्योगिक एक्सट्रीम प्रोग्रामिंग (IXP)^[15] को एक्सपी के विकास के रूप में प्रस्तुत किया गया था। इसका उद्देश्य बड़ी और वितरित समूहों में कार्य करने की क्षमता लाना है। अब इसमें 23 प्रथाएँ और नम्य गुण हैं।

पृथक्करणीयता और प्रतिक्रियाएँ

2003 में, मैट स्टीफ़ेंस और डौग रोसेनबर्ग ने एक्सट्रीम प्रोग्रामिंग रिफैक्टर्ड: एक्सपी के विरुद्ध प्रकरण प्रकाशित किया, जिसमें एक्सपी प्रक्रिया के गुण पर प्रश्न उठाया गया और ऐसे तरीके सुझाए गए जिनसे इसे श्रेष्ठतर बनाया जा सकता है।^[6]इससे लेखों, इंटरनेट समाचार समूहों और वेब-साइट चैट क्षेत्रों में एक लम्बा विवाद प्रारंभ हुआ। पुस्तक का मुख्य तर्क यह है कि एक्सपी की प्रथाएँ अन्योन्याश्रित हैं परन्तु कुछ व्यावहारिक संगठन सभी प्रथाओं को अपनाने के इच्छुक/सक्षम हैं; इसलिए सम्पूर्ण प्रक्रिया विफल हो जाती है। पुस्तक अन्य आलोचनाएँ भी करती है और यह एक्सपी के सामूहिक स्वामित्व मॉडल की तुलना समाजवाद से नकारात्मक तरीके से करती है।

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

अन्य लेखकों ने एक एकीकृत कार्यप्रणाली बनाने के लिए एक्सपी को पुरानी पद्धतियों के साथ सामंजस्य स्थापित करने का प्रयास किया है। इनमें से कुछ एक्सपी को प्रतिस्थापित करने की मांग की गई, जैसे वॉटरफॉल पद्धति; उदाहरण: परियोजना जीवनचक्र: प्रपात, तीव्र अनुप्रयोग विकास (RAD) और वह सब है। जेपी मॉर्गन चेज़ और उद्योग ने क्षमता परिपक्वता मॉडल एकीकरण (CMMI) और सिक्स सिग्मा के परिकलक प्रोग्रामिंग तरीकों के साथ एक्सपी को संयोजित करने का प्रयास किया। उन्होंने पाया कि तीनों प्रणालियाँ एक-दूसरे को अच्छी तरह से सुदृढ़ करती हैं, जिससे उन्नत विकास होता है और परस्पर विरोधाभास नहीं होता है।^[16]

आलोचना

एक्सट्रीम प्रोग्रामिंग की प्रारंभिक चर्चा और विवादास्पद सिद्धांतों, जैसे कि युग्म प्रोग्रामिंग और सतत डिजाइन, ने विशेष आलोचनाओं को आकर्षित किया है, जैसे कि मैकब्रीन ^[17] और बोहेम और टर्नर,^[18] मैट स्टीफेंस और डौग रोसेनबर्ग से आ रही हैं।^[19] हालाँकि, कई आलोचनाओं को एजाइल अभ्यासकर्ताओं द्वारा एजाइल विकास का भ्रम माना जाता है।^[20]

विशेष रूप से, मैट स्टीफंस और डौग रोसेनबर्ग एक्सट्रीम प्रोग्रामिंग रिफैक्टर्ड द्वारा एक्सट्रीम प्रोग्रामिंग की समीक्षा और आलोचना की गई है।^[6]

यह भी देखें

संदर्भ

↑ "Human Centred Technology Workshop 2006 ", 2006, PDF, Human Centred Technology Workshop 2006
↑ ^2.0 ^2.1 UPenn-Lectures-design-patterns "Design Patterns and Refactoring", University of Pennsylvania, 2003 Archived August 2, 2010, at the Wayback Machine.
↑ ^3.0 ^3.1 USFCA-edu-601-lecture Extreme Programming.
↑ "एजाइल सॉफ्टवेयर विकास के लिए घोषणापत्र". Agilemanifesto.org. 2001. Retrieved March 26, 2019.
↑ ^5.00 ^5.01 ^5.02 ^5.03 ^5.04 ^5.05 ^5.06 ^5.07 ^5.08 ^5.09 ^5.10 ^5.11 ^5.12 Computerworld-appdev-92 "Extreme Programming", Computerworld (online), December 2001.
↑ ^6.0 ^6.1 ^6.2 Rosenberg, Doug; Stephens, Matt (2003). Extreme Programming Refactored: The Case Against XP. Apress. ISBN 978-1-59059-096-6.
↑ Larman & Basili 2003.
↑ केंट बेक और मार्टिन फाउलर के साथ साक्षात्कार. March 23, 2001. {{cite book}}: |work= ignored (help)
↑ Lisa Crispin; Tip House (2003). एक्सट्रीम प्रोग्रामिंग का परीक्षण. ISBN 9780321113559.
↑ "Everyone's a Programmer" by Clair Tristram. Technology Review, November 2003. p. 39.
↑ Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley. ISBN 978-0-321-27865-4.
↑ "चरम प्रोग्रामिंग नियम". extremeprogramming.org.
↑ Ken Auer Archived September 20, 2008, at the Wayback Machine
↑ John Carroll; David Morris (July 29, 2015). Agile Project Management in easy steps, 2nd edition. In Easy Steps. p. 162. ISBN 978-1-84078-703-0.
↑ Cutter Consortium. "Industrial XP: Making XP Work in Large Organizations - Cutter Consortium". cutter.com.
↑ Extreme Programming (XP) Six Sigma CMMI.
↑ McBreen, P. (2003). एक्सट्रीम प्रोग्रामिंग पर सवाल उठाना. Boston, MA: Addison-Wesley. ISBN 978-0-201-84457-3.
↑ Boehm, B.; R. Turner (2004). Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley. ISBN 978-0-321-18612-6.
↑ Stephens, Matt; Doug Rosenberg (2004). चरम प्रोग्रामिंग की विडंबना. MA: Dr Dobbs journal.
↑ sdmagazine Archived March 16, 2006, at the Wayback Machine

अग्रिम पठन

Ken Auer and Roy Miller. Extreme Programming Applied: Playing To Win, Addison–Wesley.
Ken Auer; Ron Jeffries; Jeff Canna; Glen B. Alleman; Lisa Crispin; Janet Gregory (2002). "Are Testers eXtinct? How Can Testers Contribute to XP Teams?". Extreme Programming and Agile Methods — XP/Agile Universe 2002. Lecture Notes in Computer Science. Vol. 2418. Springer-Verlag. p. 287. doi:10.1007/3-540-45672-4_50. ISBN 978-3-540-44024-6.
Kent Beck: Extreme Programming Explained: Embrace Change, Addison–Wesley. First edition, 1999. Second edition, with Cynthia Andres, 2004.
Kent Beck and Martin Fowler: Planning Extreme Programming, Addison–Wesley.
Alistair Cockburn: Agile Software Development, Addison–Wesley.
Martin Fowler: Refactoring: Improving the Design of Existing Code.With Kent Beck, John Brant, William Opdyke, and Don Roberts (1999). Addison-Wesley.
Harvey Herela (2005). Case Study: The Chrysler Comprehensive Compensation System. Galen Lab, U.C. Irvine.
Jim Highsmith. Agile Software Development Ecosystems, Addison–Wesley.
Ron Jeffries, Ann Anderson and Chet Hendrickson (2000), Extreme Programming Installed, Addison–Wesley.
Larman, C.; Basili, V.R. (June 2003). "Iterative and incremental developments. a brief history" (PDF). Computer. 36 (6): 47–56. doi:10.1109/MC.2003.1204375.
Matt Stephens and Doug Rosenberg (2003). Extreme Programming Refactored: The Case Against एक्सपी, Apress.
Waldner, JB. (2008). "Nanocomputers and Swarm Intelligence". In: ISTE, 225–256.

बाहरी संबंध

A gentle introduction
Industrial eXtreme Programming
Problems and Solutions to एक्सपी implementation
Using an Agile Software Process with Offshore Development – ThoughtWorks' experiences with implementing एक्सपी in large distributed projects

[Informatics85-1] "Human Centred Technology Workshop 2006 ", 2006, PDF, Human Centred Technology Workshop 2006

[UPenn49-2] 2.0 ^2.1 UPenn-Lectures-design-patterns "Design Patterns and Refactoring", University of Pennsylvania, 2003 Archived August 2, 2010, at the Wayback Machine.

[USFCA601-3] 3.0 ^3.1 USFCA-edu-601-lecture Extreme Programming.

[MASD-4] "एजाइल सॉफ्टवेयर विकास के लिए घोषणापत्र". Agilemanifesto.org. 2001. Retrieved March 26, 2019.

[Cworld92-5] 5.00 ^5.01 ^5.02 ^5.03 ^5.04 ^5.05 ^5.06 ^5.07 ^5.08 ^5.09 ^5.10 ^5.11 ^5.12 Computerworld-appdev-92 "Extreme Programming", Computerworld (online), December 2001.

[SR-6] 6.0 ^6.1 ^6.2 Rosenberg, Doug; Stephens, Matt (2003). Extreme Programming Refactored: The Case Against XP. Apress. ISBN 978-1-59059-096-6.

[FOOTNOTELarmanBasili2003-7] Larman & Basili 2003.

[8] केंट बेक और मार्टिन फाउलर के साथ साक्षात्कार. March 23, 2001. {{cite book}}: |work= ignored (help)

[9] Lisa Crispin; Tip House (2003). एक्सट्रीम प्रोग्रामिंग का परीक्षण. ISBN 9780321113559.

[tr-10] "Everyone's a Programmer" by Clair Tristram. Technology Review, November 2003. p. 39.

[Beck99-11] Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley. ISBN 978-0-321-27865-4.

[12] "चरम प्रोग्रामिंग नियम". extremeprogramming.org.

[13] Ken Auer Archived September 20, 2008, at the Wayback Machine

[CarrollMorris2015-14] John Carroll; David Morris (July 29, 2015). Agile Project Management in easy steps, 2nd edition. In Easy Steps. p. 162. ISBN 978-1-84078-703-0.

[15] Cutter Consortium. "Industrial XP: Making XP Work in Large Organizations - Cutter Consortium". cutter.com.

[16] Extreme Programming (XP) Six Sigma CMMI.

[mcbreen-17] McBreen, P. (2003). एक्सट्रीम प्रोग्रामिंग पर सवाल उठाना. Boston, MA: Addison-Wesley. ISBN 978-0-201-84457-3.

[boehm2004-18] Boehm, B.; R. Turner (2004). Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley. ISBN 978-0-321-18612-6.

[stephens2004-19] Stephens, Matt; Doug Rosenberg (2004). चरम प्रोग्रामिंग की विडंबना. MA: Dr Dobbs journal.

[sdmagazine1811-20] sdmagazine Archived March 16, 2006, at the Wayback Machine

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

Anonymous

Search