एक्सट्रीम प्रोग्रामिंग
एक्स्ट्रीम प्रोग्रमिंग (Extreme Programming) (एक्सपी) (XP) एक सॉफ्टवेयर विकास कार्यप्रणाली है, जिसका उद्देश्य उपभोक्ता की बदलती हुई आवश्यकताओं के अनुसार सॉफ्टवेयर की गुणवत्ता और प्रतिक्रियात्मकता को बढ़ाना होता है। तीव्र सॉफ्टवेयर विकास के एक प्रकार के रूप में, यह संक्षिप्त विकास चक्रों में नियमित "रिलीज़" का समर्थन करता है (टाइमबॉक्सिंग), जिसका उद्देश्य उत्पादकता में वृद्धि करना तथा जांच-बिंदु प्रस्तुत करना है, जहां उपभोक्ता की नई आवश्यकताओं को अपनाया जा सके।
एक्सट्रीम प्रोग्रामिंग के अन्य तत्वों में शामिल हैं: युग्म में प्रोग्रामिंग करना या गहन कोड समीक्षा करना, पूरे कोड का ईकाई परीक्षण, जब तक विशेषताओं की सचमुच आवश्यकता न हो, उनकी प्रोग्रामिंग करने से बचना, एक सपाट प्रबंधन संरचना, कोड में सरलता और स्पष्टता, समय बीतने और समस्या की बेहतर समझ प्राप्त होने पर उपभोक्ता की आवश्यकताओं में बदलाव की अपेक्षा करना और उपभोक्ता के साथ व प्रोग्रामरों के बीच बार-बार संवाद. इस कार्यप्रणाली का नाम इस विचार के आधार पर पड़ा है कि पारंपरिक सॉफ्टवेयर इंजीनियरिंग पद्धतियों के लाभदायक तत्वों को इसमें इस सिद्धांत के अनुसार "चरम (Extreme)" स्तरों तक ले जाया जाता है कि यदि थोड़ा होना अच्छा है, तो अधिक होना बेहतर होता है। "काउबॉय कोडिंग", जो अधिक मुक्त-स्वरूप वाली तथा अनियोजित होती है, से इसका कोई संबंध नहीं है। यह "डेथ मार्च (Death March)" कार्य शेड्यूल का समर्थन नहीं करती, बल्कि इसके बजाय एक दीर्घकालिक गति पर कार्य करते रहने की वकालत करती है।
आलोचकों ने इसकी अनेक संभावित कमियों का उल्लेख किया है, जिनमें अस्थिर आवश्यकताओं से जुड़ी समस्याएं, प्रयोक्ता के विवादों के लिये किसी लेखबद्ध समझौते की अनुपस्थिति और एक सकल डिज़ाइन विनिर्देश या दस्तावेज की कमी शामिल हैं।
एक्सट्रीम प्रोग्रामिंग का निर्माण केंट बेक द्वारा क्रिस्लर कॉम्प्रिहेन्सिव कम्पेन्सेशन सिस्टम (Chrysler Comprehensive Compensation System) (सी3) (C3) वेतन भुगतान परियोजना पर अपने कार्य के दौरान किया गया था। मार्च 1996 में बेक सी3 (C3) परियोजना प्रमुख बने और उन्होंने परियोजना में प्रयुक्त विकास विधि को परिष्कृत करना प्रारंभ किया तथा इस विधि पर एक पुस्तक लिखी (अक्टूबर 1999 में, "एक्सट्रीम प्रोग्रामिंग एक्सप्लेन्ड (Extreme Programming Explained)" का विमोचन हुआ)।  डैम्लर-बेंज़ द्वारा कम्पनी को अधिग्रहित कर लिये जाने के बाद क्रिस्लर ने फरवरी 2000 में सी3 (C3) परियोजना निरस्त कर दी।
हालांकि एक्सट्रीम प्रोग्रामिंग स्वयं ही अपेक्षाकृत नई है, फिर भी इसकी अनेक पद्धतियां कुछ समय से प्रयोग की जाती रहीं हैं; आखिर इसकी कार्यप्रणाली "सर्वश्रेष्ठ पद्धतियों" को चरम स्तरों की ओर ले जाती है। उदाहरणार्थ, "टेस्ट-फर्स्ट विकास, नियोजन और प्रत्येक लघु-वृद्धि के पूर्व परीक्षण लिखने की पद्धति" का प्रयोग 1960 के दशक के प्रारंभ में नासा (NASA) के प्रोजेक्ट मर्क्युरी के समय से किया जाता रहा है। पुनर्रचना (Refactoring), प्रमापीयता (Modularity), बॉटम-अप तथा वृद्धिशील (Incremental) डिज़ाइन का वर्णन लियो ब्रॉडि ने 1984 में प्रकाशित अपनी किताब में किया है।
1990 के दशक में हुए सॉफ्टवेयर विकास को मुख्यतः दो बातों ने आकार दिया: आंतरिक रूप से उद्योग के कुछ लोगों द्वारा पसंद किये जाने वाले प्रोग्रामिंग प्रतिमान के रूप में प्रोसीजरल प्रोग्रामिंग का स्थान ऑब्जेक्ट-अभिमुख प्रोग्रामिंग ने ले लिया; बाह्य रूप से, इंटरनेट के उदय और डॉट-कॉम बूम ने प्रतिस्पर्धात्मक कारकों के रूप में बाज़ार-की-ओर-तेज़ी तथा कम्पनी-के-विकास पर ज़ोर दिया। तेज़ी से बदलती आवश्यकताएं संक्षिप्त उत्पाद जीवन-चक्र की मांग कर रहीं थीं और अक्सर सॉफ्टवेयर विकास की पारंपरिक विधियों के साथ असंगत थीं।
क्रिस्लर कॉम्प्रिहेन्सिव कम्पेन्सेशन सिस्टम की शुरुआत अनुसंधान के विषय के रूप में क्रिस्लर के वेतन-तंत्र का प्रयोग करके ऑब्जेक्ट प्रद्योगिकियों के सर्वश्रेष्ठ मार्ग का निर्धारण करने के लिये की गई थी, जिसमें भाषा के रूप में स्मॉलटॉक (Smalltalk) तथा डेटा अभिगम परत के रूप में जेमस्टोन (Gemstone) का प्रयोग हुआ था। इसमें सिस्टम के प्रदर्शन में सुधार के लिये केंट बेक को लाया गया, जो कि स्मॉलटॉक के एक प्रसिद्ध प्रयोगकर्ता थे, लेकिन जब उन्होंने उनकी विकास प्रक्रिया में विभिन्न समस्याओं को देखा, तो उनकी भूमिका बढ़ गई। इस अवसर का लाभ उठाते हुए उन्होंने उनकी पद्धतियों में कुछ परिवर्तन प्रस्तावित व क्रियान्वित किये, जो अपने नियमित सहयोगी वार्ड कनिंघम के साथ किये गये उनके कार्य पर आधारित थे। बेक इन विधियों की प्रारंभिक अवधारणा का वर्णन इस प्रकार करते हैं:
इन विधियों को विकसित व परिष्कृत करने में सहायता प्रदान करने के लिये बेक ने रॉन जेफ्रिस को परियोजना में आमंत्रित किया। इसके बाद जेफ्रिस ने इन पद्धतियों को सी3 (C3) टीम की आदतों में शामिल कराने के लिये आवश्यक प्रशिक्षण देने वाले प्रशिक्षक का कार्य किया।
एक्सपी (XP) की पृष्ठभूमि में स्थित सिद्धांतों और पद्धतियों से संबंधित जानकारी को मूल विकि (Wiki), कनिंघम की विकिविकिवेब (WikiWikiWeb) पर चर्चाओं के द्वारा व्यापक तौर पर विश्व-भर में प्रचारित किया गया। विभिन्न योगदानकर्ताओं ने इस पर चर्चा की और अपने विचार विस्तारित किये, तथा इसके परिणामस्वरूप कुछ अतिरिक्त कार्यप्रणालियों का निर्माण हुआ (तीव्र सॉफ्टवेयर विकास देखें)। साथ ही, अनेक वर्षों से, लगभग 1999 से, एक्सपी (XP) की अवधारणायें "https://web.archive.org/web/20190930205401/http://www.extremeprogramming.org/" पर स्थित एक्सपी (XP) की वेबसाइट पर एक हाइपर-टेक्स्ट सिस्टम मानचित्र की सहायता से भी स्पष्ट की जातीं रहीं हैं।
बेक ने एक्सपी (XP) पर लिखी गई पुस्तकों की एक श्रृंखला का संपादन किया, जिसकी शुरुआत उनकी स्वयं की पुस्तक "एक्स्ट्रीम प्रोग्रामिंग एक्सप्लेन्ड (Extreme Programming Explained)" से हुई (1999, ISBN 0-201-61641-6), जिससे यह ज्ञान बहुत बड़े, परंतु फिर भी ग्रहणशील दर्शकों तक फैला. इस श्रृंखला में लेखकों ने एक्सपी (XP) और इसकी पद्धतियों से जुड़े अनेक पहलुओं पर ध्यान दिया। यहां तक कि इन पद्धतियों पर एक विवेचनात्मक पुस्तक भी लिखी गई।
1990 के दशक के अंतिम दौर तथा 2000 के दशक के प्रारंभिक काल में एक्सपी (XP) ने एक रोमांच उत्पन्न किया, जिसका कारण ऐसे अनेक वातावरणों का अभिग्रहण था, जो मूलतः इसकी उत्पत्ति से भिन्न थे।
मूल पद्धतियों के लिये आवश्यक अनुशासन की उच्च मात्रा अक्सर अपने मार्ग से भटक जाती थी, जिससे इनमें से कुछ पद्धतियों, जो बहुत सख्त प्रतीत हुईं, की आलोचना की गई या उन्हें उनके स्थानों पर अपूर्ण अवस्था में ही छोड़ दिया गया। तीव्र विकास पद्धतियां कभी स्थिर खड़ी नहीं रहीं हैं और इस क्षेत्र में मिले अनुभवों को आत्मसात करते हुए एक्सपी (XP) अभी भी विकसित हो रहा है। "एक्सट्रीम प्रोग्रामिंग एक्सप्लेन्ड (Extreme Programming Explained)" के दूसरे संस्करण में बेक ने कुछ नए मूल्य और पद्धतियां शामिल कीं और प्राथमिक तथा सहायक पद्धतियों के बीच अंतर स्पष्ट किया।
"एक्सट्रीम प्रोग्रामिंग एक्सप्लेन्ड (Extreme Programming Explained)" एक्सट्रीम प्रोग्रामिंग का वर्णन सॉफ्टवेयर विकास के एक ऐसे क्षेत्र के रूप में करती है, जो उच्च गुणवत्ता वाले सॉफ्टवेयर का उत्पादन अधिक उत्पादकता के साथ करने के लिये लोगों को संगठित करता है।
पारंपरिक सिस्टम विकास विधियों (जैसे एसएसएडीएम (SSADM) अथवा वॉटरफॉल मॉडल) में सिस्टम की आवश्यकताओं का निर्धारण विकास परियोजना के प्रारंभ में ही कर लिया जाता है और अक्सर वे उस बिंदु से आगे स्थिर रहती हैं। इसका अर्थ यह है कि बाद में किसी चरण में आवश्यकताओं को बदलने (जो कि सॉफ्टवेयर इंजीनियरिंग परियोजनाओं का एक आम लक्षण है) की लागत उच्च होगी। तीव्र सॉफ्टवेयर विकास की अन्य विधियों की ही तरह, एक्सपी (XP) भी परिवर्तन की लागत को कम करने का प्रयास करती है, जिसके लिये एक बड़े विकास चक्र के बजाय अनेक संक्षिप्त विकास चक्रों का प्रयोग किया जाता है। इस सिद्धांत के अनुसार परिवर्तन सॉफ्टवेयर विकास परियोजनाओं का एक स्वाभाविक, अपरिहार्य और वांछित पहलू हैं और आवश्यकताओं के एक स्थिर समुच्चय को परिभाषित करने का प्रयास करने के बजाय उनकी पूर्ति के लिये नियोजन किया जाना चाहिये।
एक्सट्रीम प्रोग्रामिंग ने तीव्र प्रोग्रामिंग ढांचे के शीर्ष पर अनेक बुनियादी मूल्य, सिद्धांत और पद्धतियां भी प्रस्तुत कीं.
एक्सपी (XP) सॉफ्टवेयर विकास प्रक्रिया के भीतर की जाने वाली चार मूलभूत गतिविधियों का वर्णन करती है।
एक्सपी (XP) के समर्थकों का तर्क है कि कोड-ऐसे सॉफ्टवेयर निर्देश, जिन्हें कम्प्यूटर समझ सकता हो, सिस्टम विकास प्रक्रिया का एकमात्र वास्तविक रूप से महत्वपूर्ण उत्पाद है। कोड के बिना, कोई भी कार्य उत्पाद नहीं होता।
कोडिंग का प्रयोग सर्वाधिक उपयुक्त समाधान निकाल पाने में भी किया जा सकता है। उदाहरण के लिये, एक्सपी (XP) इस बात का समर्थन करेगा कि किसी प्रोग्रामिंग समस्या के लिये विभिन्न विकल्प उपलब्ध होने पर, व्यक्ति को सभी समाधानों की कोडिंग करनी चाहिये और स्वचालित परीक्षणों के द्वारा यह निर्धारित करना चाहिये कि कौन सा समाधान सर्वाधिक उपयुक्त है। कोडिंग प्रोग्रामिंग समस्याओं के बारे में विचारों का संप्रेषण करने में भी सहायक होती है। यदि कोई प्रोग्रामर किसी जटिल प्रोग्रामिंग समस्या का सामना कर रहा हो और अपने सहयोगी प्रोग्रामरों को इसका समाधान समझा पाने में कठिनाई महसूस कर रहा हो, तो वह इसकी कोडिंग करके यह प्रदर्शित कर सकता है कि वह क्या कहना चाहता है। कोड, जिसे हम इस स्थिति का प्रस्तावक कह सकते हैं, सदैव ही स्पष्ट और संक्षिप्त होता है और इसकी एक से अधिक व्याख्याएं नहीं की जा सकतीं. अन्य प्रोग्रामर भी अपने विचारों की कोडिंग करके इस कोड पर अपना फीडबैक दे सकते हैं।
जब तक किसी फंक्शन का परीक्षण न किया जाए, तब तक निश्चित रूप से यह नहीं कहा जा सकता कि वह कार्य करता है। बग (Bug) व डिज़ाइन त्रुटियां सॉफ्टवेयर विकास में व्यापक समस्याएं हैं। एक्सट्रीम प्रोग्रामिंग का मार्ग यह है कि यदि परीक्षण की थोड़ी-सी मात्रा कुछ दोषों को दूर कर सकती है, तो अधिक मात्रा में परीक्षण करने पर हम बहुत अधिक दोषों को मिटा सकते हैं।
एक "टेस्टेथॉन (Testathon)" एक ऐसा आयोजन होता है, जिसमें प्रोग्रामर सहयोगपूर्ण परीक्षण लेखन के लिये आपस में मिलते हैं, जो कि सॉफ्टवेयर परीक्षण के संदर्भ में एक प्रकार का विचार-विमर्श होता है।
प्रोग्रामर के लिये इस बात को सुनना अनिवार्य होता है कि उपभोक्ता सिस्टम से क्या कार्य करवाना चाहता है, किस "व्यापार तर्क" की आवश्यकता है। उन्हें अनिवार्य रूप से इन आवश्यकताओं को इतनी अच्छी तरह समझ लेना चाहिये कि वे उपभोक्ता को इस बारे में फीडबैक दे सकें कि समस्या को क्यों सुलझाया जा सकता है या क्यों सुलझाया नहीं जा सकता. उपभोक्ता और प्रोग्रामर के बीच संवाद पर आगे नियोजन खेल (Planning Game) में ध्यान दिया जाता है।
सादगी के दृष्टिकोण से, हम अवश्य ही यह कह सकते हैं कि प्रणाली विकास के लिये कोडिंग, परीक्षण और श्रवण पर्याप्त हैं। यदि वे गतिविधियां भली-भांति पूर्ण की गईं हैं, तो परिणाम के रूप में हमें सदैव ही एक कार्यशील सिस्टम प्राप्त होता है। परंतु व्यावहारिक रूप से, यह कार्य नहीं करेगा। डिज़ाइन के बिना भी व्यक्ति एक लंबा रास्ता तय कर सकता है, लेकिन किसी विशिष्ट बिंदु पर आकर वह फंस जाएगा. सिस्टम बहुत अधिक जटिल बन जाता है और सिस्टम के अंतर्गत निर्भरताएं स्पष्ट नहीं हो पाती हैं। सिस्टम में प्रयुक्त तर्क को व्यवस्थित रूप से रखनेवाली एक डिज़ाइन संरचना का निर्माण करके इससे बचा जा सकता है। अच्छा डिज़ाइन किसी सिस्टम के अंतर्गत अनेक निर्भरताओं से बचा सकता है; इसका अर्थ यह है कि सिस्टम के एक भाग में परिवर्तन करने पर अन्य भाग प्रभावित नहीं होंगे।
प्रारंभ में 1999 में एक्सट्रीम प्रोग्रामिंग ने चार मूल्यों को मान्यता दी। "एक्सट्रीम प्रोग्रामिंग एक्सप्लेन्ड (Extreme Programming Explained)" के दूसरे संस्करण में एक नया मूल्य जोड़ा गया। ये पांच मूल्य हैं:
सॉफ्टवेयर सिस्टम का निर्माण करने के लिये सिस्टम के विकासकर्ताओं तक सिस्टम की आवश्यकताओं का संप्रेषण करना आवश्यक होता है। औपचारिक सॉफ्टवेयर विकास कार्यप्रणालियों में, यह कार्य दस्तावेजीकरण के द्वारा किया जाता है। एक्सट्रीम प्रोग्रामिंग तकनीकों को विकास-दल के सदस्यों के बीच संस्थागत ज्ञान का निर्माण व प्रचार तीव्र गति से करने की विधियों के रूप में देखा जा सकता है। इसका लक्ष्य सभी विकासकर्ताओं को सिस्टम का एक साझा दृश्य प्रदान करना होता है, जो कि सिस्टम के प्रयोक्ता द्वारा सोचे गये दृश्य से मेल खाता हो। इस छोर पर, एक्सट्रीम प्रोग्रामिंग सरल डिज़ाइनों, आम लक्षणों, प्रयोक्ताओं व प्रोग्रामरों के आपसी सहयोग, नियमित मौखिक संवाद और फीडबैक का समर्थन करती है।
एक्सट्रीम प्रोग्रामिंग सबसे सरल समाधान के साथ शुरुआत करने को प्रोत्साहित करती है। अतिरिक्त कार्यात्मकता बाद में जोड़ी जा सकती है। इस विधि और सिस्टम विकास की अधिक पारंपरिक विधियों के बीच अंतर यह है कि इसमें कल, अगले सप्ताह, या अगले माह की आवश्यकताओं के बजाय आज की आवश्यकताओं के लिये डिज़ाइनिंग व कोडिंग करने पर ध्यान केंद्रित किया जाता है। कभी-कभी संक्षेप में इसे "आपको इसकी आवश्यकता नहीं पड़ने वाली है (you ain't gonna need it)" (यैग्नी) (YAGNI) पद्धति कहा जाता है। एक्सपी (XP) के समर्थक इस कमी को मानते हैं कि कभी-कभी इसके कारण भविष्य में सिस्टम में परिवर्तन करने के लिये अधिक प्रयास करना पड़ सकता है; उनका तर्क यह है कि इस कमी की पूर्ति इस लाभ के द्वारा हो जाती है कि हमें उन भावी आवश्यकताओं में निवेश नहीं करना पड़ता, जो प्रासंगिक बन पाने से पूर्व परिवर्तित हो सकती हैं। भविष्य की अनिश्चित आवश्यकताओं के लिये कोडिंग और डिज़ाइनिंग करने में इस बात का खतरा रहता है कि ऐसी बात के लिये अपने संसाधन खर्च किये जा रहे हैं, जिसकी आवश्यकता शायद न भी पड़े. "संवाद" मूल्य के संबंध में, डिज़ाइन और कोडिंग की सरलता से संवाद की गुणवत्ता में सुधार होना चाहिये। बहुत ही सरल कोड के साथ एक सरल डिज़ाइन को दल के अधिकांश प्रोग्रामरों द्वारा सरलता से समझा जा सकता है।
एक्सट्रीम प्रोग्रामिंग के अंतर्गत, फीडबैक सिस्टम विकास के विभिन्न आयामों से संबंधित होता है:
संवाद और सरलता के साथ फीडबैक का निकट संबंध होता है। सिस्टम में उपस्थित दोषों को एक ऐसा ईकाई परीक्षण लिखकर सरलता से संप्रेषित किया जा सकता है, जो यह साबित करता हो कि कोड का विशिष्ट भाग टूट जाएगा. सिस्टम से मिलने वाले प्रत्यक्ष फीडबैक से प्रोग्रामरों को यह पता चलता है कि इस भाग की कोडिंग पुनः करनी है। समय-समय पर उपभोक्ता कार्यात्मक आवश्यकताओं के अनुसार सिस्टम का परीक्षण कर पाने में सक्षम होता है, जिन्हें "प्रयोक्ता कथाएं (User Stories)" कहते हैं। केंट बेक के शब्दों में, "आशावादिता प्रोग्रामिंग का एक व्यावसायिक जोखिम है और फीडबैक उसका उपचार है।" अनेक पद्धतियों में साहस सम्मिलित होता है। इनमें से एक यह नियम है कि डिज़ाइनिंग और कोडिंग सदैव ही आज के लिये करनी चाहिये, न कि आने वाले कल के लिये। यह डिज़ाइन में फंसकर उलझ जाने और कुछ और क्रियान्वित करने के लिये अत्यधिक प्रयास करने की आवश्यकता से बचने का प्रयास है। साहस विकासकर्ताओं को आवश्यकता के अनुसार अपने कोड की पुनर्रचना के कार्य के दौरान सहज महसूस कर पाने में सक्षम बनाता है। इसका अर्थ है, वर्तमान सिस्टम की समीक्षा करना और उसे संशोधित करना, ताकि भावी परिवर्तनों को अधिक सरलतापूर्वक लागू किया जा सके। साहस का एक अन्य उदाहरण इस बाद को जानना है कि कोड को कब हटा देना है: अनुपयोगी स्रोत कोड को हटाने का साहस, भले ही उस स्रोत कोड के निर्माण में चाहे कितनी ही ज्यादा मेहनत क्यों न लगी हो। साथ ही साहस का अर्थ दृढ़ता भी है: हो सकता है कि कोई प्रोग्रामर पूरे दिन किसी एक जटिल समस्या में फंसा रहे और दूसरे दिन वह इसे बहुत जल्दी सुलझा ले, लेकिन यह केवल तभी संभव है, जब वह दृढ़ हो।
सम्मान मूल्य में दूसरों के लिये सम्मान के साथ ही आत्म-सम्मान भी शामिल होता है। प्रोग्रामरों को कभी भी ऐसे परिवर्तन नहीं करने चाहिये, जो कम्पाइलेशन को तोड़ दें, जो वर्तमान ईकाई-परीक्षणों को विफल बना दें, अथवा जो अन्यथा अपने सहकर्मियों के कार्य को विलंबित कर दें। सदैव उच्च गुणवत्ता का प्रयास करके और उपलब्ध समाधान के लिये पुनर्रचना के द्वारा सर्वश्रेष्ठ डिज़ाइन बनाने का प्रयास करके सदस्य अपने स्वयं के कार्य का सम्मान करते हैं।
पिछले चार मूल्यों को अपनाने के परिणामस्वरूप टीम के अन्य सदस्यों की ओर से सम्मान प्राप्त होता है। टीम के किसी सदस्य को यह महसूस नहीं होना चाहिये कि उसकी प्रशंसा नहीं की जाती या उसकी उपेक्षा की जा रही है। इससे प्रेरणा का एक उच्च स्तर सुनिश्चित होता है और यह टीम के प्रति और परियोजना के लक्ष्य के प्रति वफादारी को प्रोत्साहित करती है। यह मूल्य अन्य मूल्यों पर अत्यधिक निर्भर होता है और टीम के लोगों की ओर बहुत अधिक अभिमुख होता है।
एक्सपी (XP) के नियमों का पहला संस्करण केन ऑयर द्वारा एक्सपी/एजाइल यूनिवर्स 2003 में प्रस्तावित किया गया था। उन्होंने यह महसूस किया कि एक्सपी (XP) को इसके नियमों के द्वारा परिभाषित किया गया था, न कि इसकी पद्धतियों के द्वारा (जिनमें अधिक भिन्नता और अस्पष्टता होती है)। उन्होंने दो श्रेणियां परिभाषित कीं: "कार्य के नियम", जो उस वातावरण का वर्णन करते हैं, जिसमें सॉफ्टवेयर विकास का कार्य प्रभावी रूप से किया जा सकता हो, तथा "खेल के नियम", जो कार्य के नियमों के ढांचे के अंतर्गत मिनट-दर-मिनट की जाने वाली गतिविधियों तथा नियमों को परिभाषित करते हैं।
आईसीएसई 2008 सम्मेलन (ICSE 2008 Conference) की एप्सो कार्यशाला (APSO Workshop) में, मेहदी मिराखोरली ने एक्सट्रीम प्रोग्रामिंग का एक नया और अधिक स्पष्ट व विशद संस्करण प्रस्तावित किया, जो कि पद्धतियों से अधिक स्वतंत्र था और जिसका अधिक "तीव्र" होना अभीष्ट था।
मेहदी मिराखोरली के अनुसार, ये हैं:जो सिद्धांत एक्सपी (XP) का आधार बनाते हैं, वे अभी-अभी वर्णित मूल्यों पर आधारित होते हैं और उनका उद्देश्य एक सिस्टम विकास परियोजना में निर्णयों को प्रोत्साहित करना होता है। सिद्धांत मूल्यों से अधिक दृढ़ होने चाहिये और किसी व्यावहारिक परिस्थिति में वे अधिक सरलता से एक मार्गदर्शन में अनुवादित होने चाहिये।
एक्सट्रीम प्रोग्रामिंग में फीडबैक को सर्वाधिक उपयोगी माना जाता है, यदि इसे तीव्रता से किया गया हो और यह इस बात को व्यक्त करता हो कि किसी कार्य और इसके फीडबैक के बीच का समय सीखने और परिवर्तन करने के लिये बहुत अधिक महत्वपूर्ण होता है। पारंपरिक सिस्टम विकास विधियों के विपरीत, उपभोक्ता के साथ कम अवधि वाले चक्रों में बार-बार संपर्क किया जाता है। विकसित किये जा रहे सिस्टम के बारे में उपभोक्ता के पास एक स्पष्ट अंतर्दृष्टि होती है। वह अपना फीडबैक दे सकता है और आवश्यकता के अनुसार विकास को संचालित भी कर सकता है।
ईकाई परीक्षण भी तीव्र फीडबैक सिद्धांत के प्रति सहायक होते हैं। कोड लिखते समय, ईकाई परीक्षण इस बारे में प्रत्यक्ष फीडबैक प्रदान करता है कि एक बार परिवर्तन कर दिये जाने पर सिस्टम इनके प्रति किस प्रकार की प्रतिक्रिया देता है। उदाहरणार्थ, यदि परिवर्तन सिस्टम के किसी ऐसे भाग को प्रभावित करते हों, जो उन्हें बनाने वाले प्रोग्रामर के दायरे में नहीं आता, तो वह प्रोग्रामर उस दोष को नहीं देख सकेगा। इस बात की बहुत अधिक संभावना है कि जब सिस्टम का उत्पादन किया जायेगा, तो उस समय यह त्रुटि उपस्थित होगी।
इसके अंतर्गत प्रत्येक समस्या के साथ यह मानकर कार्य किया जाता है कि वह "अत्यधिक सरल" है। पारंपरिक सिस्टम विकास विधियां भविष्य के लिये नियोजन करने और पुनर्प्रयोग के लिये कोड लिखने को कहतीं हैं। एक्सट्रीम प्रोग्रामिंग इन विचारों को अस्वीकार करती है।
एक्सट्रीम प्रोग्रामिंग के समर्थक कहते हैं कि बड़े परिवर्तन एक ही बार में एक साथ करना उपयुक्त नहीं होता। एक्सट्रीम प्रोग्रामिंग वृद्धिशील परिवर्तनों को लागू करती है: उदाहरण के लिये, प्रत्येक तीन सप्ताह बाद किसी सिस्टम के छोटे संस्करण को रिलीज़ किया जा सकता है। जब अनेक छोटे-छोटे कदम बनाये जाते हैं, तो उपभोक्ता के पास विकास प्रक्रिया का और विकसित किये जा रहे सिस्टम का अधिक नियंत्रण होता है।
परिवर्तन को अपनाने का सिद्धांत परिवर्तनों के विपरीत काम न करने और उन्हें स्वीकार करने से संबंधित है। उदाहरण के लिये, यदि चरणबद्ध बैठकों में से किसी एक के दौरान यह दिखाई दे कि उपभोक्ता की आवश्यकताएं नाटकीय रूप से बदल गईं हैं, तो प्रोग्रामर इसे स्वीकार करते हैं और अगले चरण के लिये नई आवश्यकताओं की योजना बनाते हैं।
एक्सट्रीम प्रोग्रामिंग में 12 पद्धतियों का वर्णन किया गया है, जो चार क्षेत्रों में समूहबद्ध की गईं हैं:
एक्सपी (XP) की पद्धतियों पर अत्यधिक विवाद होता रहा है, जिसमें एक्सपी (XP) के प्रयोग के समर्थन और विरोध में कठोर विचार व्यक्त हुए हैं।
एक्सट्रीम प्रोग्रामिंग के समर्थकों का दावा है कि उपभोक्ता की आवश्यकताओं में परिवर्तन के निवेदन अनौपचारिक रूप से कार्य-स्थल पर ही प्राप्त हो जाने के कारण यह प्रक्रिया अधिक लचीली बनती है और इसके कारण औपचारिक खर्च की लागत बचती है। एक्सपी (XP) के आलोचक दावा करते हैं कि इसके परिणामस्वरूप दोबारा कार्य करना महंगा पड़ सकता है और धीरे-धीरे परियोजना का दायरा उस सीमा से बाहर चला जाता है, जिस पर पूर्व में सहमति बनी थी या जिसके लिये धन दिया गया था।
परिवर्तन नियंत्रण बोर्ड इस बात का संकेत हैं कि परियोजना के उद्देश्यों और बाधाओं के बारे में अनेक प्रयोक्ताओं के बीच टकराव संभावित हैं। एक्सपी (XP) की तीव्र कार्यप्रणाली कुछ हद तक इस बात पर निर्भर होती है कि प्रोग्रामर उपभोक्ता के एक एकीकृत दृष्टिकोण की कल्पना कर पाने में सक्षम हों, ताकि प्रोग्रामर समझौते के उद्देश्यों और बाधाओं के दस्तावेजीकरण के बजाय अपना ध्यान कोडिंग पर केंद्रित कर सकें. यह बात तब भी लागू होती है, जब अनेक कोडिंग संगठन शामिल हों, विशिष्ट रूप से ऐसे संगठन, जिनके बीच परियोजनाओं के अंश को लेकर प्रतिस्पर्धा जारी हो।
एक्सट्रीम प्रोग्रामिंग के संभावित रूप से विवादास्पद अन्य पहलुओं में शामिल हैं:
ऐतिहासिक रूप से, एक्सपी (XP) केवल बारह या इससे कम लोगों के समूहों में कार्य करता है। परियोजना को छोटे भागों में तोड़ना और फिर छोटे समूहों में टीम बनाना इस सीमा को धोखा देने का एक उपाय है। यह दावा किया जाता रहा है कि एक्सपी (XP) का प्रयोग सौ से भी अधिक सदस्यों के समूहों पर सफलतापूर्वक किया जाता रहा है। थॉटवर्क्स (ThoughtWorks) ने दावा किया है कि उन्होंने वितरित एक्सपी (XP) परियोजनाओं पर साठ लोगों तक की संख्या वाले समूहों के साथ कार्य करके पर्याप्त सफलता पाई है।
2004 में, इंडस्ट्रियल एक्सट्रीम प्रोग्रामिंग (Industrial Extreme Programming) (आईएक्सपी) (IXP) को एक्सपी (XP) के एक विस्तार के रूप में प्रस्तुत किया गया। इसका उद्देश्य बड़े और वितरित समूहों में कार्य करने की क्षमता प्रदान करना है। अब इसमें 23 पद्धतियां और लचीले मूल्य हैं। चूंकि यह एजाइल (Agile) परिवार का नया सदस्य है, अतः इसकी उपयोगिता सिद्ध करने के लिये अभी पर्याप्त डेटा उपलब्ध नहीं है, हालांकि, यह दावा किया जाता है कि यह उस बात का जवाब है, जिसे एक्सपी (XP) की कमी माना जाता है।
2003 में, मैट स्टीफन्स और डफ रॉसेनबर्ग ने "एक्सट्रीम प्रोग्रामिंग रिफैक्टर्ड : द केस अगेन्स्ट एक्सपी (Extreme Programming REgactored: The Case Against XP)" प्रकाशित की, जिसने एक्सपी (XP) प्रक्रिया के मूल्य पर सवाल खड़े किये और इसमें सुधार करने के लिये कुछ उपाय सुझाये. इसके कारण लेखों, इंटरनेट समाचार-समूहों और वेब-साइट चैट क्षेत्रों में एक लंबी बहस शुरु हो गई। इस पुस्तक का मूल तर्क यह है कि एक्सपी (XP) की पद्धतियां अंतःनिर्भर हैं, परंतु कुछ ही व्यावहारिक संगठन इन सभी पद्धतियों को अपनाने के इच्छुक/सक्षम हैं; अतः पूरी प्रक्रिया विफल हो जाती है। यह पुस्तक अन्य आलोचनाएं भी करती है और एक्सपी (XP) के "सामूहिक स्वामित्व" के मॉडल की समाजवाद के साथ समानता को एक नकारात्मक स्वरूप में प्रस्तुत करती है।
पुस्तक "एक्सट्रीम प्रोग्रामिंग रिफैक्टर्ड (Extreme Programming Refactored)" (2003) के प्रकाशन के बाद से एक्सपी (XP) के कुछ पहलुओं में परिवर्तन हुआ है; विशिष्ट रूप से, एक्सपी (XP) अब पद्धतियों में तब तक संशोधनों को अनुकूल बनाता है, जब तक कि आवश्यक उद्देश्यों की पूर्ति होती रहे। एक्सपी (XP) में प्रक्रियाओं के लिये सामान्य शब्दावलियों का प्रयोग भी बढ़ता जा रहा है। कुछ लोगों का तर्क है कि ये परिवर्तन पिछली आलोचनाओं को अमान्य बना देते हैं; कुछ अन्य लोग दावा करते हैं कि यह केवल प्रक्रिया को सींचने का प्रयास है।
आरडीपी (RDP) पद्धति एक एक्सट्रीम प्रोग्रामिंग को अपनी आवश्यकताओं के अनुसार प्रयोग करने की एक तकनीक है। प्रारंभिक रूप से यह तकनीक फिलिपे क्रुश्तेन और स्टीव एडॉल्फ द्वारा आयोजित एक कार्यशाला में एक लंबे शोध-पत्र के रूप में प्रकाशित की गई थी (आईसीएसई (ICSE) 2008 में एप्सो (APSO) कार्यशाला देखें) और फिर भी यह केवल एक्सपी (XP) को अपनी आवश्यकतानुसार संशोधित करने के लिये प्रस्तावित एवं प्रयोज्य विधि है। आरडीपी (RDP) पद्धति की पृष्ठभूमि में स्थित मूल्यवान अवधारणाओं ने बहुत थोड़े समय में ही उद्योगों में इसकी प्रयोज्यता के लिये औचित्य प्रदान किया। आरडीपी (RDP) पद्धतियां तकनीक एक्सपी (XP) नियमों पर आश्रित रहते हुए एक्सपी (XP) को अपनी आवश्यकतानुसार संशोधित करने का प्रयास करती हैं।
अन्य लेखकों ने एक्सपी (XP) को पुरानी विधियों के साथ मिलाने का प्रयास किया है, ताकि एक एकीकृत कार्यप्रणाली का निर्माण किया जा सके। इनमें से कुछ एक्सपी (XP) को प्रतिस्थापित करने का प्रयास करते हैं, जैसे वॉटरफॉल विधि; उदाहरण: परियोजना जीवन-चक्र: वॉटरफॉल, रैपिड एक्शन डेवलपमेंट आदि सभी कुछ. जेपीमॉर्गन चेस एण्ड कम्पनी (JPMorgan Chase & Co.) ने एक्सपी (XP) को कैपेबिलिटी मैच्युरिटी मॉडल इंटीग्रेशन (Capability Maturity Model Integration) (सीएमएमआई) (CMMI) और सिक्स सिग्मा (Six Sigma) की कम्प्यूटर प्रोग्रामिंग कार्यप्रणालियों के साथ संयोजित करने का प्रयास किया है। उन्होंने पाया कि इन तीनों प्रणालियों ने एक दूसरे को बहुत अच्छी तरह सहारा दिया, जिसका परिणाम बेहतर विकास के रूप में मिला और इनके बीच कोई आपसी टकराव नहीं है।
एक्सट्रीम प्रोग्रामिंग के प्रारंभिक रोमांच और विवादास्पद सिद्धांतों, जैसे युग्म प्रोग्रामिंग और सतत डिज़ाइन, ने विशिष्ट आलोचना को आकर्षित किया है, जैसे मैकब्रीन (McBreen) तथा बोहेम व टर्नर की ओर से आने वाली आलोचना. हालांकि, एजाइल (Agile) पद्धतियों के प्रयोक्ताओं का विश्वास है कि इनमें से अधिकांश आलोचनाओं का कारण तीव्र विकास की गलत समझ है।
विशिष्ट रूप से, एक्सट्रीम प्रोग्रामिंग की समीक्षा और आलोचना मैट स्टीफेंस और डफ रॉसेनबर्ग की "एक्सट्रीम प्रोग्रामिंग रिफैक्टर्ड (Extreme Programming Refactored)" द्वारा की गई है।
आलोचनाओं में शामिल हैं: