Extreme programming (XP) is a simplified methodology for the organization of program development for small and medium-sized teams of developers engaged in creating a software product in the face of unclear or rapidly changing requirements.

XP Objectives

The main objectives of XP are to increase customer confidence in the software by providing real success evidence of the development process and drastically shortening the development time of the product. In this case, XP is focused on minimizing errors in the early stages of development. This allows you to achieve the maximum speed of release of the finished product and gives an opportunity to talk about the predictability of the work. Virtually all XP techniques are aimed at improving the quality of the software product.

Principles of XP

The main principles are:

• Iterative. Development is carried out by short iterations in the presence of an active relationship with the customer. To do iterations by themselves is suggested to be short, the recommended duration is 2-3 weeks and not longer than 1 month. For one iteration, a group of programmers must implement several properties of the system, each of which is described in the user history. User stories (US) in this case are the initial information on the basis of which the module is created. They differ from the use cases (UC). The description of the US is short – 1-2 paragraphs, whereas the UCs are usually described in sufficient detail, with the main and alternative flows, and supplemented by the model. USs are written by the users themselves, which are part of the team in XP, in contrast to the UCs, which are described by the system analyst. The lack of the description formalization of the project input data in XP is sought to be compensated for by actively integrating the customer into the development process as a full member of the team.
• Simplicity of solutions. The first simplest working solution is accepted. Extremality of the method is associated with a high degree of risk of the solution, due to the surface analysis and a rigid time schedule. A minimal set of main functions of the system is implemented at the first and each subsequent iteration; functionality expands at each iteration.
• Intensive development by small groups (no more than 10 people) and pair programming (when two programmers together create code in one common workplace), active communication in a group and between groups. All this is aimed at the earliest possible detection of problems (both errors and failure of terms). Pair programming is aimed at solving the problem of project stabilization. When applying XP methodology, the risk of code loss is high due to the departure of a programmer who has not sustained an intensive work schedule. In this case, the second programmer from the pair plays the role of the “heir” of the code. It is also important how the groups are distributed in the workspace – in XP an open workspace is used, which implies fast and free access to everyone for everyone.
• Feedback from the customer, whose representative is actually involved in the development process.
• Sufficient degree of courage and the desire to take risks.

XP tricks (practices)

XP is usually characterized by a set of 12 rules (practices) that must be met to achieve a good result. None of the practices is fundamentally new, but they are gathered together in XP.

1. Planning the process. The entire development team comes together, a collective decision is made about which properties of the system will be implemented in the nearest iteration. The complexity of implementing each property is determined by the programmers themselves.
2. Close interaction with the customer. The customer representative must be a member of the XP team. He writes USs, chooses stories that will be implemented in a specific iteration, and answers questions about the business. The customer representative must be an expert in the automated subject area. It is necessary to have constant feedback from the customer’s representative.
3. System-wide naming rules. Good system naming rules assume the simplicity of naming classes and variables. The development team must have unified naming rules.
4. Simple architecture. Any property of the system should be implemented as simply as possible. Programmers in the XP-team work under the motto: “Bare bones!”. The first simplest working solution is accepted, the necessary level of functionality is implemented at the moment. This saves the time for the programmer.
5. Refactoring. This is optimization of existing code in order to simplify it. Such work should be conducted constantly. Keeping the code transparent and defining its elements only once, programmers reduce the number of errors that will later have to be eliminated. When implementing each new property of the system, the programmer must think about whether it is possible to simplify the existing code and how this will help to implement the new property. In addition, you can not combine refactoring with design: if a new code is being created, refactoring should be postponed.
6. Pair programming. All programmers should work in pairs: one writes the code, the other monitors. Thus, it is necessary to place a group of programmers in one place. XP most successfully works in unallocated teams of programmers and users.
7. 40-hour work week. A programmer should not work more than 8 hours a day. The need for overtime is a clear indicator of the problem in this particular area of development. The search for reasons for overtime work and their early elimination is one of the main rules.
8. Collective ownership of the code. Each programmer in the team must have access to the code of any part of the system and the right to make changes to any code. Mandatory rule: if the programmer made changes and the system does not work correctly after that, then this programmer should correct the errors.
9. Uniform coding standards. Coding standards are needed to provide other practices: collective code ownership, paired programming and refactoring. Without a single standard, these practices are at least more difficult to implement, but in reality it is impossible: the group will work in a constant time-out regime. The team is working on the project for a long time. People come and go. No one encodes alone and the code belongs to everyone. There will always be times when you need to understand and correct someone else’s code. Developers will remove duplicate code, analyze and improve other people’s classes, etc. Over time, it will be impossible to tell who is the author of a particular class. Therefore, everyone should obey the general coding standards – code formatting, naming classes, variables, constants, comment style. The foregoing means that all team members must agree on common coding standards. No matter what, but all are obligated to them.
10. Small releases. The minimum iteration is one day, the maximum one is a month; The more releases are carried out, the more shortcomings of the system will be revealed. The first releases help to identify shortcomings at the earliest stages, then the functionality of the system is expanded on the basis of PI. Since the user is included in the development process from the first release, he evaluates the system and provides a user history and comments. Based on this, the next iteration is determined, that is, what will be the new release. In XP, everything is aimed at providing continuous feedback to users.
11. Continuous integration. Integration of new parts of the system should occur as often as possible, at least every few hours. The basic rule of integration is as follows: integration can be made if all tests are successful. If the tests do not pass, then the programmer must either make corrections and then integrate the component parts of the system, or do not integrate them at all. The rule is hard and unambiguous. If there is at least one error in the created part of the system, integration can not be made. Frequent integration allows you to get the finished system faster, instead of spending a week on the assembly.
12. Testing. Unlike most other methodologies, testing in XP is one of the most important components. The extreme approach assumes that tests are written before writing the code. Each module must have a unit test-test of this module. Thus, XP performs regression testing, “quality degradation” when adding functionality. Most errors are corrected at the coding stage. Tests are written by programmers themselves, any of them has the right to write a test for any module. Another important principle: the test determines the code, and not vice versa (test-driven development), that is, a piece of code is put in the repository if and only if all the tests were successful, otherwise this code change is rejected.

The XP process is informal, but requires a high level of self-discipline. If this rule is not met, then XP instantly turns into a chaotic and uncontrolled process. XP does not require programmers to write multiple reports and build mass models. In XP, each programmer is considered a qualified employee, who takes his duties professionally and with great responsibility. If this is not the case in the team, then it’s completely pointless to implement XP – it’s better to start reorganizing the team first. The risk of development is reduced only in the team, which XP is ideal for, in all other cases XP is the development process with the highest risk, because other methods to reduce commercial risks, except for the human factor, are simply absent in XP.