The Nuts and Bolts of eXtreme Programming (XP)
XP development practices are mostly counterintuitive. This can make it difficult for organizations to adopt them. Below are a list of some of the more counterintuitive aspects of XP development. These are grouped under 3 main headings:
Planning
User Stories
In XP, software requirements are communicated to development in the form of "User Stories" instead of large formal specification documents. These can be handwritten on index cards or an electronic form which can be easily shared (a must for distributed teams). User Stories are brief vignettes about what a user would experience when using a new functionality or feature. more
Project Velocity
One of the most challenging and mysterious aspects of software development is predicting when software will actually be done. The inability to forecast releasable software causes havoc with the marketing and sales machinery of a business and leads to a lot of external grumbling about that "&%$(*@! software development group". XP has an innovative way to mostly resolve this chronic problem. It can be summed up as "yesterday's weather." more
Development
Pair Programming
In XP, developers always work in pairs. They take turns at the keyboard, writing code, while other developer is watching over, checking for errors and keeping the bigger picture in mind. Intuitively, this might seem to be an inefficient.... more
Incremental Software Development
This first appears to be as counterintuitive as building a house one room at a time, without an overall blueprint.But unlike a house design, in many software projects the stakeholders don't really know what they want the software to look like or do when it is finally done. more
Frequent Small Iterations of Software
A development "cycle" in XP can be between 1 - 4 weeks, often 2 weeks for many projects. more
Test Driven Development
First write the tests, then write the code. That has to be one of the most counterintuitive of the XP practices.... more
Testing
Acceptance Testing
Code is not finished until the stakeholder representative agrees it is. more
Continuous Integration
It would seem that testing something each time you make a change would waste a lot of time and slow down the process. Isn't more important to get coding done as quickly as possible without delays or interruptions? more
