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



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

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

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

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

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


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

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

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

"The first time I was asked to lead a team, I asked them to do a little bit of the things I thought were sensible, like testing and reviews. The second time there was a lot more on the line. I thought, "Damn the torpedoes, at least this will make a good article," [and] asked the team to crank up all the knobs to 10 on the things I thought were essential and leave out everything else."

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

साझा समझ

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

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

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

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

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

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

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

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

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

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

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

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

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

यह भी देखें

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

अग्रिम पठन

 * 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 XP, Apress.
 * Waldner, JB. (2008). "Nanocomputers and Swarm Intelligence". In: ISTE, 225–256.
 * Matt Stephens and Doug Rosenberg (2003). Extreme Programming Refactored: The Case Against XP, Apress.
 * Waldner, JB. (2008). "Nanocomputers and Swarm Intelligence". In: ISTE, 225–256.

बाहरी संबंध

 * A gentle introduction
 * Industrial eXtreme Programming
 * Problems and Solutions to XP implementation
 * Using an Agile Software Process with Offshore Development – ThoughtWorks' experiences with implementing XP in large distributed projects