Extreme Programming (XP) is a trivial discipline of development of software based on principles of communication, simplicity, feedback and courage. XP is designed for use with small teams who need to develop software quickly in rapidly changing requirements.
Extreme Programming teams use a simple form of planning to decide what should be done next in order to predict when the project would be done. The team produces the software in a series of small fully integrated releases that pass all the tests the customer has defined by focusing on business value.
Extreme Programmers work together in pairs as a group with simple design and tested code improving the design continually to keep it always just right for the current requirements. The Extreme Programming group keeps the system fully integrated and running at all the time. The programmers always use to write production code in pairs and all work together all the time. They code in a consistent way so that everyone can understand and improve all the code as per requirement.
there are 12 Basic practices of XP
1) Planning Game
In software development XP planning addresses two key questions which are predicting what will be accomplished by the due date and determining what to do next. The emphasis is on direction finding the project, which is quite straightforward rather than on exact prediction of what will be required and how much time it will take which is quite difficult. There are two key steps in XP addressing these two questions:
a) Release Planning
In this planning the Customer presents the desired features to the programmers and the programmers calculate their difficulty. The Customer lays out a plan for the project with the costs estimates and with knowledge of the importance of the features. Initial release plans are necessarily imprecise because until the team begins to work neither the priorities nor the estimates are truly solid. Even the first release plan is accurate enough to make decision however XP teams revise regularly the release plan.
b) Iteration Planning
It is the practice in which the team is given direction every week. XP teams develop software in two-week iterations, delivering software at end of iteration. The Customer presents the features desired for the next two weeks during Iteration Planning. The programmers divide them down into different tasks and estimate their cost. Based on the amount of work accomplished in the previous iteration, the team decides for what will be done in the current iteration.
2) Small Releases
XP teams practice small releases in two different ways:
First the team releases tested, running software, delivering business value chosen by the Customer. The Customer uses this software for evaluation or even release to end-users. The most important aspect is that the software is visible to the customer at the end of every iteration. This keeps everything visible, open and tangible to customer.
Second, XP teams release design of software to their end users frequently. XP Web projects release daily in house projects or more frequently.
3) Metaphor
Extreme Programming teams develop a common view of how the program works which is called “metaphor”. The metaphor is a simple suggestive description of how the program works. XP teams use a common name system to ensure that everyone understands how the system works and where to look to find the functionality you’re looking for.
4) Simple Design
XP teams use simple design to build software. An XP team maintains the design, which exactly implemented for the current functionality of the system.
In XP design is not a one-time thing. It is an all time thing. There are certain design steps in release planning and iteration planning plus teams engage in quick design sessions and design revisions through the course of the entire project. In an incremental, iterative process like Extreme Programming, good design is very important. That’s why there is so much concentration on design throughout the entire development of software.
5) Customer Tests
The XP Customer defines one or more automated tests to show that the feature is working as a part of presenting each desired feature. The team runs these tests and uses them to prove to the customer that the feature is implemented correctly. Automation is used in the press of time to skip manual tests.
In best XP teams the customer tests are same as programmer tests: once the test runs correctly the team keeps it running correctly thereafter.
6) Refactoring
XP teams improve the development of the software throughout its design cycle. This is done by maintaining the software clean with high communication, simple, complete and without duplication.
7) Pair Programming
All development of software in XP is built by using two programmers: sitting side by side and at the same machine. This practice guarantees that at least one programmer reviewed all development code and which results in better design, better testing and better code.
It is looking like two programmers doing “one programmer’s job”, but the reverse is true because pairing produces better code in the same time as programmers working singly. Pair programming offer better code and tests, serves to communicate knowledge throughout the team. As pair programmer uses to switch then everyone gets the benefits of everyone’s specialized knowledge.
8) Collective Code Ownership
In collective code ownership any pair of programmers can improve any code at any time. This means that all code gets many people’s attention, which improves code quality and reduces defects. There is another important advantage is that when code is owned by particular individuals then required features may be put in the wrong place.
9) Continuous Integration
XP teams build and integrate the software design system multiple times everyday. This maintains all the programmers on the same page and enables very rapid growth. Team integrating more regularly tends to reduce integration problems that plague teams who integrate less often.
10) 40-hour Week
Exhausted programmers make more mistakes. XP teams do not work overtime, maintaining team member fresh, healthy and effective.
11) On-site Customer
An XP project is observed by a dedicated individual who is determine requirements, set priorities and answer questions as the programmers have them. The effect of on-site customer is that communication improves with less hard-copy documentation.
12) Coding Standard
For a team to work in pairs and to share ownership of all the code; all the programmers should write the code with some rules that make sure the code communicates clearly.
XP teams use a common coding standard so that all the code in the system looks as a single individual wrote it. The specifications of the standards are not important but important is that all the code looks familiar in support of collective ownership.