We are talking about an efficient, organized, and flexible way to design and implement software. This is relevant in the area of systems analysis and design techniques.
The "(XP)" at the end of Extreme Programming (XP) has nothing to do with the operating system Windows XP. In this case, the "XP" is an abbreviation for the term eXtreme Programming. It seems redundant, doesn't it?
Extreme Programming is not a type of programming language; it is a technique. Extreme Programming is a type of Agile Programming.
A methodology is simply a way of doing things, i.e., a technique. A methodology is an organized procedure to accomplish a task or goal.
The term "agile" means efficient, flexible, and adaptable.
The first part of this answer explains Agile Programming. The second part provides you with a description of Extreme Programming (XP). The first two paragraphs of each part give you a brief summary of the subject (concept). The remaining parts of each section further explain the concepts.
____________________________________________
_________________________________________________________________________
PART 1: AGILE PROGRAMMING
http://www.versionone.net/Resources/AgileDevelopment.asp
Note: See Part 2, Extreme Programming (XP), further below.
_________________________________________________________________________
Agile Development
What is Agile Development?
"Agile Development" is an general term (or category) for several iterative and incremental software development methodologies. The most popular agile methodologies include Extreme Programming (XP), Scrum, Crystal, Dynamic Systems Development Method (DSDM), Lean Development, and Feature-Driven Development (FDD).
Though each of the agile methods is unique in its specific approach, they all share a common vision and core values (see the Agile Manifesto: http://www.agilemanifesto.org/). They all fundamentally incorporate iteration and the continuous feedback that it provides to successively refine and deliver a software system. They all involve continuous planning, continuous testing, continuous integration, and other forms of continuous evolution of both the project and the software. They are all lightweight (especially compared to traditional waterfall-style processes), and inherently adaptable. As important, they all focus on empowering people to collaborate and make decisions together quickly and effectively.
The Evolution of Agile Development
Many of the individual principles and practices that are promoted by agile development have been around for years, even decades. As opposed to implementing these best practices piecemeal, agile methodologies have "packaged" various customer, management (and in some cases, engineering) practices and principles together in a way that helps guide teams through the process of rapidly planning and delivering working, tested software.
Each of the agile methodologies combines both old and new ideas into refinements that are certainly greater than the sums of their parts.
Though it is true that many of the practices associated with agile development have been around for quite some time, the average software development team has yet to embrace many of the principles and practices. Even today, the average software team does not iterate, does not deliver software incrementally, and does not practice continuous planning nor automate testing. Now that these practices have been combined in a manner that can more easily be understood and adopted, the trend appears to be rapidly changing for the better, especially during the last several years.
As with any new way of doing business though, agile methods have generated quite a bit of controversy within the software community. Yet since their emergence, in project after project, they have continued to deliver higher quality software systems in less time than traditional processes. If you are a software development professional, you definitely owe it to yourself to at least become familiar with the theory and practice of agile development. Hopefully the information presented on this site can assist.
__________________________________________________________________________
http://www.menloinnovations.com/method/agile.htm?gclid=CIOmnIeK3I0CFRnHEAodpAg9ZQ
If you want to build killer software applications then you must build an agile software team. Period. No debate. No excuses. It is that important.
An agile software development team can add features in any order and can release a working version of the product at any iteration. Agile teams learn to add features in the order that makes sense to the business.
Since features always get thrown overboard at the end of a project, a team interested in building a killer application must build and fully incorporate the most important features first. An agile team understands the real business trade-offs that are being made as each new feature is added.
An agile team is capable of releasing the software to end users every 10 business days. The business now has the opportunity to deploy to the user community the most recent features as frequently as every two weeks. Of course, most users don't want updates that fast.
They also present the release to real users for demonstrations, beta trials, and evaluations. They use real software to gain real feedback from real users. This feedback is often the difference between a mediocre product and a killer app.
The ability to have new releases come out every two weeks have additional benefits to the business as well. If the business is in a year long product development cycle, the business now has clear choices to make every two weeks. Options include continuing to add more features on the current plan, prioritizing the features differently, or to stop adding features altogether.
The business now can decide halfway through the year if all of the key features are present. They can stop development, ship the product, and save half of the development costs!
The ability to release a version of the product at each iteration also makes the developers far better software engineers. Issues such as integration and installation that previously were deferred to the end of a project must now be addressed consistently throughout the entire development lifecycle. Software built in this manner is of consistently higher quality.
_________________________________________________________________________
PART 2: EXTREME PROGRAMMING (XP)
http://www.versionone.net/Resources/AgileMethodologies.asp
_________________________________________________________________________
.
XP, originally described by Kent Beck, has emerged as one of the most popular and controversial agile methods. XP is a disciplined approach to delivering high-quality software quickly and continuously. It promotes high customer involvement, rapid feedback loops, continuous testing, continuous planning, and close teamwork to deliver working software at very frequent intervals, usually every 1–3 weeks.
--------
Don Wells has depicted the XP process in a popular diagram:
http://www.extremeprogramming.org/map/project.html.
In XP, the “Customer” works very closely with the development team to define and prioritize granular units of functionality referred to as "User Stories". The development team estimates, plans, and delivers the highest priority user stories in the form of working, tested software on an iteration by iteration basis. In order to maximize productivity, the practices provide a supportive, lightweight framework to guide a team and ensure high-quality software.
--------
The original XP recipe is based on four simple values—simplicity, communication, feedback, and courage—and twelve supporting practices:
1) Planning Game
2) Small Releases
3) Customer Acceptance Tests
4) Simple Design
5) Pair Programming
6) Test-Driven Development
7) Refactoring
8) Continuous Integration
9) Collective Code Ownership
10) Coding Standards
11) Metaphor
12) Sustainable Pace