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



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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 * जोड़ा प्रोग्राम तैयार करना * योजना खेल
 * परीक्षण संचालित विकास
 * अत्यधिक प्रोग्रामिंग अभ्यास#पूरी समूह

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

 * लगातार एकीकरण
 * रिफैक्टरिंग या रूपांकित में सुधार * एक्सट्रीम प्रोग्रामिंग प्रथाएं#छोटी रिलीज

साझा समझ

 * अत्यधिक प्रोग्रामिंग अभ्यास#कोडिंग मानक
 * अत्यधिक प्रोग्रामिंग अभ्यास#सामूहिक कोड स्वामित्व * अत्यधिक प्रोग्रामिंग अभ्यास#सरल रूपांकित * अत्यधिक प्रोग्रामिंग अभ्यास#प्रणाली रूपक

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

 * अत्यधिक प्रोग्रामिंग अभ्यास#टिकाऊ गति

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

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

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

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

स्केलेबिलिटी
विचार कार्य करता है ने साठ लोगों तक वितरित एक्सपी परियोजनाओं पर उचित सफलता का दावा किया है।

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

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

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

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

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

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

यह भी देखें

 * एजाइल सॉफ्टवेयर विकास
 * निरंतर अप्रचलन
 * अत्यधिक विनिर्माण
 * अत्यधिक परियोजना प्रबंधन
 * अत्यधिक प्रोग्रामिंग अभ्यास
 * काइज़ेन
 * सॉफ्टवेयर विकास दर्शन की सूची
 * युग्म प्रोग्रामिंग
 * स्क्रम (विकास)
 * सॉफ्टवेयर शिल्प कौशल
 * स्टैन्डअप सम्मेलन
 * टाइमबॉक्सिंग

अग्रिम पठन

 * Ken Auer and Roy Miller. Extreme Programming Applied: Playing To Win, Addison–Wesley.
 * 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.
 * Matt Stephens and Doug Rosenberg (2003). Extreme Programming Refactored: The Case Against एक्सपी, Apress.
 * Waldner, JB. (2008). "Nanocomputers and Swarm Intelligence". In: ISTE, 225–256.
 * 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