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

जनवरी 2008 thumb|240px|एक्सट्रीम प्रोग्रामिंग (XP) के साथ योजना और एकाधिक लूप्स के समय फ्रेम में प्रतिक्रिया लूप्स. एक्स्ट्रीम प्रोग्रमिंग (extreme programming) (एक्सपी) (XP) एक सॉफ्टवेयर विकास कार्यप्रणाली है, जिसका उद्देश्य उपभोक्ता की बदलती हुई आवश्यकताओं के अनुसार सॉफ्टवेयर की गुणवत्ता और प्रतिक्रियात्मकता को बढ़ाना होता है। तीव्र सॉफ्टवेयर विकास के एक प्रकार के रूप में,"मानव सेंटर्ड प्रौद्योगिकी कार्यशाला 2005", 2005, पीडीएफ वेबपेज: सूचना-ब्रिटेन-रिपोर्ट-cdrp585जून 2020 InternetArchiveBot . यह संक्षिप्त विकास चक्रों में नियमित "रिलीज़" का समर्थन करता है (टाइमबॉक्सिंग), जिसका उद्देश्य उत्पादकता में वृद्धि करना तथा जांच-बिंदु प्रस्तुत करना है, जहां उपभोक्ता की नई आवश्यकताओं को अपनाया जा सके। एक्सट्रीम प्रोग्रामिंग के अन्य तत्वों में शामिल हैं: युग्म में प्रोग्रामिंग करना या गहन कोड समीक्षा करना, पूरे कोड का ईकाई परीक्षण, जब तक विशेषताओं की सचमुच आवश्यकता न हो, उनकी प्रोग्रामिंग करने से बचना, एक सपाट प्रबंधन संरचना, कोड में सरलता और स्पष्टता, समय बीतने और समस्या की बेहतर समझ प्राप्त होने पर उपभोक्ता की आवश्यकताओं में बदलाव की अपेक्षा करना और उपभोक्ता के साथ व प्रोग्रामरों के बीच बार-बार संवाद."डिजाइन पैटर्न और रिफैक्टरिंग", पेंसिल्वेनिया के विश्वविद्यालय, 2003, वेबपेज: युपेन-व्याख्यान-डिजाइन पैटन https://web.archive.org/web/20100802073814/http://www.cis.upenn.edu/%7Ematuszek/cit591-2003/Lectures/49-design-patterns.ppt 2 अगस्त 2010 ."एक्सट्रीम प्रोग्रामिंग" (व्याख्यान कागज), USFCA.edu, वेबपेज: USFCA-edu-601-व्याख्यान https://web.archive.org/web/20110526175358/http://www.cs.usfca.edu/~parrt/course/601/lectures/xp.html 26 मई 2011 ."फुर्तीली सॉफ्टवेयर विकास के लिए घोषणा पत्र", एजाइल एलायंस, 2001, वेबपेज: घोषणा पत्र के बदले चंचल सॉफ्टवेयर-देव https://web.archive.org/web/20110223004611/http://agilemanifesto.org/ 23 फ़रवरी 2011 इस कार्यप्रणाली का नाम इस विचार के आधार पर पड़ा है कि पारंपरिक सॉफ्टवेयर इंजीनियरिंग पद्धतियों के लाभदायक तत्वों को इसमें इस सिद्धांत के अनुसार "चरम (Extreme)" स्तरों तक ले जाया जाता है कि यदि थोड़ा होना अच्छा है, तो अधिक होना बेहतर होता है। "काउबॉय कोडिंग", जो अधिक मुक्त-स्वरूप वाली तथा अनियोजित होती है, से इसका कोई संबंध नहीं है। यह "डेथ मार्च (Death March)" कार्य शेड्यूल का समर्थन नहीं करती, बल्कि इसके बजाय एक दीर्घकालिक गति पर कार्य करते रहने की वकालत करती है। आलोचकों ने इसकी अनेक संभावित कमियों का उल्लेख किया है, जिनमें अस्थिर आवश्यकताओं से जुड़ी समस्याएं, प्रयोक्ता के विवादों के लिये किसी लेखबद्ध समझौते की अनुपस्थिति और एक सकल डिज़ाइन विनिर्देश या दस्तावेज की कमी शामिल हैं। 3 इतिहास एक्सट्रीम प्रोग्रामिंग का निर्माण केंट बेक द्वारा क्रिस्लर कॉम्प्रिहेन्सिव कम्पेन्सेशन सिस्टम (Chrysler Comprehensive Compensation System) (सी3) (C3) वेतन भुगतान परियोजना पर अपने कार्य के दौरान किया गया था। मार्च 1996 में बेक सी3 (C3) परियोजना प्रमुख बने और उन्होंने परियोजना में प्रयुक्त विकास विधि को परिष्कृत करना प्रारंभ किया तथा इस विधि पर एक पुस्तक लिखी (अक्टूबर 1999 में, एक्सट्रीम प्रोग्रामिंग एक्सप्लेन्ड (Extreme Programming Explained) का विमोचन हुआ)। "एक्सट्रीम प्रोग्रामिंग", कंप्यूटरवर्ल्ड (ऑनलाइन), दिसंबर 2001, वेबपेज: Computerworld-appdev-92 https://web.archive.org/web/20081220071242/http://www.computerworld.com/softwaretopics/software/appdev/story/0,10801,66192,00.html 20 दिसंबर 2008 . डैम्लर-बेंज़ द्वारा कम्पनी को अधिग्रहित कर लिये जाने के बाद क्रिस्लर ने फरवरी 2000 में सी3 (C3) परियोजना निरस्त कर दी। Matt Stephens, Doug Rosenberg Extreme Programming Refactored: The Case Against XP 1590590961 registration https://archive.org/details/extremeprogrammi00matt हालांकि एक्सट्रीम प्रोग्रामिंग स्वयं ही अपेक्षाकृत नई है, फिर भी इसकी अनेक पद्धतियां कुछ समय से प्रयोग की जाती रहीं हैं; आखिर इसकी कार्यप्रणाली "सर्वश्रेष्ठ पद्धतियों" को चरम स्तरों की ओर ले जाती है। उदाहरणार्थ, "टेस्ट-फर्स्ट विकास, नियोजन और प्रत्येक लघु-वृद्धि के पूर्व परीक्षण लिखने की पद्धति" का प्रयोग 1960 के दशक के प्रारंभ में नासा (NASA) के प्रोजेक्ट मर्क्युरी के समय से किया जाता रहा है। Larman 2003 पुनर्रचना (Refactoring), प्रमापीयता (Modularity), बॉटम-अप तथा वृद्धिशील (Incremental) डिज़ाइन का वर्णन लियो ब्रॉडि ने 1984 में प्रकाशित अपनी किताब में किया है।Brodie Leo Thinking Forth https://archive.org/details/thinkingforthlan00brod paperback 2006-06-19 1984 Prentice-Hall 0-13-917568-7 registration उत्पत्तियां 1990 के दशक में हुए सॉफ्टवेयर विकास को मुख्यतः दो बातों ने आकार दिया: आंतरिक रूप से उद्योग के कुछ लोगों द्वारा पसंद किये जाने वाले प्रोग्रामिंग प्रतिमान के रूप में प्रोसीजरल प्रोग्रामिंग का स्थान ऑब्जेक्ट-अभिमुख प्रोग्रामिंग ने ले लिया; बाह्य रूप से, इंटरनेट के उदय और डॉट-कॉम बूम ने प्रतिस्पर्धात्मक कारकों के रूप में बाज़ार-की-ओर-तेज़ी तथा कम्पनी-के-विकास पर ज़ोर दिया। तेज़ी से बदलती आवश्यकताएं संक्षिप्त उत्पाद जीवन-चक्र की मांग कर रहीं थीं और अक्सर सॉफ्टवेयर विकास की पारंपरिक विधियों के साथ असंगत थीं। क्रिस्लर कॉम्प्रिहेन्सिव कम्पेन्सेशन सिस्टम की शुरुआत अनुसंधान के विषय के रूप में क्रिस्लर के वेतन-तंत्र का प्रयोग करके ऑब्जेक्ट प्रद्योगिकियों के सर्वश्रेष्ठ मार्ग का निर्धारण करने के लिये की गई थी, जिसमें भाषा के रूप में स्मॉलटॉक (Smalltalk) तथा डेटा अभिगम परत के रूप में जेमस्टोन (Gemstone) का प्रयोग हुआ था। इसमें सिस्टम के प्रदर्शन में सुधार के लिये केंट बेक को लाया गया, जो कि स्मॉलटॉक के एक प्रसिद्ध प्रयोगकर्ता थे, लेकिन जब उन्होंने उनकी विकास प्रक्रिया में विभिन्न समस्याओं को देखा, तो उनकी भूमिका बढ़ गई। इस अवसर का लाभ उठाते हुए उन्होंने उनकी पद्धतियों में कुछ परिवर्तन प्रस्तावित व क्रियान्वित किये, जो अपने नियमित सहयोगी वार्ड कनिंघम के साथ किये गये उनके कार्य पर आधारित थे। बेक इन विधियों की प्रारंभिक अवधारणा का वर्णन इस प्रकार करते हैं:http://www.informit.com/articles/article.aspx?p=20972 संग्रहीत प्रति 11 अगस्त 2010 https://web.archive.org/web/20111111075414/http://www.informit.com/articles/article.aspx?p=20972 11 नवंबर 2011 dead 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) की अवधारणायें "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) इस बात का समर्थन करेगा कि किसी प्रोग्रामिंग समस्या के लिये विभिन्न विकल्प उपलब्ध होने पर, व्यक्ति को सभी समाधानों की कोडिंग करनी चाहिये और स्वचालित परीक्षणों के द्वारा यह निर्धारित करना चाहिये कि कौन सा समाधान सर्वाधिक उपयुक्त है।June 2009 कोडिंग प्रोग्रामिंग समस्याओं के बारे में विचारों का संप्रेषण करने में भी सहायक होती है। यदि कोई प्रोग्रामर किसी जटिल प्रोग्रामिंग समस्या का सामना कर रहा हो और अपने सहयोगी प्रोग्रामरों को इसका समाधान समझा पाने में कठिनाई महसूस कर रहा हो, तो वह इसकी कोडिंग करके यह प्रदर्शित कर सकता है कि वह क्या कहना चाहता है। कोड, जिसे हम इस स्थिति का प्रस्तावक कह सकते हैं, सदैव ही स्पष्ट और संक्षिप्त होता है और इसकी एक से अधिक व्याख्याएं नहीं की जा सकतीं. अन्य प्रोग्रामर भी अपने विचारों की कोडिंग करके इस कोड पर अपना फीडबैक दे सकते हैं। परीक्षण जब तक किसी फंक्शन का परीक्षण न किया जाए, तब तक निश्चित रूप से यह नहीं कहा जा सकता कि वह कार्य करता है। बग (Bug) व डिज़ाइन त्रुटियां सॉफ्टवेयर विकास में व्यापक समस्याएं हैं। एक्सट्रीम प्रोग्रामिंग का मार्ग यह है कि यदि परीक्षण की थोड़ी-सी मात्रा कुछ दोषों को दूर कर सकती है, तो अधिक मात्रा में परीक्षण करने पर हम बहुत अधिक दोषों को मिटा सकते हैं। ईकाई परीक्षण यह निर्धारित करता है कि क्या कोई विशेषता उसी प्रकार कार्य करती है, जैसा कि अभीष्ट है। एक प्रोग्रामर वे सभी स्वचालित परीक्षण लिखता है, जो उसके अनुसार कोड को "तोड़" सकते हैं; यदि सभी परीक्षण सफलतापूर्वक क्रियान्वित हो जाते हैं, तो कोडिंग पूरी हो जाती है। कोड के जो भी भाग लिखे गये हैं, अगली विशेषता की ओर बढ़ने से पूर्व उन सभी का परीक्षण किया जाता है। स्वीकृति परीक्षण इस बात का सत्यापन करता है कि प्रोग्रामर ने आवश्यकताओं को इस प्रकार भली-भांति समझ लिया है कि उपभोक्ता की वास्तविक आवश्यकताओं की पूर्ति की जा सके। ये रिलीज़ नियोजन के अन्वेषण चरण में किये जाते हैं। एक "टेस्टेथॉन (Testathon)" एक ऐसा आयोजन होता है, जिसमें प्रोग्रामर सहयोगपूर्ण परीक्षण लेखन के लिये आपस में मिलते हैं, जो कि सॉफ्टवेयर परीक्षण के संदर्भ में एक प्रकार का विचार-विमर्श होता है। श्रवण प्रोग्रामर के लिये इस बात को सुनना अनिवार्य होता है कि उपभोक्ता सिस्टम से क्या कार्य करवाना चाहता है, किस "व्यापार तर्क" की आवश्यकता है। उन्हें अनिवार्य रूप से इन आवश्यकताओं को इतनी अच्छी तरह समझ लेना चाहिये कि वे उपभोक्ता को इस बारे में फीडबैक दे सकें कि समस्या को क्यों सुलझाया जा सकता है या क्यों सुलझाया नहीं जा सकता. उपभोक्ता और प्रोग्रामर के बीच संवाद पर आगे नियोजन खेल (Planning Game) में ध्यान दिया जाता है। डिज़ाइनिंग सादगी के दृष्टिकोण से, हम अवश्य ही यह कह सकते हैं कि प्रणाली विकास के लिये कोडिंग, परीक्षण और श्रवण पर्याप्त हैं। यदि वे गतिविधियां भली-भांति पूर्ण की गईं हैं, तो परिणाम के रूप में हमें सदैव ही एक कार्यशील सिस्टम प्राप्त होता है। परंतु व्यावहारिक रूप से, यह कार्य नहीं करेगा। डिज़ाइन के बिना भी व्यक्ति एक लंबा रास्ता तय कर सकता है, लेकिन किसी विशिष्ट बिंदु पर आकर वह फंस जाएगा. सिस्टम बहुत अधिक जटिल बन जाता है और सिस्टम के अंतर्गत निर्भरताएं स्पष्ट नहीं हो पाती हैं। सिस्टम में प्रयुक्त तर्क को व्यवस्थित रूप से रखनेवाली एक डिज़ाइन संरचना का निर्माण करके इससे बचा जा सकता है। अच्छा डिज़ाइन किसी सिस्टम के अंतर्गत अनेक निर्भरताओं से बचा सकता है; इसका अर्थ यह है कि सिस्टम के एक भाग में परिवर्तन करने पर अन्य भाग प्रभावित नहीं होंगे। June 2009 मूल्य प्रारंभ में 1999 में एक्सट्रीम प्रोग्रामिंग ने चार मूल्यों को मान्यता दी। एक्सट्रीम प्रोग्रामिंग एक्सप्लेन्ड (Extreme Programming Explained) के दूसरे संस्करण में एक नया मूल्य जोड़ा गया। ये पांच मूल्य हैं: संवाद सॉफ्टवेयर सिस्टम का निर्माण करने के लिये सिस्टम के विकासकर्ताओं तक सिस्टम की आवश्यकताओं का संप्रेषण करना आवश्यक होता है। औपचारिक सॉफ्टवेयर विकास कार्यप्रणालियों में, यह कार्य दस्तावेजीकरण के द्वारा किया जाता है। एक्सट्रीम प्रोग्रामिंग तकनीकों को विकास-दल के सदस्यों के बीच संस्थागत ज्ञान का निर्माण व प्रचार तीव्र गति से करने की विधियों के रूप में देखा जा सकता है। इसका लक्ष्य सभी विकासकर्ताओं को सिस्टम का एक साझा दृश्य प्रदान करना होता है, जो कि सिस्टम के प्रयोक्ता द्वारा सोचे गये दृश्य से मेल खाता हो। इस छोर पर, एक्सट्रीम प्रोग्रामिंग सरल डिज़ाइनों, आम लक्षणों, प्रयोक्ताओं व प्रोग्रामरों के आपसी सहयोग, नियमित मौखिक संवाद और फीडबैक का समर्थन करती है। सरलता एक्सट्रीम प्रोग्रामिंग सबसे सरल समाधान के साथ शुरुआत करने को प्रोत्साहित करती है। अतिरिक्त कार्यात्मकता बाद में जोड़ी जा सकती है। इस विधि और सिस्टम विकास की अधिक पारंपरिक विधियों के बीच अंतर यह है कि इसमें कल, अगले सप्ताह, या अगले माह की आवश्यकताओं के बजाय आज की आवश्यकताओं के लिये डिज़ाइनिंग व कोडिंग करने पर ध्यान केंद्रित किया जाता है। कभी-कभी संक्षेप में इसे "आपको इसकी आवश्यकता नहीं पड़ने वाली है (you ain't gonna need it)" (यैग्नी) (YAGNI) पद्धति कहा जाता है।क्लेयर ट्रिस्टरम द्वारा "एवरीवन'स अ प्रोग्रामर" प्रौद्योगिकी की समीक्षा, 2003 नवम्बर पृष्ठ 39 एक्सपी (XP) के समर्थक इस कमी को मानते हैं कि कभी-कभी इसके कारण भविष्य में सिस्टम में परिवर्तन करने के लिये अधिक प्रयास करना पड़ सकता है; उनका तर्क यह है कि इस कमी की पूर्ति इस लाभ के द्वारा हो जाती है कि हमें उन भावी आवश्यकताओं में निवेश नहीं करना पड़ता, जो प्रासंगिक बन पाने से पूर्व परिवर्तित हो सकती हैं। भविष्य की अनिश्चित आवश्यकताओं के लिये कोडिंग और डिज़ाइनिंग करने में इस बात का खतरा रहता है कि ऐसी बात के लिये अपने संसाधन खर्च किये जा रहे हैं, जिसकी आवश्यकता शायद न भी पड़े. "संवाद" मूल्य के संबंध में, डिज़ाइन और कोडिंग की सरलता से संवाद की गुणवत्ता में सुधार होना चाहिये। बहुत ही सरल कोड के साथ एक सरल डिज़ाइन को दल के अधिकांश प्रोग्रामरों द्वारा सरलता से समझा जा सकता है। फीडबैक एक्सट्रीम प्रोग्रामिंग के अंतर्गत, फीडबैक सिस्टम विकास के विभिन्न आयामों से संबंधित होता है: सिस्टम से फीडबैक: परिवर्तनों को लागू करने के बाद ईकाई परीक्षण लिखकर, या आवधिक एकीकरण परीक्षणों को क्रियान्वित करके प्रोग्रामर सिस्टम की अवस्था के बारे में प्रत्यक्ष फीडबैक प्राप्त करते हैं। उपभोक्ता से फीडबैक: कार्यात्मक परीक्षण (जिन्हें स्वीकृति परीक्षण भी कहा जाता है) उपभोक्ताओं तथा परीक्षणकर्ताओं द्वारा लिखे जाते हैं। उन्हें अपने सिस्टम की अवस्था के बारे में मज़बूत फीडबैक मिल जाएगा. यह समीक्षा प्रत्येक दो या तीन सप्ताहों में नियोजित की जाती है, तकि उपभोक्ता सरलतापूर्वक विकास को संचालित कर सके। टीम से फीडबैक: नियोजन खेल में जब उपभोक्ता नई आवश्यकताएं लेकर आते हैं, तो टीम सीधे ही इस बात का एक अनुमान बता सकती है कि इन्हें लागू कर पाने में लगभग कितना समय लगेगा। संवाद और सरलता के साथ फीडबैक का निकट संबंध होता है। सिस्टम में उपस्थित दोषों को एक ऐसा ईकाई परीक्षण लिखकर सरलता से संप्रेषित किया जा सकता है, जो यह साबित करता हो कि कोड का विशिष्ट भाग टूट जाएगा. सिस्टम से मिलने वाले प्रत्यक्ष फीडबैक से प्रोग्रामरों को यह पता चलता है कि इस भाग की कोडिंग पुनः करनी है। समय-समय पर उपभोक्ता कार्यात्मक आवश्यकताओं के अनुसार सिस्टम का परीक्षण कर पाने में सक्षम होता है, जिन्हें प्रयोक्ता कथाएं (User Stories) कहते हैं। केंट बेक के शब्दों में, "आशावादिता प्रोग्रामिंग का एक व्यावसायिक जोखिम है और फीडबैक उसका उपचार है।"June 2007 courage साहस अनेक पद्धतियों में साहस सम्मिलित होता है। इनमें से एक यह नियम है कि डिज़ाइनिंग और कोडिंग सदैव ही आज के लिये करनी चाहिये, न कि आने वाले कल के लिये। यह डिज़ाइन में फंसकर उलझ जाने और कुछ और क्रियान्वित करने के लिये अत्यधिक प्रयास करने की आवश्यकता से बचने का प्रयास है। साहस विकासकर्ताओं को आवश्यकता के अनुसार अपने कोड की पुनर्रचना के कार्य के दौरान सहज महसूस कर पाने में सक्षम बनाता है। इसका अर्थ है, वर्तमान सिस्टम की समीक्षा करना और उसे संशोधित करना, ताकि भावी परिवर्तनों को अधिक सरलतापूर्वक लागू किया जा सके। साहस का एक अन्य उदाहरण इस बाद को जानना है कि कोड को कब हटा देना है: अनुपयोगी स्रोत कोड को हटाने का साहस, भले ही उस स्रोत कोड के निर्माण में चाहे कितनी ही ज्यादा मेहनत क्यों न लगी हो। साथ ही साहस का अर्थ दृढ़ता भी है: हो सकता है कि कोई प्रोग्रामर पूरे दिन किसी एक जटिल समस्या में फंसा रहे और दूसरे दिन वह इसे बहुत जल्दी सुलझा ले, लेकिन यह केवल तभी संभव है, जब वह दृढ़ हो। सम्मान सम्मान मूल्य में दूसरों के लिये सम्मान के साथ ही आत्म-सम्मान भी शामिल होता है। प्रोग्रामरों को कभी भी ऐसे परिवर्तन नहीं करने चाहिये, जो कम्पाइलेशन को तोड़ दें, जो वर्तमान ईकाई-परीक्षणों को विफल बना दें, अथवा जो अन्यथा अपने सहकर्मियों के कार्य को विलंबित कर दें। सदैव उच्च गुणवत्ता का प्रयास करके और उपलब्ध समाधान के लिये पुनर्रचना के द्वारा सर्वश्रेष्ठ डिज़ाइन बनाने का प्रयास करके सदस्य अपने स्वयं के कार्य का सम्मान करते हैं। पिछले चार मूल्यों को अपनाने के परिणामस्वरूप टीम के अन्य सदस्यों की ओर से सम्मान प्राप्त होता है। टीम के किसी सदस्य को यह महसूस नहीं होना चाहिये कि उसकी प्रशंसा नहीं की जाती या उसकी उपेक्षा की जा रही है। इससे प्रेरणा का एक उच्च स्तर सुनिश्चित होता है और यह टीम के प्रति और परियोजना के लक्ष्य के प्रति वफादारी को प्रोत्साहित करती है। यह मूल्य अन्य मूल्यों पर अत्यधिक निर्भर होता है और टीम के लोगों की ओर बहुत अधिक अभिमुख होता है। नियम एक्सपी (XP) के नियमों का पहला संस्करण केन ऑयर द्वाराhttp://www.rolemodelsoftware.com/moreAboutUs/publications/rulesOfXp.php केन एयुर 11 अगस्त 2010 https://web.archive.org/web/20080920062925/http://www.rolemodelsoftware.com/moreAboutUs/publications/rulesOfXp.php 20 सितंबर 2008 dead एक्सपी/एजाइल यूनिवर्स 2003 में प्रस्तावित किया गया था। उन्होंने यह महसूस किया कि एक्सपी (XP) को इसके नियमों के द्वारा परिभाषित किया गया था, न कि इसकी पद्धतियों के द्वारा (जिनमें अधिक भिन्नता और अस्पष्टता होती है)। उन्होंने दो श्रेणियां परिभाषित कीं: "कार्य के नियम", जो उस वातावरण का वर्णन करते हैं, जिसमें सॉफ्टवेयर विकास का कार्य प्रभावी रूप से किया जा सकता हो, तथा "खेल के नियम", जो कार्य के नियमों के ढांचे के अंतर्गत मिनट-दर-मिनट की जाने वाली गतिविधियों तथा नियमों को परिभाषित करते हैं। आईसीएसई 2008 सम्मेलन (ICSE 2008 Conference) की एप्सो कार्यशाला (APSO Workshop) में, मेहदी मिराखोरली ने एक्सट्रीम प्रोग्रामिंग का एक नया और अधिक स्पष्ट व विशद संस्करण प्रस्तावित किया, जो कि पद्धतियों से अधिक स्वतंत्र था और जिसका अधिक "तीव्र" होना अभीष्ट था। कार्य के नियम मेहदी मिराखोरली के अनुसार, ये हैं:June 2009 व्यापार से जुड़े लोग और विकासकर्ता संयुक्त रूप से कार्य करते हैं: व्यापार से जुड़े लोग और विकासकर्ताओं को पूरी परियोजना के दौरान प्रतिदिन एक साथ कार्य करना चाहिये। उपभोक्ता की संतुष्टि हमारी सर्वोच्च प्राथमिकता है: विकासकर्ताओं तथा टीम के अन्य सदस्यों द्वारा प्रदान की गए आकलनों और अन्य जानकारी के आधार पर उपभोक्ता को अनिवार्य रूप से अपने उद्देश्य और प्राथमिकताएं निर्धारित करनी चाहिये और उन्हें नियमित रूप से समायोजित करते रहना चाहिये। उद्देश्यों को इस रूप में परिभाषित किया जाता है कि क्या करना है, न कि कैसे करना है। कार्यशील सॉफ्टवेयर लगातार सौंपना चाहिये: कार्यशील सॉफ्टवेयर नियमित रूप से, दो सप्ताह से दो माह तक के अंतरालों पर, सौंपना चाहिये और इसमें छोटे समय-माप को प्राथमिकता दी जानी चाहिये (टाइमबॉक्सिंग)। कार्यशील सॉफ्टवेयर: कार्यशील सॉफ्टवेयर प्रगति का प्राथमिक माप होता है। वैश्विक जागरूकता: किसी भी बिंदु पर, टीम का कोई भी सदस्य उपभोक्ता के उद्देश्यों की ओर टीम की प्रगति का मापन कर पाने में सक्षम होना चाहिये और टीम यह प्रतिबिंबित करती है कि किस प्रकार अधिक प्रभावी बनना है और इसके अनुसार अपने व्यवहार में सुधार लाती है। टीम को अनिवार्य रूप से एक प्रभावी सामाजिक नेटवर्क के रूप में कार्य करना चाहिये, जिसका अर्थ है: दस्तावेजीकरण के बजाय ईमानदार संवाद, जिसके परिणामस्वरूप लगातार सीखने और व्यक्ति-से-व्यक्ति के बीच अंतःक्रिया पर बल दिया जाता है। प्रगति करने के लिये टीम को जिस बात की आवश्यकता हो और उन आवश्यकताओं की पूर्ति करने के लिये जिन लोगों/संसाधनों की आवश्यकता हो, उनसे न्यूनतम पृथकता. अधिकार और ज़िम्मेदारी का संरेखण. सिद्धांत जो सिद्धांत एक्सपी (XP) का आधार बनाते हैं, वे अभी-अभी वर्णित मूल्यों पर आधारित होते हैं और उनका उद्देश्य एक सिस्टम विकास परियोजना में निर्णयों को प्रोत्साहित करना होता है। सिद्धांत मूल्यों से अधिक दृढ़ होने चाहिये और किसी व्यावहारिक परिस्थिति में वे अधिक सरलता से एक मार्गदर्शन में अनुवादित होने चाहिये। फीडबैक एक्सट्रीम प्रोग्रामिंग में फीडबैक को सर्वाधिक उपयोगी माना जाता है, यदि इसे तीव्रता से किया गया हो और यह इस बात को व्यक्त करता हो कि किसी कार्य और इसके फीडबैक के बीच का समय सीखने और परिवर्तन करने के लिये बहुत अधिक महत्वपूर्ण होता है। पारंपरिक सिस्टम विकास विधियों के विपरीत, उपभोक्ता के साथ कम अवधि वाले चक्रों में बार-बार संपर्क किया जाता है। विकसित किये जा रहे सिस्टम के बारे में उपभोक्ता के पास एक स्पष्ट अंतर्दृष्टि होती है। वह अपना फीडबैक दे सकता है और आवश्यकता के अनुसार विकास को संचालित भी कर सकता है। ईकाई परीक्षण भी तीव्र फीडबैक सिद्धांत के प्रति सहायक होते हैं। कोड लिखते समय, ईकाई परीक्षण इस बारे में प्रत्यक्ष फीडबैक प्रदान करता है कि एक बार परिवर्तन कर दिये जाने पर सिस्टम इनके प्रति किस प्रकार की प्रतिक्रिया देता है। उदाहरणार्थ, यदि परिवर्तन सिस्टम के किसी ऐसे भाग को प्रभावित करते हों, जो उन्हें बनाने वाले प्रोग्रामर के दायरे में नहीं आता, तो वह प्रोग्रामर उस दोष को नहीं देख सकेगा। इस बात की बहुत अधिक संभावना है कि जब सिस्टम का उत्पादन किया जायेगा, तो उस समय यह त्रुटि उपस्थित होगी। सरलता की कल्पना करना इसके अंतर्गत प्रत्येक समस्या के साथ यह मानकर कार्य किया जाता है कि वह "अत्यधिक सरल" है। पारंपरिक सिस्टम विकास विधियां भविष्य के लिये नियोजन करने और पुनर्प्रयोग के लिये कोड लिखने को कहतीं हैं। एक्सट्रीम प्रोग्रामिंग इन विचारों को अस्वीकार करती है। एक्सट्रीम प्रोग्रामिंग के समर्थक कहते हैं कि बड़े परिवर्तन एक ही बार में एक साथ करना उपयुक्त नहीं होता। एक्सट्रीम प्रोग्रामिंग वृद्धिशील परिवर्तनों को लागू करती है: उदाहरण के लिये, प्रत्येक तीन सप्ताह बाद किसी सिस्टम के छोटे संस्करण को रिलीज़ किया जा सकता है। जब अनेक छोटे-छोटे कदम बनाये जाते हैं, तो उपभोक्ता के पास विकास प्रक्रिया का और विकसित किये जा रहे सिस्टम का अधिक नियंत्रण होता है। परिवर्तन को स्वीकार करना परिवर्तन को अपनाने का सिद्धांत परिवर्तनों के विपरीत काम न करने और उन्हें स्वीकार करने से संबंधित है। उदाहरण के लिये, यदि चरणबद्ध बैठकों में से किसी एक के दौरान यह दिखाई दे कि उपभोक्ता की आवश्यकताएं नाटकीय रूप से बदल गईं हैं, तो प्रोग्रामर इसे स्वीकार करते हैं और अगले चरण के लिये नई आवश्यकताओं की योजना बनाते हैं। पद्धतियां Extreme programming practices एक्सट्रीम प्रोग्रामिंग में 12 पद्धतियों का वर्णन किया गया है, जो चार क्षेत्रों में समूहबद्ध की गईं हैं: अच्छे पैमाने पर फीडबैक युग्म प्रोग्रामिंग नियोजन खेल परीक्षण-चालित विकास संपूर्ण टीम सतत प्रक्रिया लगातार एकीकरण पुनर्रचना या डिज़ाइन में सुधार छोटे रिलीज साझा समझ कोडिंग मानक कोड का सामूहिक स्वामित्व सरल डिज़ाइन सिस्टम रूपक प्रोग्रामर का कल्याण दीर्घकालिक गति कोडिंग उपभोक्ता सदैव उपलब्ध होता है ईकाई परीक्षण की कोडिंग पहले करें एक समय पर केवल एक ही युग्म कोड का एकीकरण करता है इष्टतमीकरण को अंत तक छोड़ दें कोई अतिरिक्त समय नहीं परीक्षण समस्त कोड का ईकाई परीक्षण होना अनिवार्य है रिलीज़ किये जाने से पूर्व पूरे कोड को ईकाई परीक्षणों में सफल होना चाहिये। जब किसी बग (Bug) का पता चलता है, तो उस बग को सुधारने से पूर्व परीक्षण निर्मित किये जाते हैं (बग तर्क में कोई त्रुटि नहीं है, बल्कि यह ऐसा परीक्षण होता है, जिसे लिखना आप भूल गये हों) स्वीकृति परीक्षण अक्सर क्रियान्वित किये जाते हैं और उनके परिणाम प्रकाशित किये जाते हैं विवादास्पद पहलू एक्सपी (XP) की पद्धतियों पर अत्यधिक विवाद होता रहा है, जिसमें एक्सपी (XP) के प्रयोग के समर्थन और विरोध में कठोर विचार व्यक्त हुए हैं। एक्सट्रीम प्रोग्रामिंग के समर्थकों का दावा है कि उपभोक्ता की आवश्यकताओं में परिवर्तन के निवेदन अनौपचारिक रूप से कार्य-स्थल पर ही प्राप्त हो जाने के कारण यह प्रक्रिया अधिक लचीली बनती है और इसके कारण औपचारिक खर्च की लागत बचती है। एक्सपी (XP) के आलोचक दावा करते हैं कि इसके परिणामस्वरूप दोबारा कार्य करना महंगा पड़ सकता है और धीरे-धीरे परियोजना का दायरा उस सीमा से बाहर चला जाता है, जिस पर पूर्व में सहमति बनी थी या जिसके लिये धन दिया गया था। परिवर्तन नियंत्रण बोर्ड इस बात का संकेत हैं कि परियोजना के उद्देश्यों और बाधाओं के बारे में अनेक प्रयोक्ताओं के बीच टकराव संभावित हैं। एक्सपी (XP) की तीव्र कार्यप्रणाली कुछ हद तक इस बात पर निर्भर होती है कि प्रोग्रामर उपभोक्ता के एक एकीकृत दृष्टिकोण की कल्पना कर पाने में सक्षम हों, ताकि प्रोग्रामर समझौते के उद्देश्यों और बाधाओं के दस्तावेजीकरण के बजाय अपना ध्यान कोडिंग पर केंद्रित कर सकें. यह बात तब भी लागू होती है, जब अनेक कोडिंग संगठन शामिल हों, विशिष्ट रूप से ऐसे संगठन, जिनके बीच परियोजनाओं के अंश को लेकर प्रतिस्पर्धा जारी हो। July 2008 एक्सट्रीम प्रोग्रामिंग के संभावित रूप से विवादास्पद अन्य पहलुओं में शामिल हैं: आवश्यकताओं को विनिर्देशन दस्तावेजों के बजाय स्वचालित स्वीकृति परीक्षणों के रूप में व्यक्त किया जाता है। सभी आवश्यकताएं पहले से ही प्राप्त करने का प्रयास करने के बजाय आवश्यकताओं को वृद्धिशील रूप से परिभाषित किया जाता है। आमतौर पर सॉफ्टवेयर विकासकर्ताओं को जोड़ियां बनाकर कार्य करना पड़ता है। इसमें कोई बिग डिज़ाइन अप फ्रंट (Big Design Up Front) नहीं होता। अधिकांश डिज़ाइन गतिविधि आवश्यकतानुसार तथा वृद्धिशील रूप से की जाती है, जिसकी शुरुआत "उस सरलतम वस्तु के साथ होती है, जो संभवतः कार्यशील होगी" और इसके बाद जटिलता केवल तभी जोड़ी जाती है, जब विफल परीक्षणों के कारण इसकी आवश्यकता हो। आलोचक इसकी तुलना "प्रदर्शन में सिस्टम की त्रुटियों को दूर करने" से करते हैं और उन्हें भय है कि इसके परिणामस्वरूप पुनर्रचना करने में केवल आवश्यकताओं में परिवर्तन होने पर ही पुनर्रचना करने के लिये लगने वाले प्रयास से अधिक पुनर्रचना प्रयास की आवश्यकता होती है। परियोजना के साथ एक उपभोक्ता प्रतिनिधि संलग्न कर दिया जाता है। यह भूमिका परियोजना के लिये विफलता-का-एकल-बिंदु बन सकती है और कुछ लोगों ने पाया है कि यह तनाव का एक स्रोत है। साथ ही, यदि कोई गैर-तकनीकी प्रतिनिधि तकनीकी सॉफ्टवेयर विशेषताओं तथा संरचना के प्रयोग को संचालित करने का प्रयास करे, तो इसमें सूक्ष्म-प्रबंधन का खतरा भी होता है। एक्सपी (XP) के अन्य सभी पहलुओं पर निर्भरता: "एक्सपी (XP) जहरीले सर्पों के एक चक्र के समान है, जो एक दूसरे साथ डेज़ी-पुष्प जैसी एक संरचना के द्वारा जुड़े होते हैं। यदि इनमें से केवल कोई एक भी मुक्त होने के लिये छटपटाने लगे, तो आपको एक अत्यंत क्रोधित, जहरीला सांप आपकी ओर आता हुआ मिलता है।http://www.softwarereality.com/lifecycle/xp/safety_net.jsp एक्सट्रीम प्रोग्रामिंग के खिलाफ प्रकरण: एक आत्म रेफरेंशीयल सेफ्टी नेट 11 अगस्त 2010 https://web.archive.org/web/20100330012643/http://www.softwarereality.com/lifecycle/xp/safety_net.jsp 30 मार्च 2010 dead मापनीयता ऐतिहासिक रूप से, एक्सपी (XP) केवल बारह या इससे कम लोगों के समूहों में कार्य करता है। परियोजना को छोटे भागों में तोड़ना और फिर छोटे समूहों में टीम बनाना इस सीमा को धोखा देने का एक उपाय है। यह दावा किया जाता रहा है कि एक्सपी (XP) का प्रयोग सौ से भी अधिक सदस्यों के समूहों पर सफलतापूर्वक किया जाता रहा है। फ़रवरी 2007 थॉटवर्क्स (ThoughtWorks) ने दावा किया है कि उन्होंने वितरित एक्सपी (XP) परियोजनाओं पर साठ लोगों तक की संख्या वाले समूहों के साथ कार्य करके पर्याप्त सफलता पाई है।August 2009 2004 में, इंडस्ट्रियल एक्सट्रीम प्रोग्रामिंग (Industrial Extreme Programming) (आईएक्सपी) (IXP)http://www.cutter.com/content-and-analysis/resource-centers/agile-project-management/sample-our-research/apmr0502.html कटर कंसोर्टियम: औद्योगिक XP:बड़े कार्य संगठन में XP का काम करना 11 अगस्त 2010 https://web.archive.org/web/20100710010534/http://www.cutter.com/content-and-analysis/resource-centers/agile-project-management/sample-our-research/apmr0502.html 10 जुलाई 2010 dead को एक्सपी (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) की कम्प्यूटर प्रोग्रामिंग कार्यप्रणालियों के साथ संयोजित करने का प्रयास किया है। उन्होंने पाया कि इन तीनों प्रणालियों ने एक दूसरे को बहुत अच्छी तरह सहारा दिया, जिसका परिणाम बेहतर विकास के रूप में मिला और इनके बीच कोई आपसी टकराव नहीं है।एक्सट्रीम प्रोग्रामिंग (XP) सिक्स सिग्मा CMMI https://web.archive.org/web/20110101021405/http://www.sei.cmu.edu/library/assets/jarvis-gristock.pdf 1 जनवरी 2011 . आलोचना एक्सट्रीम प्रोग्रामिंग के प्रारंभिक रोमांच और विवादास्पद सिद्धांतों, जैसे युग्म प्रोग्रामिंग और सतत डिज़ाइन, ने विशिष्ट आलोचना को आकर्षित किया है, जैसे मैकब्रीन (McBreen)McBreen P. Questioning Extreme Programming https://archive.org/details/questioningextre0000mcbr Addison-Wesley Boston, MA 2003 0-201-84457-5 तथा बोहेम व टर्नरBoehm B. Barry Boehm R. Turner Balancing Agility and Discipline: A Guide for the Perplexed https://archive.org/details/balancingagility0000boeh Addison-Wesley Boston, MA 2004 0-321-18612-5 की ओर से आने वाली आलोचना. हालांकि, एजाइल (Agile) पद्धतियों के प्रयोक्ताओं का विश्वास है कि इनमें से अधिकांश आलोचनाओं का कारण तीव्र विकास की गलत समझ है।http://www.sdmagazine.com/documents/s=1811/sdm0112h/0112h.htm सडमैगज़ीन 11 अगस्त 2010 https://web.archive.org/web/20060316100811/http://www.sdmagazine.com/documents/s%3D1811/sdm0112h/0112h.htm 16 मार्च 2006 live विशिष्ट रूप से, एक्सट्रीम प्रोग्रामिंग की समीक्षा और आलोचना मैट स्टीफेंस और डफ रॉसेनबर्ग की एक्सट्रीम प्रोग्रामिंग रिफैक्टर्ड (Extreme Programming Refactored) द्वारा की गई है।एक्सट्रीम प्रोग्रामिंग रिफैक्टर्ड https://web.archive.org/web/20100208105400/http://www.softwarereality.com/ExtremeProgrammingRefactored.jsp 8 फ़रवरी 2010 , मैट स्टेफंस और डौग रोसेंबर्ग, प्रकाशक: अप्रेस एल.पी. आलोचनाओं में शामिल हैं: एक कार्यप्रणाली केवल उतनी ही प्रभावी होती है, जितना कि उसमें शामिल लोग, एजाइल (Agile) इसे नहीं सुलझा सकता अक्सर इसका प्रयोग प्रदेय उत्पाद की परिभाषा में कमी के माध्यम से धन की उगाही करने के एक साधन के रूप में किया जाता है संरचना और आवश्यक दस्तावेजीकरण की कमी केवल वरिष्ठ-स्तर के विकासकर्ताओं के साथ ही कार्य करता है इसमें अपर्याप्त सॉफ्टवेयर डिज़ाइन शामिल होता है इसमें बहुत छोटे अंतरालों पर बार-बार बैठकें करने की आवश्यकता पड़ती है, जिससे उपभोक्ता का खर्च अत्यधिक बढ़ जाता है बहुत अधिक सांस्कृतिक परिवर्तन को अपनाना आवश्यक होता है इसके परिणामस्वरूप अनुबंधात्मक समझौते अधिक कठिन हो सकते हैं बहुत अधिक अदक्ष हो सकता है-यदि कोड के एक क्षेत्र की आवश्यकताएं विभिन्न दोहरावों के माध्यम से बदलती हैं, तो एक ही प्रोग्रामिंग को अनेक बार दोहराने की आवश्यकता पड़ सकती है। जबकि यदि एक योजना बनाकर उसका पालन करते हुए कार्य किया जाए, तो कोड के किसी एक क्षेत्र को केवल एक ही बार लिखना अपेक्षित होता है। एक अनुमान प्रदान करने के लिये आवश्यक कार्य-प्रयास का एक वास्तविकतापूर्ण आकलन विकसित कर पाना असंभव होता है क्योंकि परियोजना की शुरुआत में किसी को भी पूरे दायरे/आवश्यकताओं की जानकारी नहीं होती विस्तृत दस्तावेज़ीकरण आवश्यकताओं की कमी के कारण दायरे से बाहर निकल जाने का खतरा बढ़ सकता है एजाइल (Agile) विशेषता संचालित होता है; गैर-कार्यात्मक गुणवत्ता विशेषताओं को प्रयोक्ता कथाओं (User Stories) के रूप में रख पाना कठिन होता है इसे भी देखें सॉफ्टवेयर इंजीनियरिंग सॉफ्टवेयर क्राफ्टमेनशिप फुर्तीली सॉफ्टवेयर विकास एक्सट्रीम परियोजना प्रबंधन एक्सट्रीम प्रोग्रामिंग प्रथाओं पेयर प्रोग्रामिंग RDP तकनीक काई ज़ेन सॉफ्टवेयर विकास चिंतनों की सूची स्क्रम (विकास) सन्दर्भ आगे पढ़ें केन औएर और रॉय मिलर. एक्सट्रीम प्रोग्रामिंग: एप्लाइड: प्लेयिंग टू विन, एडिसन-वेस्ले. कैंट बेक: एक्सट्रीम प्रोग्रामिंग एक्स्प्लेंड: एम्बरेस चेंज, एडिसन-वेस्ले. कैंट बेक और मार्टिन फोव्लर: प्लैनिंग एक्सट्रीम प्रोग्रामिंग, एडिसन-वेस्ले. कैंट बेक और सिंथिया एन्ड्रेस. एक्सट्रीम प्रोग्रामिंग एक्स्प्लेंड: एम्बरेस चेंज, सेकेण्ड एडिशन, एडिसन-वेस्ले. एलिस्टेयर कॉकबर्न: एजाइल सॉफ्टवेयर डेवेलपमेंट, एडिसन-वेस्ले. मार्टिन फोव्लर: रिफैक्टरिंग: इम्प्रूविंग द डिज़ाइन ऑफ़ एक्ज़ीस्टिंग कोड, एडिसन-वेस्ले. हार्वे हेरेला (2005)। प्रकरण अध्ययन: क्रिसलर व्यापक मुआवजा प्रणाली. ग्लेन लैब, यु.सी. आयर्विन. जिम हाईस्मिथ. एजाइल सॉफ्टवेयर डेवेलपमेंट इकोसिस्टम्स, एडिसन-वेस्ले. रॉन जेफ्रिस, एन एंडरसन और चेट हेंड्रिकसन (2000), एक्सट्रीम प्रोग्रामिंग इन्स्टॉल्ड, एडिसन-वेस्ले. मेहदी मिराखोरली (2008)। आरडिपी (RDP) तकनीक: अ प्रैक्टिस टू कस्टमाइज़ एक्सपी, सोफ्टवेयर इंजीनियरिंग पर इंटरनैशनल कॉन्फेरेन्स, प्रोसीडिंग्स ऑफ़ द 2008 इंटरनैशनल वर्कशॉप ऑन स्क्रुटीनाइज़िन्ग एजाइल प्रैक्टिस ऑर शूट-आउट ऐट द एजाइल कोरल, लिपजिंग, जर्मनी 2008, पेजेस 23-32. क्रेग लार्मन और वी. बसिली (2003)। "इटिरेटिव एण्ड इन्क्रेमेंटल डेवेलपमेंट: अ ब्रीफ हिस्ट्री", कंप्यूटर (IEEE कम्प्यूटर सोसायटी) 36 (6): 47-56. मैट स्टेफंस और डॉ रोसेंबर्ग (2003)। एक्सट्रीम प्रोग्रामिंग रिफैक्टर्ड: द केस अगेंस्ट XP, अप्रेस. वाल्डनर, जेबी. (2008)। "नैनोकम्प्यूटर्स और स्वार्म इंटेलीजेंस". इन: ISTE, 225-256. बाहरी कड़ियाँ Extreme Programming एक्सट्रीम प्रोग्रामिंग एक सज्जन परिचय औद्योगिक एक्सट्रीम प्रोग्रामिंग XP पत्रिका XP कार्यान्वयन के लिए समस्याएं और समाधान सॉफ्टवेयर विकास प्रक्रिया के साथ अपतटीय चंचल का उपयोग - थॉटवर्क्स एक्स्पिरियंसेस विथ इम्प्लीमेंटिंग XP इन लार्ज डिस्ट्रीब्युटेड प्रोजेक्ट्स श्रेणी:एक्सट्रीम प्रोग्रामिंग श्रेणी:सॉफ्टवेयर विकास के दर्शन श्रेणी:एजाइल सॉफ्टवेयर विकास श्रेणी:गूगल परियोजना