Extreme Programming is one of many Agile Processes. It is also known as XP. The names AthlonXP and WindowsXP would appear not to be related to Extreme Programming, but if interested, you could see the Windows Xp Name Discussion.
See Extreme Programming Roadmap for an index of information about extreme programming on this site.
The basic advantage of XP is that the whole process is visible and accountable. The developers will make concrete commitments about what they will accomplish, show concrete progress in the form of deployable software, and when a milestone is reached they will describe exactly what they did and how and why that differed from the plan. This allows business-oriented people to make their own business commitments with confidence, to take advantage of opportunities as they arise, and eliminate dead-ends quickly and cheaply. -- Kent Beck
"XP is the practice and pursuit of effective simplicity, as applied to software development." -- Victor (from the Xp Mailing List)
Extreme Programming was best described by Kent Beck in his landmark book <i>Extreme Programming Explained Embrace Change</i> (take a quick look at that page for a 'back-cover' summary of XP).
This One Trick Pony ain't no Silver Bullet. And vice versa. -- Phl Ip
Interesting to note that Extreme Programming has emerged as a methodology for programming; it appears to be based in trial and error programming! Without tests and refactoring, it is not workable at all. So why not design first, write tests to that design, then program, test, perform refactoring and iterate?
That's exactly what Extreme Programming is, friend. Just do it in tiny increments.
The differences between XP and trial-and-error are basically two-fold: first, you solve each error as it comes up, so that it doesn't compound with later errors. And second, you meant to do it that way in the first place, rather than being forced to come back and deal with unforeseen complications. <i>(This paragraph would need to be written out more verbosely. I can't understand the point the paragraph is trying to make. Please Comment)</i> this looks like a development of Stepwise Refinement where the project is broken down into smaller and smaller tasks until each task is small enough to code, the idea being that one task is one module to handle an operation ie input:process:output if a task is too big to code, its split into modules. these modules are iterated to the same criteria
The Extreme Programming Core Practices constitute an Extreme Programming Project.
Why "Extreme"?
"Extreme" means these practices get "turned up" to a much higher "volume" than on traditional projects. XP ignores any other practice (like Big Design Up Front) that does not appear on the list. The result is stable, productive, and very rapid because the practices support each other the more they are used together without interference. An Extreme project is typically so stable and sedate it can lead to Forty Hour Week<b></b>s without any schedule slips.
What really matters?
Software is too damned hard to spend time on things that don't matter. So, starting over from scratch, what are we absolutely certain matters?
1. Coding. At the end of the day, if the program doesn't run and make money for the client, you haven't done anything. 1. Testing. You have to know when you're done. The tests tell you this. If you're smart, you'll write them first so you'll know the instant you're done. Otherwise, you're stuck thinking you maybe might be done, but knowing you're probably not, but you're not sure how close you are. 1. Listening. You have to learn what the problem is in the first place, then you have to learn what numbers to put in the tests. You probably won't know this yourself, so you have to get good at listening to clients - users, managers, and business people. 1. Designing. You have to take what your program tells you about how it wants to be structured and feed it back into the program. Otherwise, you'll sink under the weight of your own guesses.
Listening, Testing, Coding, Designing. That's all there is to software. Anyone who tells you different is selling something.
-- Kent Beck, author of Extreme Programming Explained
XP is designed to meet the Customer Bill Of Rights and Developer Bill Of Rights. Participants work in one of the Extreme Roles (The Coach, Tracker Role, etc.). XP is done during a Forty Hour Week, with All Engineers In One Room, having a daily Stand Up Meeting. As There Must Be Food, there are Snacks For Positive Reinforcement in the room where Engineering Task<b></b>s are carried out with a high Project Velocity. If you don't have this kind of ideal environment, you could still attempt Extreme Programming In Enemy Territory.
The Onsite Customer participates in the Planning Game. The development team interviews the customer to determine User Stories about how the system will work. User stories are combined or split to come up with a story that can be described (Write It Ona Card) on one of these Crc Card<b></b>s, and completed by a pair of programmers during one release cycle (typically about three weeks). The customer prioritizes the cards according to the business value of the User Stories, which puts stories into the release schedule based on the development resources available. This lets customers have an accurate Release Plan.
After each release, the customer has a system that works according to the stories completed so far; they don't have to wait for the whole thing to be done to start using the initial functionality. The development group identifies which stories are risky to complete on time (mainly because of a lack of experience with that type of coding) and does Worst Things First based on a Spike Solution. Read more about Extreme Requirements Gathering.
Special note on Listening: we do listening in two ways:
1. UserStories. (Similar to "use cases".) On cards, our customers write stories describing how something is supposed to work. A story might say "An employee making $10 an hour works four hours of overtime on Friday and two on Sunday. She should receive $60 for the Friday overtime and $40 for Sunday." We have hundreds of cards describing the product. 1. AcceptanceTest''''''s. These are typically single use cases with expected answers provided by the customer.
-- Ron Jeffries
XP relies on Test Driven Development for its inner loop. This pumps the outer loop, and makes the political end of XP possible. Promises are automatically kept. Programmer Tests are written which the successful software will be able to pass. At first, the tests fail because the software hasn't been written yet. A simple design is developed by doing the Simplest Thing which might pass the tests. Big Design Up Front is avoided because You Arent Gonna Need It. However, once the Simplest Thing is done the programmers Refactor Mercilessly, because in the end things should be expressed Once And Only Once. Read more about Subsystems In Xp.
XP involves pairs of programmers (who Pair Promiscuously) working together on code, so that the entire development team achieves Code Stewardship. They use Test Driven Development to Code Unit Test First.
This Pair Programming leads to Collective Code Ownership. Programmers follow the Coding Convention<b></b>s whenever they write new code, and while they Refactor Mercilessly.
After code passes Programmer Test<b></b>s (cf Relentless Testing), practice Continuous Integration (at The Integration Station) of Frequent Releases and run Acceptance Test<b></b>s to verify that the software meets the customer's requirements. No Bug Database is needed.
Several wikis describe/implement Web-based systems that support XP practices:
Noted Perl Language luminary, and mad scientist, Damian Conway believes that Extreme Programming is actually a misnomer. Since it embodies many of the good programming practises that programmers are taught but almost certainly ignore, he believes that it should really have been called Ultra Conservative Programming. -- Simon Law
<i>How is XP "best practices" different from other best practices lists? If you have Empirical Evidence beyond anecdotes, I would like to see the data!</i>
I do not have data to publish, but I've done several projects this way and it sure makes projects go faster, way faster, although programming goes slower. Think about that, it makes lots of sense, since you are programming only a 10% of the time.
And since there are so many practices, if you skip one, you will think you are going faster, then when you fail, you will realize you were not going as fast as you thought. Another way of saying it is that you were going fast, but in the wrong direction, or you were going fast but you hit a wall (it depends on which practice did you skip).
The last project I worked on, was achieved with half the estimated people and half the time. The quality was not so good because we skipped functional testing during the whole project. When everything was coded and seemeingly functioning with a lot of defects, we wrote functional tests for all user stories (full use cases in our case). It just took 2 months to completely stabilize the system of around 300 use cases.
XP is spreading like wildfire in the industry, which is good("change is good"). There is one big danger, people always misunderstand XP as jumping right into the code and getting the code out, and figure out what the code needs to do later. This is not leaving us in any better position than we are today. I wish XP gurus will advocate more on listening and understanding of the problem before trying to solve it. If you are advocating to understand the problem while (well) after writing the solution, then that is wrong and ought to be illegal.
I'm unconvinced of Extreme Programming's utility when it comes to the design and construction of platforms for other software (e.g. programming languages, frameworks, message protocols, library APIs, operating systems, security models, concurrency models, etc.) - too often, the need to maintain backwards compatibility, especially to support the 'quirks' and 'bugs' of previous modes, quickly becomes an enormous burden against any attempt to Refactor Mercilessly. However, I think it works fine for situations where the programmers DO possess full authority to muck around with all code and repair any dependencies broken as a consequence of refactoring. Big Design Up Front vs Yag Ni, Program In The Future Tense vs Do The Simplest Thing That Could Possibly Work - I believe that each have their place in design and construction of software.
Discussion moved to Extreme Programming For Platform Software.
I vote to drop the <i>Extreme</i> and <i>Ultra</i> things. I understand that is <i>swiftly</i> abbreviates to something like XP, but this is the future of programming. It is. So why name it like the next non-evolution of washing agents. To me, all I have read in Category Extreme Programming pages, <i>is</i> about programming. No more no less. Anything else than that doesn't <i>earn</i> the name programming with me, at most <i>coding</i>. -- Stijn Sanders
Simplified Process seems to have been an Extreme Programming-like practice from Germany Country.
Q: For "simple" programming language (e.g. CICS-COBOL/DB2) on Big Iron (e.g., ZOS) development projects, would XP practitioners agree that XP approach is not really suitable because
1 nobody benefits from PairProgramming with these environments (no reuse / pattern applicability discussions needed) 1 it's not realistic to have users participate in the team because enterprise tasks (e.g.. ERP integration) have organization-wide impact and are not suited for small but FrequentReleases 1 PairProgramming does not improve productivity as complexity is in the business and not in the technical environment 1 of inertia, and no one wants to be the first shop that does MainFrame development in XP. See also XpAndHierarchies.
-- David Liu
A: It may be arguable that XP would be difficult simply because it would be such a radical change from the existing practice and most people doing it have so much inertia/experience with their current approach. But two people could certainly pair and benefit from it without having to change the whole culture. The benefits would come precisely because the existing app is already mature and complex that it greatly helps to have two pair of eyes watching every change.
I have two junior programmers, fresh out of school, breaking out the UI from the business logic of a legacy app. They are buying into the value of pairing and writing tests. The old guard are stunned at how fast they are tearing through. Working together works. 8:-) -- Brad White
Language used for that Legacy Application?
Just considering the Extreme<i>Programming</i> aspect, this is exactly how programmers want to work, without necessarily knowing it. Coders like coding, not documenting, and coders like seeing code they've written work. I love it - no more huge Design Documentation, and rapid feedback from Programmer Tests. It makes programming fun again, like when you were a kid (or when you were hacking some Open Source piece where no one demands a 90-page design doc complete with full Unified Modeling Language models).
About documentation: I recently started to put my documentation (UML snippets, method signatures and other remarks) inside my unit tests. I must off course admit that that is easy to do in a web-oriented language (PHP in my case). I use a lot of shared components and these components usually have some idea behind them that can be expressed in UML nicely. I thought that the unit tests were the best place for the documentation, as you will see it a few times a day anyway. And you <i>really want</i> to see it when that particular unit tests breaks.
For a demo, see the tests at www.w-p.dds.nl 
-- Willem Bogaerts
Maybe not design docs but how about help docs? You have to document at some time, because it's how customers actually use those features that you thought up. It'd be selfish just to code and never document or comment on how the software works. But I'm sure you mean just reduction of design docs, right? Any documentation is tough for a programmer since he can never explain the software in less than ten words. More like ten thousand words. (I think you'll see Video Documentation in the future as more popular.. and it's easier to 'write up' for a programmer) (See User Docs In Xp)
See Extreme Programming Roadmap, Extreme Programming Principles, Extreme Programming Topics, Extreme Programming Links Outside Wiki, Extreme Programming For Dummies, Extreme Programming Projects, Who Is Using Extreme Programming, Extreme Programming Articles
<->
Extreme Open Business (is a generalization of Extreme Programming, applying experiences and principles to the Business Process. It is especially interesting for the Creative Commons.)
See original on c2.com