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

इतिहास

एक्सट्रीम प्रोग्रामिंग का निर्माण केंट बेक द्वारा क्रिस्लर कॉम्प्रिहेन्सिव कम्पेन्सेशन सिस्टम (Chrysler Comprehensive Compensation System) (सी3) (C3) वेतन भुगतान परियोजना पर अपने कार्य के दौरान किया गया था। मार्च 1996 में बेक सी3 (C3) परियोजना प्रमुख बने और उन्होंने परियोजना में प्रयुक्त विकास विधि को परिष्कृत करना प्रारंभ किया तथा इस विधि पर एक पुस्तक लिखी (अक्टूबर 1999 में, एक्सट्रीम प्रोग्रामिंग एक्सप्लेन्ड (Extreme Programming Explained) का विमोचन हुआ)। 
डैम्लर-बेंज़ द्वारा कम्पनी को अधिग्रहित कर लिये जाने के बाद क्रिस्लर ने फरवरी 2000 में सी3 (C3) परियोजना निरस्त कर दी। 
हालांकि एक्सट्रीम प्रोग्रामिंग स्वयं ही अपेक्षाकृत नई है, फिर भी इसकी अनेक पद्धतियां कुछ समय से प्रयोग की जाती रहीं हैं; आखिर इसकी कार्यप्रणाली "सर्वश्रेष्ठ पद्धतियों" को चरम स्तरों की ओर ले जाती है। उदाहरणार्थ, "टेस्ट-फर्स्ट विकास, नियोजन और प्रत्येक लघु-वृद्धि के पूर्व परीक्षण लिखने की पद्धति" का प्रयोग 1960 के दशक के प्रारंभ में नासा (NASA) के प्रोजेक्ट मर्क्युरी के समय से किया जाता रहा है।(Larman   2003) पुनर्रचना (Refactoring), प्रमापीयता (Modularity), बॉटम-अप तथा वृद्धिशील (Incremental) डिज़ाइन का वर्णन लियो ब्रॉडि ने 1984 में प्रकाशित अपनी किताब में किया है।

उत्पत्तियां

1990 के दशक में हुए सॉफ्टवेयर विकास को मुख्यतः दो बातों ने आकार दिया: आंतरिक रूप से उद्योग के कुछ लोगों द्वारा पसंद किये जाने वाले प्रोग्रामिंग प्रतिमान के रूप में प्रोसीजरल प्रोग्रामिंग का स्थान ऑब्जेक्ट-अभिमुख प्रोग्रामिंग ने ले लिया; बाह्य रूप से, इंटरनेट के उदय और डॉट-कॉम बूम ने प्रतिस्पर्धात्मक कारकों के रूप में बाज़ार-की-ओर-तेज़ी तथा कम्पनी-के-विकास पर ज़ोर दिया। तेज़ी से बदलती आवश्यकताएं संक्षिप्त उत्पाद जीवन-चक्र की मांग कर रहीं थीं और अक्सर सॉफ्टवेयर विकास की पारंपरिक विधियों के साथ असंगत थीं।
क्रिस्लर कॉम्प्रिहेन्सिव कम्पेन्सेशन सिस्टम की शुरुआत अनुसंधान के विषय के रूप में क्रिस्लर के वेतन-तंत्र का प्रयोग करके ऑब्जेक्ट प्रद्योगिकियों के सर्वश्रेष्ठ मार्ग का निर्धारण करने के लिये की गई थी, जिसमें भाषा के रूप में स्मॉलटॉक (Smalltalk) तथा डेटा अभिगम परत के रूप में जेमस्टोन (Gemstone) का प्रयोग हुआ था। इसमें सिस्टम के प्रदर्शन में सुधार के लिये केंट बेक को लाया गया, जो कि स्मॉलटॉक के एक प्रसिद्ध प्रयोगकर्ता थे, लेकिन जब उन्होंने उनकी विकास प्रक्रिया में विभिन्न समस्याओं को देखा, तो उनकी भूमिका बढ़ गई। इस अवसर का लाभ उठाते हुए उन्होंने उनकी पद्धतियों में कुछ परिवर्तन प्रस्तावित व क्रियान्वित किये, जो अपने नियमित सहयोगी वार्ड कनिंघम के साथ किये गये उनके कार्य पर आधारित थे। बेक इन विधियों की प्रारंभिक अवधारणा का वर्णन इस प्रकार करते हैं:
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.
इन विधियों को विकसित व परिष्कृत करने में सहायता प्रदान करने के लिये बेक ने रॉन जेफ्रिस को परियोजना में आमंत्रित किया। इसके बाद जेफ्रिस ने इन पद्धतियों को सी3 (C3) टीम की आदतों में शामिल कराने के लिये आवश्यक प्रशिक्षण देने वाले प्रशिक्षक का कार्य किया।
एक्सपी (XP) की पृष्ठभूमि में स्थित सिद्धांतों और पद्धतियों से संबंधित जानकारी को मूल विकि (Wiki), कनिंघम की विकिविकिवेब (WikiWikiWeb) पर चर्चाओं के द्वारा व्यापक तौर पर विश्व-भर में प्रचारित किया गया। विभिन्न योगदानकर्ताओं ने इस पर चर्चा की और अपने विचार विस्तारित किये, तथा इसके परिणामस्वरूप कुछ अतिरिक्त कार्यप्रणालियों का निर्माण हुआ (तीव्र सॉफ्टवेयर विकास देखें)। साथ ही, अनेक वर्षों से, लगभग 1999 से, एक्सपी (XP) की अवधारणायें "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) इस बात का समर्थन करेगा कि किसी प्रोग्रामिंग समस्या के लिये विभिन्न विकल्प उपलब्ध होने पर, व्यक्ति को सभी समाधानों की कोडिंग करनी चाहिये और स्वचालित परीक्षणों के द्वारा यह निर्धारित करना चाहिये कि कौन सा समाधान सर्वाधिक उपयुक्त है। कोडिंग प्रोग्रामिंग समस्याओं के बारे में विचारों का संप्रेषण करने में भी सहायक होती है। यदि कोई प्रोग्रामर किसी जटिल प्रोग्रामिंग समस्या का सामना कर रहा हो और अपने सहयोगी प्रोग्रामरों को इसका समाधान समझा पाने में कठिनाई महसूस कर रहा हो, तो वह इसकी कोडिंग करके यह प्रदर्शित कर सकता है कि वह क्या कहना चाहता है। कोड, जिसे हम इस स्थिति का प्रस्तावक कह सकते हैं, सदैव ही स्पष्ट और संक्षिप्त होता है और इसकी एक से अधिक व्याख्याएं नहीं की जा सकतीं. अन्य प्रोग्रामर भी अपने विचारों की कोडिंग करके इस कोड पर अपना फीडबैक दे सकते हैं।

श्रवण

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

डिज़ाइनिंग

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

मूल्य

प्रारंभ में 1999 में एक्सट्रीम प्रोग्रामिंग ने चार मूल्यों को मान्यता दी। एक्सट्रीम प्रोग्रामिंग एक्सप्लेन्ड (Extreme Programming Explained) के दूसरे संस्करण में एक नया मूल्य जोड़ा गया। ये पांच मूल्य हैं:

संवाद

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

सरलता

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

साहस

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

सम्मान

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

नियम

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

सिद्धांत

जो सिद्धांत एक्सपी (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) की कम्प्यूटर प्रोग्रामिंग कार्यप्रणालियों के साथ संयोजित करने का प्रयास किया है। उन्होंने पाया कि इन तीनों प्रणालियों ने एक दूसरे को बहुत अच्छी तरह सहारा दिया, जिसका परिणाम बेहतर विकास के रूप में मिला और इनके बीच कोई आपसी टकराव नहीं है।