Table Of Contents
Extreme Programming is a combination of simple, common-sense practices stressing communication, teamwork, requirements, and customer satisfaction. It is based on these values:
- Communication - in order to successfully create and deliver a software product on time, there must be constant and thorough communication between members of the development team.
- Feedback - Customer involvement and feedback are essential for customer satisfaction.
- Simplicity - XP stresses the need to keep things as simple as possible while meeting the requirements laid out for the project.
- Courage - Developers must have the courage and confidence to bring change and produce quality results.
Please consult the Resources section for the sources of the information in this article.
The concepts of XP require their own vocabulary. Whether one introduces the vocabulary first or the concepts first is always the issue. In this case, the concepts are introduced first with links to the vocabulary.
XP assumes that people work best in pairs so that they complement each other's strengths and weaknesses and so that knowledge can be spread between members of the team. The benefits as far as design, bug elimination, etc., can make two programmers at one computer be much more effective than they would be if they were each at separate computers. Here is an excerpt from a book report on The Costs and Benefits of Pair Programming (Laurie Williams & Alstair Cockburn), which talks about the benefits of pair programming.
Economics. A recent controlled experiment found only a small development cost for adding the second person. However, the resulting code also had fewer defects. The defect removal savings should more than offsets the development cost increase.
Satisfaction. People working in pairs found the experience more enjoyable than working alone.
Design quality. The study also found that the pairs produced shorter programs than their solo peers, indicating superior designs. Interviewees made the same comments.
Continuous Reviews. Pair programming's shoulder-to-shoulder technique serves as a continual design and code review, leading to most efficient defect removal rates.
Problem solving. Interview participants constantly refer to the team's ability to solve "impossible" problems faster.
Learning. Pair programmers repeatedly cite how much they learn from each other.
Team Building and Communication. Interview participants describe that people learn to discuss and work together. This improves team communication and effectiveness.
Staff and Project Management. Since multiple people have familiarity with each piece of code, pair programming reduces staff-loss risk.
Pairs and roles are changed often so that people can get the benefit of what each other has learned, and get a good feel for all the different areas of the system.
Weaknesses
This will not work for all programmers. It may be difficult to convince managers of the cost benefit. Also, it does not work where the programmers are working from a distance especially when time zones are an issue, however there are tools that can help this, such as http://www.gotomypc.com/ and other remote viewing/control software.
A project's requirements are laid out as individual stories. These stories have test cases. A test case includes the test and the desired results which, if met, indicate that that story is complete.
The project is done in iterations. At the end of an iteration, the next iteration is planned out in an iteration planning meeting. The customer (with the developers' guidance, of course) decides what stories are to be implemented in the next iteration, based on what is most important to them, and what is most practical to implement next.
It is important that each iteration takes just as long as all the others in a given project. The time that it took to complete a given story is recorded so that the programmers get a good feel for how much effort it takes to do that type of work.
The stories are broken down into tasks, which are the steps needed to implement a given user story. Developers then sign up to do those tasks.
On the completion of an iteration, acceptance tests are done to ensure that the test cases defined in that story have been met. The acceptance tests include both automated unit testing, and customer testing. This makes sure that all requirements are reached because the development is based around those requirements and there are definite indicators on whether a given requirement is met. It also breaks down the project into reachable goals rather than having programmers work away forever on an ever-expanding megalith.
Go the simplest way that meets the requirements - complexity may be clever, but it costs more in the end (maintenance, etc). No needless complications.
This development method enables the design to evolve as you implement the stories and get an in-depth look at what is needed to fill the requirements. This will, of course, require a lot of refactoring of code, but it also will lead to the flexibility to add new features as they come. Needless to say, JIT Designing is one of the most controversial concepts in XP.
Weaknesses
It can become counter-productive to design as you go because certain things need to be planned out ahead of any implementation. With no concrete design, things can become chaos. However, there are many things which, if planned ahead, will only be re-designed later on.
In XP, developers are in constant communication with each other and with their customer(s). This includes:
- A daily stand-up meeting of all members of the group.
- Swapping developers between tasks, so everyone gets to know all the different parts of the system being developed.
Continuous integration eliminates the headaches of working with outdated code and trying to integrate fragmented or diverging code into the system.
The programming team should not work too much overtime and exhaust themselves. Try to maintain a moderate pace that can be sustained throughout the entire length of the project, rather than a hectic, crowded schedule that leaves you burned out by the middle of the project.
Have the customer be as available and as close as possible, preferably on-site. This will help you collaborate with the customer and meet their requirements.
Weaknesses: It is unlikely that it will be possible for a competent customer representative to be available at all times.
Anyone in the developer team should be able to change any piece of code.
Weakness: If the person who changed the code does not talk to others both before and after the changes, problems can arise.
Otherwise known as "If it ain't broke, fix it!". When you see something that could be better and simpler, change it! According to XP, this will make the product constantly improve.
Weaknesses
If you're constantly changing things, it can be hard for everyone to keep up with the changes, both in knowledge and in coding. Regression testing is a must with constant refactoring. The reliance on testing becomes a weak point in the development process--are you adequately testing, and are your tests right? Testing, both the process of testing and the process of writing and testing the tests involves a hidden cost-benefit relationship. XP attempts to push the unknown and unmanageable qualities of "bug fixing" onto known and manageable tests but does not adequately address the core issue of what comprises a good test.
YAGNI
"You aren't gonna need it." An expression meaning: "That's not needed, and it will complicate things. Throw it out."
A project's requirements are laid out as individual user stories. These stories have test cases, which are tests and the desired results of those tests, which, if met, indicate that the implementation of that story is complete.
It is important to make small releases of the software product every time you add an area of functionality and make it workable. This helps by allowing the developers to:
- Get feedback on the product at each step of the product's development
- See the fruits of their work before the end of the development process.
A spike solution is a small program/project to explore/test out different solutions to a tough technical or design problem.
Designing as you go, rather than doing all the designing at the beginning of the project. This helps to cover the problem of changing user requirements, and a changing perspective of the system's implementation.
A unit test is an automated test that ensures that the functionality required for a certain area of a project is implemented, and that there are no breaking changes that have not been taken into consideration. See http://www.xprogramming.com/software.htm for a list of unit testing frameworks for different languages/platforms.
At some point in each day, a stand-up meeting is held where everyone stands up in a circle and talks about the project and its progress. It is important that the meeting be kept short, as the purpose is to encourage essential communication between all the members of the team, not to bore everyone by taking a long time hashing things through. It is for this reason that people should stand up for the meeting - it naturally keeps the meeting short.
A test which verifies if the requirements defined in a given user story have been met. This may be an automated unit test, or it may be a manual test by the customer.
A system where two programmers work together at one computer. This way:
- One team member's knowledge and expertise in the area being worked on can be easily passed on to another team member, thereby helping to spread knowledge of the system from developer to another;
- The team members can complement each other's strengths and weaknesses;
- One person can be thinking of the task at hand in terms of the overall design, while the other one thinks in terms of the details of implementation.
The benefits as far as design, bug elimination, etc, can make two programmers at one computer be much more effective than they would be if they were each at separate computers.
The team members must switch roles and re-pair often to keep the knowledge flowing rather than having "knowledge islands", where a certain small group on the team knows a lot about a certain aspect of the product, whereas the rest of the team knows almost nothing about it.
A project is divided into a number of iterations of about 1-3 weeks each. In each iteration, a set of stories that are the most important to the customer are chosen and implemented. At the beginning of each iteration, an iteration planning meeting is held so that the customer can decide what user stories will be done in that iteration.
It is important to keep iterations the same length throughout the entire project, so that you won't be grinding along for weeks on the same area, and so that the project velocity can be easily measured.
A measurement of the number of stories of a given size that can be done in a single iteration.
A user story is broken up into tasks. Each task is taken up and completed by a member/pair on the development team.
A usage situation of a given part of the system for which tests are made to ensure that it works as it should. For example, the customer may want to be able to enter in a part number and receive a report on the current price and availability. Before the programmer implements this functionality, he writes a test, which, if it succeeds, indicates that the functionality works as expected.
A system metaphor should be chosen for each project, to keep the design simple and orderly, and to give people an idea of what the system should be like/ how it should work. A system metaphor is a comparison of the system being developed to a known system model. This helps people to get an overall picture of what the system is like and how it works, from their experience with the system model the system is being compared to. The system metaphor can be anything from an Accounting metaphor, with accounts, transactions, and ledgers, to an Auction metaphor, with sellers, bidders, items-to-sell, and bids.
A planning session to plan out what user stories will be completed in the next iteration of the software product.
A planning session to plan out what will be done for the next release of the software product.
When a fault is found in a system, a regression test is made to ensure that the problem does not recur. This forms a "bug net" to catch bugs as soon as they enter the system.
Coding standards are important in XP. A coding standard keeps code uniform and readable, and makes it as coherent as if it had been written by only one competent developer.
(In the context of QA/Testing) A fault is an area that was overlooked in designing/creating the system that could cause undesired operation.
(In the context of QA/Testing) An issue that causes undesired operation, that is due to an error on the part of the developer(s).
(In the context of QA/Testing) Any undesired operation in the software product.
A feature is any type of functionality requested by the user. It is NOT another word for bug.
(In the context of QA/Testing) A problem is an issue that causes undesired operation, and is not the fault of the software product, but can be overcome by changes to the software product.
A test which simulates the largest possible load on a system.
Test to see how the system behaves under nonsensical input.
A test to ensure that two systems work exactly the same as each other.
Kent Beck is the originator of XP. He has written numerous books on the subject.
Laurie Williams has done extensive writing and research on Extreme Programming, especially in the area of Pair Programming.
Martin Fowler has written some books on XP. He is well known for his work and writing on refactoring.
Jim Highsmith has written books on a couple of different software development methodologies, including XP.
William Wake is an agile development team coach, and has written numerous articles on specific topics within XP.
Ron Jefferies is one of the inventors of XP, and has written many books on the subject.
IBM is fairly heavily involved with XP, especially since it works with the Java community (Eclipse, etc), and XP is closely tied to Java.
I apologize if I have missed mentioning any important figures in the XP arena. There are hundreds of important figures in XP, but if I have missed any of the most prominent figures, please let me know.
Extreme Programming Explained: Embrace Change by Kent Beck - Written by the originator of XP, and one of the most definitive guides available on XP. A MUST-READ! A 42-page preview is available at Amazon.com
Extreme Programming Installed by Ron Jefferies, Ann Anderson, and Chet Hendrickson - This book goes deeper into XP techniques than Extreme Programming Explained. Should probably be read after the aforementioned book.
The Costs and Benefits of Pair Programming by Laurie Williams & Alstair Cockburn - Results of an empirical study on Pair Programming. Shows and studies the benefits of pair programming
XProgramming Unit Testing Downloads Section - Links to downloads of unit testing software for most common languages.
