home Windows The process of programming effective actions in extreme conditions. Unified development process and extreme programming. At any given time, the system should be designed as simply as possible. Do not need extra

The process of programming effective actions in extreme conditions. Unified development process and extreme programming. At any given time, the system should be designed as simply as possible. Do not need extra

Extreme Programming (XP) is one of the agile development methodologies software. The authors of the methodology are Kent Beck, Ward Cunningham, Martin Fowler and others.

The planning game

Our world is too changeable and unpredictable to rely on the constancy of the situation. The same thing happens in software development: a rare system can be said that its final form was known in advance in detail at the very beginning of development. Usually, the customer's appetite comes with eating: he constantly wants to change something, improve something, and throw something out of the system altogether. This is the variability of requirements that everyone is so afraid of. Fortunately, man is given the ability to predict possible options and thus keep the situation under control.
In Extreme Programming, planning is an integral part of development and the fact that plans can change is taken into account from the very beginning. That fulcrum, a technique that allows you to predict the situation and painlessly put up with changes, is the game of planning. In the course of such a game, known system requirements can be quickly collected, evaluated and planned for their development in accordance with priority.
Like any other game, planning has its participants and its purpose. The key figure is, of course, the customer. It is he who informs about the need for a particular functionality. Programmers also give an approximate assessment of each functionality. The beauty of the game of planning lies in the unity of purpose and solidarity between the developer and the customer: in case of victory, everyone wins; in case of defeat, everyone loses. But at the same time, each participant goes to victory in his own way: the customer chooses the most important tasks in accordance with the budget, and the programmer evaluates the tasks in accordance with his ability to implement them.
Extreme programming assumes that developers are able to decide for themselves how long they will cope with their tasks and which of them would be more willing to solve one problem and who would not.
In an ideal situation, the planning game involving the customer and the programmer should be played every 3-6 weeks, before the start of the next iteration of development. This makes it fairly easy to make adjustments in line with the successes and failures of the previous iteration.

Release plan

The release plan defines release dates and the user language that will be implemented in each release. Based on this, you can choose the wording for the next iteration. During an iteration, acceptance tests are produced and run within that iteration and all subsequent iterations to ensure that the program works correctly. The plan can be revised in case of a significant lag or advance following the results of one of the iterations.
Iterations. Iteration makes the development process dynamic. You don't need to plan your programming tasks long in advance. It is better to have a planning meeting at the beginning of each iteration instead. It is not worth trying to implement something that was not planned. You will still have time to implement these ideas when they reach the turn according to the release plan.
By getting used to not adding functionality ahead of time and using direct planning, you can easily adapt to changing customer requirements.

Iteration planning

Iteration planning begins with a meeting at the beginning of each iteration to develop a plan of steps to achieve program objectives. Each iteration should last between one and three weeks. Statements within an iteration are sorted in order of their importance to the customer. In addition, tasks are added that failed the acceptance tests and need to be improved. Statements and test results are translated into program tasks. Tasks are written on cards that form a detailed iteration plan. It takes from one to three days to solve each of the tasks. Tasks that need less than one day can be grouped together, and large tasks can be divided into several smaller ones. Developers evaluate tasks and deadlines to complete them. It is very important for the developer to set the exact time for the execution of the task. It may be necessary to re-evaluate some of the language and revise the release plan after every three or five iterations - this is quite acceptable. If you implement the most important areas of work first, then you will always have time to do the maximum possible for your customers. A development style based on a sequence of iterations improves the development process.

Standing meeting

Every morning there is a meeting to discuss problems, their solutions and to increase the concentration of the team. The meeting is held standing up to avoid lengthy discussions that are not interesting for all team members.
In a typical meeting, most participants don't contribute anything, just participate to hear what others have to say. A large amount of people's time is wasted to receive a small amount of communication. Therefore, the participation of all people in meetings takes resources away from the project and creates chaos in planning.
For this kind of communication, a standing meeting is needed. It's much better to have one short mandatory meeting than many long ones that most developers have to attend anyway.
If you have daily standing meetings, then all other meetings should be attended only by those people who are needed and will bring something. Moreover, it is even possible to avoid some meetings. With limited participants, most meetings can be held spontaneously in front of a monitor where the exchange of ideas is much more intense.
The daily morning meeting is not just another waste of time. It will allow you to avoid many other meetings and will save you more time than wasted.

Simplicity

A simple design always takes less time than a complex one. So always do the simplest things that can only work. It's always faster and cheaper to replace complex code right away before you spend a lot of time working on it. Keep things as simple as possible without adding functionality before it's planned. Keep in mind: keeping design simple is hard work.

Metaphor system

The choice of metaphor system is needed to keep the team in the same framework when naming classes and methods. How you name your objects is very important for understanding the overall design of the system and code reuse. If the developer is able to correctly guess how an existing object might be named, this saves time. Use a naming system for your objects that everyone can understand without specific knowledge of the system.

Customer at work site

The main problem of software development is the lack of knowledge of programmers in the developed subject area. Extreme Programming found a way out of this situation as well. No, this is not a developer's internship at the customer's enterprise - then he will not want to program. On the contrary, it is the participation of the customer in the development process.
How can a programmer, without thoroughly understanding the essence of the issue and not being a telepath, guess what the customer wants? The answer is obvious. by the most in a simple way overcome such an inconvenience - and Extreme Programming teaches us to find the most simple solutions- will ask the customer a direct question. More rigorous approaches require a comprehensive preliminary analysis of the area being developed. In certain cases, this is justified, although it costs more. The real experience of conducting mundane projects shows that it is impossible to collect all the requirements in advance. Moreover, even if we assume that all the requirements are currently collected, there will still be one bottleneck: programs, like everything in nature, are not created instantly, and in the meantime, business processes can change. This should be taken into account.
Many doubt the possibility of involving the customer in the development process. Indeed, customers are different. If it is not possible to attract a customer or his representative, it sometimes makes sense to temporarily hire a specialist in the area being developed. Such a step will reduce ambiguities in the work, increase the speed of development and bring the project closer to what the customer wants to receive. This can also be beneficial from the financial side: after all, the salary of a programmer sometimes significantly exceeds the salary of specialists in other industries.
user story. User Story (something like a user story) is a description of how the system should work. Each User Story is written on a card and represents some piece of system functionality that makes logical sense from the Customer's point of view. The form is one or two paragraphs of text that is understandable to the user (not very technical).
User Story is written by the Customer. They are similar to, but not limited to, system usage scenarios. user interface. For each story, functional tests are written to confirm that this story is correctly implemented - they are also called acceptance tests.

Testing before development

Testing, in its classical sense, is a rather boring procedure. Usually they hire a tester who periodically performs the same actions and waits for the day when he is finally transferred to another position or there is an opportunity to change jobs.
In extreme programming, the role of testing is more interesting: now the test comes first, and then the code. How can you test something that doesn't exist yet? The answer is simple and banal: test your thoughts - what should be expected from a future piece of software or functionality. This will allow you to better understand what programmers need to do, and check the functionality of the code as soon as it is written.
But the test might not work either. What about writing a test for a test? And then test for test and so on ad infinitum? Not at all. The test for the test will replace the code. How so? But look: imagine that you need to fix the nut in the middle of the bolt so that it does not turn. What do they do for this? Screw the second nut close to the first, so that each nut prevents the next one from turning. It's the same in programming: the test tests the code, and the code tests the test.
Experience shows that this approach not only does not slow down, but also speeds up development. After all, knowing what needs to be done and the required amount of work will save time by refusing to implement unclaimed this moment details.

Pair programming

All code for a production system is written in pairs. Two developers are sitting side by side. One dials, the other watches. They change from time to time. It is not allowed to work alone. If for some reason the second of the pair missed something (he was ill, departed, etc.), he is obliged to review all the changes made by the first.
It sounds unusual, but after a short adjustment period, most people work great in pairs. They even like it, because the work is done noticeably faster. The principle "One head is good, but two is better" applies. Couples usually find more optimal solutions. In addition, the quality of the code is significantly increased, the number of errors is reduced, and the exchange of knowledge between developers is accelerated. While one person focuses on the strategic view of an object, the second person implements its properties and methods.

Change of positions

During the next iteration, all workers should be moved to new areas of work. Such movements are necessary to avoid isolation of knowledge and eliminate bottlenecks. Particularly fruitful is the replacement of one of the developers in pair programming.

Collective code ownership

Collective code ownership encourages developers to submit ideas for all parts of the project, not just their own modules. Any developer can change any code to add functionality and fix bugs.
At first glance it looks like chaos. However, considering that at least any code is created by a couple of developers, that tests allow you to check the correctness of the changes made, and that in real life you still have to understand someone else's code one way or another, it becomes clear that collective code ownership greatly simplifies the introduction of changes and reduces the risk associated with the high specialization of a team member.

Coding convention

You are in a team that has been working on this project for a long time. People come and go. No one codes alone and the code belongs to everyone. There will always be moments when it will be necessary to understand and correct someone else's code. Developers will remove or change duplicate code, analyze and improve other people's classes, and so on. Over time, it will not be possible to tell who the author of a particular class is.
Therefore, everyone must obey common coding standards - code formatting, class, variable, constant naming, comment style. In this way, we will be sure that by making changes to someone else's code (which is necessary for aggressive and extreme progress forward), we will not turn it into a Babylonian Pandemonium.
The above means that all team members must agree on common coding standards. It doesn't matter what. The rule is that everyone obeys them. Those who do not wish to comply with them leave the team.

Frequent integration

Developers, if possible, should integrate and release their code every few hours. In any case, you should never keep changes longer than one day. Frequent integration avoids alienation and fragmentation in development where developers can't communicate in the sense of exchanging ideas or reusing code. Everyone must work with latest version.
Each pair of developers should give away their code as soon as there is a reasonable opportunity to do so. This may be when all UnitTests pass 100%. By submitting changes several times a day, you reduce integration problems to almost nothing. Integration is a "pay now or pay more later" activity. Therefore, by integrating changes daily in small portions, you will not have to spend a week to tie the system together just before the project is delivered. Always work on the latest version of the system.

Forty hour work week

A person, especially if he is a programmer, is capable of doing a lot for the sake of business: stay at work, go to work for the weekend, refuse to take a vacation, stay awake for several days, sitting at the keyboard ... In general, you can’t do anything for the sake of your favorite pastime. But extreme programming is categorically against such self-sacrifice and violation of accepted labor law norms.
This is dictated not only by considerations of legality and humanity, but - first of all - by the need to increase the efficiency of work and strict organization. After all, extreme programming is a collective game, designed not for individuals, but for the whole group as a whole. And such a thing as, for example, pair programming, is possible only if the biorhythms of its participants are synchronized. And it is impossible if one person comes to work at nine, and the second at twelve, or one decides that it is better for him to work on Saturday and Sunday, while the other is uncomfortable.
But most importantly, in order to maintain health and performance, a person needs a good rest. The eight-hour work day and the five-day work week are established precisely for reasons of maximum productivity. In many Western firms, leaving work late is regarded as poor academic performance or an inability to properly manage one's working time. In most cases, this is true. Yes, and from a medical point of view, delays at work lead to constant fatigue, irritability and decreased brain activity. Is it effective? But how to organize constant open communication between developers in such a team, and will pair programming be possible? The answer is negative. Rules are rules and should be followed.

Conclusion

These techniques are not brought together by chance. Their consistent combination is able to bring the development process into an intellectual resonance, significantly improving the quality of the product and bringing the time of its release closer. The main beauty of all Extreme Programming is predictability and minimizing development costs; providing the customer with the product that he wants to receive at the time of release; and of course communication and training of developers on the job.

Bibliography:

Extreme Programming (XP) originated as an evolutionary bottom-up software development method. This approach is an example of the so-called Agile Development Method. The group of "live" methods includes, in addition to extreme programming, SCRUM methods, DSDM (Dynamic Systems Development Method), Feature-Driven Development (development driven by system functions), etc.

The basic principles of "live" software development are fixed in the "live" development manifesto, which appeared in 2000.

· The people involved in the project and their communication is more important than processes and tools.
· A working program is more important than comprehensive documentation.
· Cooperation with the customer is more important than discussing the details of the contract.
· Practicing changes is more important than following plans.

"Live" methods appeared as a protest against the excessive bureaucratization of software development, the abundance of side documents that are not necessary to obtain the final result, which have to be drawn up during the project in accordance with the majority of "heavy" processes, additional work to support the organization's fixed process, as required by, for example, the CMM. Most of these works and documents are not directly related to software development and quality assurance, but are intended to comply with the formal clauses of development contracts, obtain and confirm certificates for compliance with various standards.

"Live" methods allow most of the efforts of developers to focus on the actual tasks of developing and satisfying real needs users. The absence of a pile of documents and the need to keep them in a coherent state allows you to more quickly and efficiently respond to changes in requirements and in the environment in which the future program will have to work.

Nevertheless, XP has its own development process scheme (although, generally speaking, the widely used understanding of the "development process" as a fairly rigid scheme of actions contradicts the very idea of development "liveness"), shown in Figure 1.

According to the authors of XP, this technique is not so much following some general patterns of action as using a combination of the following techniques. However, each technique is important, and without it, development is considered non-XP, according to Kent Beck, one of the authors of this approach along with Ward Cunningham (Ward Cunningham) and Ron Jeffries (Ron Jeffries).

· living planning game)

Its task is to determine as quickly as possible the amount of work that needs to be done before the next version of the software. The decision is made, first of all, based on the priorities of the customer (i.e., his needs, what he needs from the system to more successfully run his business) and, secondly, based on technical assessments(i.e. estimates of the complexity of development, compatibility with other elements of the system, etc.). Plans change as soon as they begin to diverge from reality or the wishes of the customer.

Fig.1

· Frequent change versions (small releases)

The very first working version should appear as soon as possible and should immediately be used. Next versions are prepared at fairly short intervals (from several hours with small changes in small program, up to a month or two with a serious processing of a large system). Versions (releases) of the product should go into production as often as possible. Work on each version should take as little time as possible. At the same time, each version should be meaningful enough in terms of usefulness for business.

· Metaphor of the system

The metaphor, in a fairly simple and understandable form for the team, should describe the main mechanism of the system. This concept is reminiscent of architecture, but it should be much simpler, in just one or two phrases, to describe the main essence of the accepted technical solutions.

Architecture is some idea of the components of the system and how they are interconnected. Developers use architecture to understand where in the system some new functionality is added and what some new component will interact with.

The system metaphor is analogous to what most techniques call architecture. The system metaphor gives the team an idea of how the system currently works, where new components are added, and what form they should take.

· Simple design solutions (simple design)

At any given time, the system should be designed as simply as possible. No need to add features in advance - only after explicitly asking for it. All excess complexity is removed as soon as it is discovered.

XP proceeds from the fact that in the course of work, the conditions of the problem can change repeatedly, which means that the product being developed should not be designed in advance entirely and completely. If at the very beginning of work you are trying to design the system in detail from beginning to end, you are wasting your time. XP suggests that design is such an important process that it must be done continuously throughout the life of the project. Design should be carried out in small steps, taking into account constantly changing requirements. At each moment in time, we try to use the simplest design that suits the current task. At the same time, we change it as the conditions of the problem change.

· Development on the basis testing (test-driven development)

Developers first write tests, then try to implement their modules so that the tests work. Customers write tests in advance that demonstrate the main features of the system, so that you can see that the system really works.

XP focuses on two types of testing:

ь testing of units (unit testing);

ь acceptance testing (acceptance testing).

extreme programming software

A developer cannot be sure of the correctness of the code he writes until absolutely all unit tests of the system he develops work. Unit tests allow developers to verify that their code works correctly. They also help other developers understand why a particular piece of code is needed and how it functions. Unit tests also allow the developer to refactor without any fear.

Acceptance tests allow you to make sure that the system really has the declared capabilities. In addition, acceptance tests allow you to check the correct functioning of the developed product.

For XP, an approach called TDD (Test Driven Development) is more priority, first a test is written that does not pass, then the code is written so that the test passes, and after that the code is refactored.

· Constant refactoring

It's no secret that every new feature added and the code growing makes it harder to develop, catch bugs, and make subsequent changes. One of the tricks of Extreme Programming is to compensate for the addition of functionality by improving the code. This is code refactoring or refactoring.

Programmers are constantly reworking the system to eliminate unnecessary complexity, increase the understandability of the code, increase its flexibility, but without changing its behavior, which is verified by running after each reworking of the tests. At the same time, preference is given to more elegant and flexible solutions, compared to those that simply give the desired result. Unsuccessfully refactored components should be detected when running tests and rolled back to the last consistent state (along with components dependent on them).

Refactoring is a technique for improving code without changing its functionality. XP implies that once code is written, it will almost certainly be redone many times during the course of a project. The XP developers are ruthlessly reworking previously written code in order to improve it. This process is called refactoring. The lack of test coverage provokes the rejection of refactoring, due to the fear of breaking the system, which leads to the gradual degradation of the code.

· Programming in pairs (pair programming)

Experienced developers have noticed that periodically reviewing someone else's code has a positive effect on its quality. Extreme Programmers have developed this approach: during development, the code is constantly revised through a technique called pair programming.

Coding is done by two programmers on one computer. Pairing is arbitrary and varies from problem to problem. The one in whose hands the keyboard is trying in the best possible way solve the current problem. The second programmer analyzes the work of the first and gives advice, considers the consequences of certain decisions, new tests, less direct, but more flexible solutions. If necessary, the keyboard is freely transferred from one to another. While working on a project, the pairs are not fixed: it is recommended to mix them up so that each programmer in the team has a good idea of the whole system. Thus, pair programming enhances the interaction within the team.

· Collective possession code (collective ownership)

Collective possession means that each team member is responsible for the entire source. Thus, everyone has the right to make changes to any part of the program. Pair programming supports this practice: working in different pairs, all programmers become familiar with all parts of the system's code. An important benefit of collective code ownership is that it speeds up the development process, because when a bug occurs, any programmer can fix it.

By giving every programmer the right to change the code, we run the risk of introducing bugs from programmers who think they know what they're doing but don't consider some dependencies. Well-defined UNIT tests solve this problem: if unreviewed dependencies generate errors, then the next run of UNIT tests will fail.

· Constant integration (continuous integration)

The system is assembled and integrated tested as often as possible, several times a day, every time a couple of programmers finish implementing a feature.

If you integrate your system often enough, you can avoid most of the problems associated with it. In traditional methods, integration, as a rule, is performed at the very end of the work on the product, when it is considered that all the components of the system being developed are completely ready. In XP, code integration of the entire system is performed several times a day, after the developers have made sure that all unit tests work correctly.

Despite its simplicity, this technique has its own rules of use, such as the success of the existing unit tests for the integrated functionality, the presence of functional or acceptance tests, and, of course, the ability to rollback to a previous state. As a rule, integration and resolution of accompanying difficulties are performed on separate computer a couple of programmers. This allows you to minimize the risk of undesirable consequences of integration.

· 40 hour working a week

Overtime is seen as a sign of big problems in the project. It is not allowed to work overtime for 2 weeks in a row - this exhausts the programmers and makes their work significantly less productive.

A person, especially if he is a programmer, is capable of many things for the sake of business: stay at work, go to work for the weekend, refuse to take a vacation, stay awake for several days, sitting at the keyboard ... In general, you can’t do anything for the sake of your favorite pastime. But extreme programming is categorically against such self-sacrifice and violation of accepted labor law norms.

This is dictated not only by considerations of legality and humanity, but - first of all - by the need to increase the efficiency of work and strict organization. After all, extreme programming is a collective game, designed not for individuals, but for the whole group as a whole. And such a thing as, for example, pair programming, is possible only if the biorhythms of its participants are synchronized. And it is impossible if one person comes to work at nine, and the second at twelve, or one decides that it is better for him to work on Saturday and Sunday, while the other is uncomfortable.

But most importantly, in order to maintain health and performance, a person needs a good rest. The eight-hour work day and the five-day work week are established precisely for reasons of maximum productivity. In many Western firms, leaving work late is regarded as poor academic performance or an inability to properly manage one's working time. In most cases, this is true. Yes, and from a medical point of view, delays at work lead to constant fatigue, irritability and decreased brain activity. Is it effective? But how to organize constant open communication between developers in such a team, and will pair programming be possible? The answer is negative. Rules are rules and should be followed.

· Inclusion customer in command (on-site customer)

As part of the development team, there is always a representative of the customer, who is available throughout the working day and is able to answer all questions about the system. It is his duty to respond promptly enough to questions of any type regarding the functions of the system, its interface, the required performance, correct operation systems in difficult situations, the need to communicate with other applications, etc.

Many doubt the possibility of involving the customer in the development process. Indeed, customers are different. If it is not possible to attract a customer or his representative, it sometimes makes sense to temporarily hire a specialist in the area being developed. Such a step will reduce ambiguities in the work, increase the speed of development and bring the project closer to what the customer wants to receive. This can also be beneficial from the financial side: after all, the salary of a programmer sometimes significantly exceeds the salary of specialists in other industries.

· Usage code how funds communications

The code is seen as the most important means of communication within the team. Code clarity is one of the top priorities. Following coding standards that provide such clarity is imperative. Such standards, in addition to code clarity, should ensure the minimum of expressions (no duplication of code and information) and should be accepted by all team members.

· open working space (open workspace)

The team is housed in one room, spacious enough to facilitate communication and the possibility of collective discussions when planning and making important technical decisions.

· Change rules on necessary (just rules)

Each member of the team must accept the listed rules, but if the need arises, the team can change them if all its members agree on this change.

As can be seen from the techniques used, XP is designed to be used within small teams (no more than 10 programmers), which is also emphasized by the authors of this technique. A larger team size destroys the ease of communication necessary for success and makes many of the techniques listed impossible.

Extreme Programming is a departure from the traditional process of creating programs - instead of one-time planning, analysis and design of a system with a long-term perspective, programmers now implement all these operations gradually during development.

Initially, there was a “waterfall” model (Fig. 1a): we ask users to unambiguously formulate their requirements; we are designing a system that will do whatever users want; we write code; we test the program to make sure it does what it is supposed to do. Everything turns out great.

In fact, things were far from rosy. Before development begins, users are not yet able to unambiguously formulate their requirements. They did not always know what they wanted, sometimes they contradicted themselves and changed their views on the problem. But it's not just the users. We programmers, having gone three-quarters of the way and found that we actually did only one-third of the work, rejoiced at this as a tremendous success.

So, a long development cycle is bad because it is not able to adapt to changes. Then, perhaps, it is necessary to shorten the cycle, and all problems will be solved? On fig. 1b illustrates the transformation of the waterfall model into an iterative model.

Recall that the waterfall model did not appear out of nowhere - it was a natural reaction to those shocking estimates that showed that the cost of making changes to the program increases very much over time. If this is true, then it is necessary to make the most important, far-reaching decisions at the earliest stage of the program's life cycle so that they do not have to pay dearly for them later.

The academic community of software developers took on the problem of the high cost of change and created new technologies - relational databases, modular programming, information hiding. But what if all these works have already exhausted their potential? And we can find new way reduce the cost of making changes by not cutting the "waterfall" into pieces, but simply mixing all its components? The result is shown in Figure 1c. We called it "Extreme Programming" (XP).

Anatomy of XP

XP moves away from the traditional creation process software system and instead of one-time planning, analysis, and design with a long-term perspective, XP implements all of these activities gradually during development, thereby achieving a significant reduction in the cost of changes to the program. The XP methods were designed with cumulative use in mind, so as you understand one of them, you will inevitably come to understand the others (see sidebar). The sidebar traces the historical background to this approach.)

XP development cycle

On fig. 2 process XP is related to different time axes, where years, months, weeks and days are used as the unit of measure. The customer determines the next version (release) of the system, choosing the most valuable features (in XP they are called stories - stories) from all possible. The value of functions is determined by the material and time costs for their implementation by the development team.

The customer determines the stories for the next iteration by choosing the most significant stories from those remaining in the version, again based on an estimate of the cost and speed of their development. Programmers break down stories into local tasks, and everyone takes responsibility for one of them. Then the programmer transforms his problem into a set of test cases, the successful execution of which will show that the problem has been completely solved. Working in tandem with a partner, the programmer achieves the normal operation of the tests, while developing a common project. Thus, it is possible to implement the most simple architecture of the system as a whole.

Stories

From XP's point of view, the period leading up to the first launch of the system into actual operation is a dangerous anomaly in life cycle project, and it must be overcome as soon as possible. However, work on any project must be started somehow.

First of all, it is necessary to decide what the system is intended for in general and what it should be able to do in the first place. As a rule, some analysis is needed to make such decisions. It is symbolized by the narrow blue rectangle in Fig. 1s. You can't start programming until you understand what actually needs to be programmed.

The results of the general analysis are presented as stories - indexes listing the possible applications of the system. It is necessary that each story is focused on specific business objectives so that it can be tested and evaluated using quantitative indicators. month is enough acceptable time to formulate stories for a 10 person-year project. It is clear that this time is not enough for a detailed study of all possible problems. But there will never be enough time to analyze all the problems, if you intend to move on to the implementation of the system at all.

Version

As can be seen from fig. 2, we do not implement all the stories at once. The customer first selects a small set of the most important stories that are logically related to each other. And we program and put them into operation first of all. After that, everything else is implemented.

Selecting stories for a version of the system can be compared to shopping in a supermarket. You head to the store with a hundred dollars in your pocket. Consider what you need first. Look at the price tags. And decide what to buy. In the planning game, products are stories and price tags are story estimates. Your budget is determined by the number of estimated stories delivered by the development team in a given unit of time.

The buyer (customer) can either fill his basket (choose a set of stories), after which the programmers will calculate the final date for their implementation, or set a date by which the programmers will calculate the budget, and the customer will collect the required number of stories for the amount received.

Iteration

The goal of each iteration is to launch several new, tested and ready-to-run stories into production. This process begins with a plan that defines what stories will be implemented and how the development team will accomplish this task. While development is underway, the customer comes up with functional tests. At the end of an iteration, tests should be running and developers should be ready for the next iteration.

Starting to plan an iteration, the developers again ask the customer to select the most valuable stories, this time from among those remaining for implementation in this version. Developers break stories into tasks - modules that one person can complete in a few days. If there are several technical challenges, such as moving to new version databases, they are also included in the general list.

Programmers then take responsibility for implementing certain tasks. After all the tasks have been distributed, the programmer responsible for the task evaluates it, this time by the number of ideal programming days. Then the estimates of the tasks of all the programmers of the team are collected, and if some of them plan to spend more time on implementation, and others less, the workload in the team is redistributed accordingly.

During the iteration, programmers implement their tasks. As tasks complete, their code is integrated into the overall system and tested along with it. Either all tests pass successfully, or the code cannot be integrated into the system. During the iteration, customer-provided functional tests are added to the overall series of tests. At the end of the iteration, all tests for individual modules and all functional tests.

A task

In order to implement a task, the programmer responsible for it first of all looks for a partner, since the final code is always written by two people on the same machine. If questions arise about the subject matter or methods of implementation, the partners hold a short (15-minute) meeting with the customer and/or programmers who are knowledgeable in coding issues that are most likely to be associated with the code of this task during the implementation.

Based on the results of this meeting, programmers make a list of test cases that need to be run before the completion of the task. From the list, such a test is selected, in the implementation of which the programmers are completely confident, and with the help of which they will be able to better understand the essence of the problem. A test program is being written. If it works fine right away, you can move on. However, as a rule, it is not without problems. If the test does not work, one of the following situations is possible:

we know a simple way to make it work, and we act in this way;
we know the complicated and very frustrating way to make it work, but we understand how to re-architect the system and get the test case to work properly without too much effort. Then we decide to rework the system;
we know a difficult and unpleasant way to make it work, and see no way to overhaul the system, so we go the hard way.

After the test has worked, we may again understand how to improve the system, which we will do.

It is likely that during the implementation of the test case, we will find another test case that should also work. We bring new test to your list and continue development. Perhaps we will find that the scale of the system restructuring goes beyond the requirements of the current test, then we will fix this fact and move on. In the end, our goal is to focus on the details and successfully solve a specific problem, but at the same time not lose the general idea of \u200b\u200bthe system, which is formed during intensive work on codes.

Test

If we talk about the key method of XP, then this is, of course, unit testing. As you can see by now, unit testing is an essential part of every programmer's day-to-day work. Two features make XP's testing process much more efficient than traditional methods: programmers write their own tests, and do so before coding. Of course, if you approach programming as a gradual study of the problem, and consider the study of the problem as the most effective means feedback with a customer, you will benefit most from tests written by a third party a few days or weeks after coding is completed. XP takes into account the conventional wisdom that programmers cannot properly test their own code, and therefore requires them to work in pairs.

Some methodologies, notably Cleanroom, prohibit programmers from testing and in some cases even compiling their programs. Typically, a programmer writes code, compiles it, makes sure it works, and then submits it to some testing organization. Traditional benchmarking methods are stepping through code and variables, interpreting the results of print statements, testing menu buttons, and so on.

XP does not introduce any new testing techniques over conventional methods. It's just that testing is done in a different form, and instead of doing something that won't leave a trace after testing is completed, you create tests for the long term. These tests work today, will work on the day the system integration is completed, and the next day, and in a week, and next year. Confidence in the normal operation of each individual test gradually builds confidence among developers in the normal operation of the system as a whole.

As already noted, customers also come up with tests. At the beginning of the iteration, the customer must find those factors that will convince him that the stories for this iteration are fully implemented. He formalizes his thoughts on this in tests for the system as a whole. The customer can independently write tests using text or graphic scripting languages, or entrust them to a programmer who will use his own testing tools. Such tests also build confidence, this time, the customer's confidence in the correct operation of the system.

You have problems?

Discussing one or another programming method in conditions where it works perfectly is not difficult. It is much more interesting to know what you will do if you find yourself in an unforeseen or undesirable situation.

Reassessment of one's own abilities. At times you take on more than you can handle. It is necessary to minimize the number of such situations as much as possible, resorting to quantitative assessments of your work as often as possible. If you find yourself overwhelmed, first of all look for the cause in yourself. Analyze: perhaps you are too distracted from solving practical problems. Are you fully committed to testing, working with a partner, reworking the system and integrating? Are you doing more than what the customer needs at the moment?

If you are unable to find internal reserves to speed up development, then you should ask the customer to help you. Retaining responsibility for a scope of work that you can't guarantee is to frustrate the plan, harm the quality of the system, and finally fail completely. Don't allow yourself this. Re-evaluate your capabilities based on the experience you have gained, and then ask the customer to reconsider their requirements. If you are only able to implement two of the three stories, let him determine which stories to tackle first and which ones to keep for the next iteration or version. Is there no such story, some parts of which are more important than others? Then you can break its implementation into stages, and program the more relevant components without delay, and the less important ones a little later.

If the customer does not cooperate. Imagine a situation where the customer does not accept the rules of your game. Doesn't come up with tests, doesn't prioritize, doesn't formulate stories. First of all, try to install trusting relationship with the customer. By increasing the functionality of the system from iteration to iteration, give the customer the opportunity to control the development process. If mutual trust does not work out, analyze whether this is your fault. Are you doing everything for effective interaction with the customer?

If you are unable to resolve this issue yourself, please contact your customer for assistance. XP principles simply do not allow programmers to develop by guessing about the needs of their customers. Explain or demonstrate to the customer, using an example, the sequence of work in XP. If he does not change his attitude towards you, try to make your arguments more descriptive. If it turns out that, in essence, no one but you cares about solving this problem, perhaps this project has a low priority in the activities of the customer, and you should not insist on continuing it at all.

Staff turnover. Suppose one of the team members decided to leave it. Will you find yourself in an impasse due to the lack of necessary documents or reports? First of all, note that some staff turnover is good for the development team and its individual members. I would like, of course, that when leaving, people were guided by positive motives. If, going home at the end of the next week, the programmer sees specific positive results his activities, the likelihood of his disappointment in work and the emergence of a desire to leave is significantly reduced.

If someone leaves the XP project, this does not mean at all that he will take with him the secrets known to him alone. Each line in the system is always controlled by two people. And whatever information gets out of the workroom, it will not cause much damage to the work of the team, since the developers will be able to run the tests and check if something unexpected has happened without their knowledge.

New members of the XP team in the course of working on the first two iterations are limited to helping the more experienced partner in the pair, studying tests and communicating with the customer. Feeling greater confidence in their abilities, they will be able to take responsibility for a certain task. During the development of the next few iterations, the performance of newcomers increases so much that they are able to demonstrate to everyone the implementation of specific tasks on time. After a few months, they can no longer be distinguished from experienced team members.

A difficult problem is the programmers who are not accustomed to working in a team. XP is a hard, collaborative effort, and not everyone is able to adapt to this kind of work. It may be necessary to give up old habits, and this is not at all easy, especially for programmers who value themselves highly. But in the end, XP's many forms of feedback make it possible to pinpoint who can and cannot work on a team. If one of you constantly fails to complete a task, the integration of his modules always causes problems for other team members, he never tries to rework the system, does not work in pairs, does not conduct testing, etc. Everyone on the team will understand what's what. And the whole team will only be better off if such a person leaves, regardless of his skills and experience.

Changing requirements. The problem of problems for most development systems is not such for XP at all. Created today to solve specific problems, the XP project will cope with any changes in functionality in the future with the same efficiency. It will be easier to do something similar to what has already been done, since XP professes the principle of "formulate each thought once and only once." It is in such processing that the need arises most often. But even in the case when a completely new requirement for the system appears, you do not have to hastily build new mechanisms for its operation.

In the beginning, I didn't have a clear idea of XP's adaptability to change. In the first version of XP, the story selection process was part of version planning, and stories were assigned to all iterations in a version. The developers then discovered that with less planning effort, they could achieve best results. Therefore, now the customer is asked to specify only those stories that should be present in the next iteration. If appears new story, you put it in reserve and don't shuffle the rest of the iteration. In one or two weeks, if the new story has not lost its relevance yet, the customer will choose it.

By planning one iteration each time, we achieve gradual self-development and self-similarity of the system. On a scale of months and years, we are dealing with the histories of a given version of the system and then with the histories of future versions. On a scale of weeks and months, we are dealing with the stories of this iteration and then with the stories that remain in this version. On the scale of days and weeks, we are dealing with the task we are currently working on, and then with the tasks remaining in the iteration. Finally, on a scale of minutes and days, we are dealing with the test we are currently running, and then with other test cases that we may come up with.

Without any doubt, XP is an elegant, logically complete idea. The limits of its applicability are not yet completely clear. By taking this approach now, you must show some courage, flexibility, and a willingness to abandon the project if it fails. XP should first be tried in those projects where the benefits of this approach are obvious: in custom or in-house development of small systems, the requirements for which are not clearly defined and may well change.

If you want to experience XP, don't try to do everything at once. Choose the most annoying problem for you and try to solve it with XP. When this problem is no longer the most annoying, look for the next one and repeat the process. As you continue along the way, you will probably find that none of your old methods are working anymore. Then you can no longer contact them. This gradual onboarding process gives you a chance to develop your own style of development - which will guide you in any situation - and thereby reduce the risk of problems with XP.

XP's strong distinction between business and technical decisions goes back to the work of architect Christopher Alexander. His book The Timeless Way of Building notes that those who operate a building must be allowed to make important decisions during its construction.

XP's principles for quickly evolving a plan in line with technical and business-related changes reflect the principles of the Scrum methodology and the Episodes templating language developed by Ward Cunningham.

The idea of specifying and planning a project in terms of realizable possibilities goes back to the work of Ivar Jakobson.

Tom Gilb is an evolutionary engineering guru. His latest writings focus on getting software up and running in a matter of weeks, followed by development.

The Spiral Model by Barry Boehm was the first reaction to the obsolescence of the waterfall model. For a long time in mastering powerful technologies, no one could surpass Dave Thomas and his colleagues at Object Technology International, who created the JIT method.

The roots of the principle of metaphor used in XP can be found in the books of George Lakoff and Mark Johnson, in particular their latest work Philoslphy in the Flesh. This principle was also proposed by Richard Coine, who linked metaphor and software development in terms of postmodern philosophy.

Finally, much of XP's emphasis on office organization stems from the work of Jim Coplien, Tom DeMarco, and Tim Lister, who noted the influence of environmental conditions on the work of programmers.

Examples of executing projects using XP

Acxiom: on the way to achieving a common goal

Ji Hannula

Team: managers, business analysts, developers, testers, technical writers

Application: campaign management database

Implementation period: 3 years

Acxiom created a business management application based on the data warehouse using the Forte distributed object-oriented development toolkit. A small team of developers - only 10 people - firmly adhered to the principles of object-oriented programming and collaborative development when creating the application. Of the three years it took to develop, for the last two years the team, which included managers, business analysts, developers, testers, and technical writers, used Extreme Programming methods and that's how they succeeded.

Until recently, Acxiom considered a project to be a success if it was simple and some of the previously built systems could qualify to be part of a new application. However, it turned out that nothing good came of it. Reworking the system has become a critical element of development. We clearly realized that being afraid to change those parts of the program, the functions of which we do not yet know, we cannot be considered good developers. We let the program control us. If we didn't know what given code, we were not afraid to get into it and figure it out. Better to do it yourself certain part code than to make the entire application hostage to a separate piece of it.

A lot of effort went into unit testing because Forte doesn't offer built-in basic testing tools. We had to create our own and use them to successfully test. We recently switched to the Java programming language and now use JUnit as a testing tool.

When we first started working on the principles of XP, there were programmers among us who did not want to use his methods. They felt that these methods did not suit the programming style they had developed and would prevent them from being productive. As a result, most of the problems arose with the components of the system written by these people. These developers disregarded teamwork and became inferior in skill to other team members who took advantage of the opportunity presented to them to learn from each other. Two experienced programmers who work closely with each other and the rest of the team will always outperform the "individual" in skill, even if he is seven spans in the forehead.

We realized that every member of the team must follow the principles of XP, otherwise this approach will not work. Now we immediately warn a potential developer that if he is not satisfied with the style adopted by us, he should better look for work in another team. One person who is not interested in the chosen development method can nullify the efforts of the entire team. The essence of XP is the collective development of new ideas in the process of creating a system.

There is a misconception about HR that this approach suppresses creative activity and development of individual abilities of the developer. In fact, everything is just the opposite. XP stimulates the programmer's creative growth and gives individual team members a chance to shine. The main thing is to decide and firmly stick to the chosen direction.

"Extreme Programming" did not put our team in extreme conditions. This method uses well-known and largely familiar development approaches. Everyone works closely together and moves towards the goal together.

DaimlerChrysler: the best team in the world

Chet Hendriksen

Team: 15 people, including 10 programmers

Application: full-scale automation of payroll calculation

Implementation period: 4 years

Work on the C3 project began in January 1995. Chrysler Corporation entered into a contract with a partner company, according to which a joint development team from both organizations took on the project. Our partners followed a development methodology focused on use GUI and ignored test automation. The result was a system that was rife with unimpressive graphics and calculated the salary incorrectly for most employees. It would take about 100 days for such a system to generate a monthly payroll. We realized that the program we wrote would never really be used.

We reached out to Kent Beck to help tune the performance of the system. He found in us the same phenomena that he constantly encounters when taking on the task of performance tuning: badly designed code, tests that cannot be rerun, management that has lost confidence in its project. Kent Beck recommended throwing away all the code that was written and starting a full blown XP project.

The previous contract was terminated, and Chrysler almost half updated its development team. From that moment on, we acted according to the rules of XP. Responsibilities were assigned, iterations planned, testing rules established, pair programming tested and adopted as a standard. By the end of the 33rd week, we had a system in which we could already begin to debug performance and conduct parallel testing. We could start tweaking performance as the system was well thought out and backed up full set unit tests. We were ready for parallel testing, as a series of functional tests clearly demonstrated to the customer that the system had the required capabilities.

This phase of the C3 implementation was launched in May 1997, although we had anticipated an earlier date. The failure of our plans was due to two factors. First, we decided to replace only the internal components payment system. All external interfaces remained untouched. Match output new system components of the old one turned out to be much more challenging task than we expected. Second, we have decided not to initiate special requirements during any pay period, such as W-2 processing, profit sharing, or a general raise. wages. As a result, what should have been done in November was postponed to April.

Since the launch of the monthly payment calculation system, we have added several new features and automated biweekly payment calculation. The payroll for the pilot group has been calculated since August 1998, and we hope to have a working system for the rest of the employees by November 1999.

Based on the experience gained during this long development, I can say that we did not live up to the expectations of our management and our customers only when we deviated from the principles of XP. When the process of testing became decisive in the course of development, when we wrote code in pairs, when the simplest, most likely working functions were implemented, we turned into the best team that could be.

Ford Motor: a unique combination of efficiency and quality

Don Wells

Team: 17 people, including 12 programmers

Application: cost analysis system

Implementation period: 6 years

Ford Motor Company's financial systems division develops the Vehicle Costing and Profit System (VCAPS) analytics system, which generates reports on production revenue, expenses, net income and profit. The inputs to the system are engineering product specifications, fixed costs and expenses, and variable costs such as labor hours. VCAPS aggregates all this data and prepares detailed reports with cost analysis that enable effective forecasting and corporate decision making. Work on the VCAPS project began in 1993. Developed using VisualWorks and GemStone Smalltalk. VCAPS is currently maintained by a small team of people and will soon be replaced by a more modern application.

When implementing the VCAPS project, we had to solve two serious problems. First, analysts wanted to make changes to the system while getting new features that were already working. Requirements were constantly changing, and we just couldn't keep up with them. Secondly, there were certain restrictions on the operating time of the system. At the same time, the system spent a lot of time processing data and required manual input of long sequences. Any mistake led to the need to restart and the loss of precious time.

With XP, we have achieved a unique combination of capabilities: being able to quickly respond to constantly changing requirements and achieve a system quality that has avoided dangerous restarts.

Work on XP methods began with the planning stage. And it turned out to be a mistake. Customers and management are not accustomed to settling work schedules together. What happened as a result suffered from a lack of plausibility and practical applicability. We had to switch to MS Project plans, which could be changed without arranging general meetings, and with the help of which we received plans in the form familiar to management.

Then we did a few unit tests and after a year 40% of the system was tested, and the management noted a 40% reduction in the number of error messages. After that, XP received close attention.

We solved problems by implementing all the new XP methods. The tests allowed us to move to continuous integration and frequent version changes. This, in turn, paved the way for collective ownership and redesign of the system. We aimed to create a simple project. Finally, the moment came when we decided to try programming in pairs. And we had to work hard to achieve this success. At first, our developers found this method extremely inconvenient; It took some time to get used to and feel quite comfortable in it.

After a year and a half, the number of system failures has decreased so much that our customers and management were able to state a significantly higher system stability. For us, this symbolized the success of the XP principles.

Tariff System: tests you can read

Rob Mi

Team: three developers

Application: transportation tariff calculation system

Implementation period: 3 months

Tariff System is part of a large project implemented using SmallTalk/GemStone in one of the major international companies specializing in container transportation. The XP approach made it possible to go through all stages of the development of this subsystem, from conception to commissioning, in three months by three people. The result was remarkably stable and easy to maintain.

Starting work on the project, we immediately decided to firmly adhere to several basic principles XP: always code in pairs, keep the architecture as simple as possible, actively rework the system, and write lots of unit tests. All of these principles have proven to be effective. One XP idea seemed a little far-fetched to us at first - to write tests for the code before the actual code is written. All the more, we were surprised to find that this principle allows us to identify architectural problems and speeds up the development process.

From the very beginning, we used another XP method - collecting user requirements in the form of stories. The results were not entirely unambiguous. We are programmers and we are primarily engaged in coding, so the search common language with users has become a challenge for us. To complicate matters further, we wanted stories from users that were both relevant and unambiguous, and to do so, they had to be actively assisted. In the end, we came to the conclusion that XP was missing one special role. We needed a person whose main task would be to interact with users. Obviously, he must have the appropriate abilities.

While creating and reworking test cases, we realized that for writing basic domain objects, small languages \u200b\u200bdesigned specifically for them will be very useful, thanks to which the test code becomes much more concise and readable. In addition, we stopped wasting time inventing ways to set object instances in the process of writing tests, and defined grammars for ten domain classes. The grammar automatically generates a parser that is used by the constructor to create the domain object. The code to instantiate an object using standard constructors will be very long, almost unreadable, and bear little resemblance to the test case itself.

Extreme Programming (XP) is a simplified software development methodology for small to medium sized development teams building a software product with unclear or rapidly changing requirements.

The main goals of XP are increasing customer confidence to the software product by providing real evidence of the success of the development process development and a sharp reduction in product development time . At the same time, XP is focused on minimizing bugs in the early stages of development. This makes it possible to achieve top speed the release of the finished product and makes it possible to talk about the predictability of work. Almost all XP techniques are aimed at improving the quality of the software product.

Principles XP

The main principles are:

Iteration. Development is carried out in short iterations in the presence of an active relationship with the customer. Iterations as such are proposed to be short, the recommended duration is 2-3 weeks and no more than 1 month. In one iteration, a group of programmers must implement several features of the system, each of which is described in a user story. User stories (UI) in this case are the initial information on the basis of which the module is created. They are distinct from Use Cases (UTs). The description of the PI is short - 1-2 paragraphs, while the PI is usually described in sufficient detail, with the main and alternative flows, and is supplemented by a model. UIs are written by the users themselves, who in XP are part of the team, unlike the UIs that the system analyst describes. The lack of formalization of the description of the input data of the project in XP is sought to be compensated by the active inclusion of the customer in the development process as a full member of the team.
Simplicity of solutions. The first simplest working solution is adopted. The extreme nature of the method is associated with a high degree the risk of a decision due to the superficiality of the analysis and the rigid time schedule. The minimum set of the main functions of the system is implemented at the first and each subsequent iteration; functionality is expanded on each iteration.
Intensive development by small teams(no more than 10 people) and pair programming(when two programmers create code together at one common workplace), active communication within the group and between groups. All this is aimed at detecting problems as early as possible (both errors and missed deadlines). Pair programming is aimed at solving the problem of project stabilization. When using the XP methodology, there is a high risk of losing code due to the departure of a programmer who could not withstand 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 - XP uses an open workspace, which implies quick and free access for everyone to everyone.
Customer Feedback, whose representative is actually involved in the development process.
Sufficient degree of courage and willingness to take risks.

XP tricks (practices)

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

Process planning. The entire development team gets together, a collective decision is made about which features of the system will be implemented in the next iteration. The complexity of the implementation of each property is determined by the programmers themselves.
Close interaction with the customer. The customer representative must be a member of the XP team. He writes the UI, selects the stories that will be implemented in a particular iteration, and answers business-related questions. The customer's representative must be expert in the automated subject area. It is necessary to have constant feedback from the customer's representative.
General system naming rules. Good system naming conventions ease of naming classes and variables. The development team should have uniform naming conventions.
Simple architecture. Any property of the system should be implemented as simply as possible. Programmers in the XP team work under the motto: "Nothing more!". The first simple working solution is adopted, the required level of functionality is being implemented at the moment. This saves the programmer time.
Refactoring. This is an optimization of the existing code in order to simplify it. Such work should be carried out constantly. By keeping the code transparent and defining its elements only once, programmers reduce the number of bugs that have to be fixed later. When implementing each new property of the system, the programmer must consider whether the existing code can be simplified and how this will help to implement the new property. In addition, you cannot combine refactoring with design: if you create new code, refactoring should be postponed.
Pair programming. All programmers should work in pairs: one writes the code, the other looks. Thus, it is necessary to place a group of programmers in one place. XP works best in undistributed teams of programmers and users.
40 hour work week. The programmer should not work more than 8 hours a day. The need for overtime is a clear indicator of a problem in that particular area of development. Finding the causes of overtime and their prompt elimination is one of the basic rules.
Collective code ownership. 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 a programmer has made changes and the system does not work correctly after that, then it is this programmer who must correct the errors.
Uniform coding standards. Coding standards are needed to support other practices: code sharing, pair programming, and refactoring. Without a single standard, it is at least more difficult to perform these practices, but in reality it is generally impossible: the group will work in a mode of constant lack of time. The team has been working on the project for a long time. People come and go. No one codes alone and the code belongs to everyone. There will always be moments when it will be necessary to understand and correct someone else's code. Developers will remove duplicate code, analyze and improve other people's classes, and so on. Over time, it will not be possible to tell who the author of a particular class is. Therefore, everyone must obey common coding standards - code formatting, class, variable, constant naming, comment style. The above means that all team members must agree on common coding standards. No matter what, but everyone is obliged to obey them.
Small releases. The minimum iteration is one day, the maximum one is a month; the more often releases are made, the more flaws in the system will be revealed. The first releases help to identify deficiencies at the earliest stages, then the functionality of the system is expanded based on the UI. Since the user is included in the development process from the first release, he evaluates the system and issues a user story and comments. Based on this, the next iteration is determined, that is, what the new release will be. Everything about XP is about providing continuous feedback to users.
Continuous Integration. Integration of new parts of the system should occur as often as possible, at least once every few hours. The basic rule of integration is the following: integration can be performed if all tests pass successfully. If the tests do not pass, then the programmer must either make corrections and then integrate the components of the system, or not integrate them at all. This rule is rigid and unambiguous. If there is at least one error in the created part of the system, then integration cannot be performed. Frequent integration allows you to get a ready-made system faster, instead of spending a week on assembly.
Testing. Unlike most other methodologies, testing in XP is one of the most important components. The extreme approach assumes that tests are written before code is written . Each module must have a unit test - a test for this module. Thus, XP performs regression testing, "non-degrading quality" 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 placed in the repository if and only if all tests have passed successfully, otherwise this code change is rejected.

The XP process is informal but requires a high level of self-discipline. If this rule is not followed, then XP instantly turns into a chaotic and uncontrolled process. XP doesn't require programmers to write a lot of reports and build a lot of models. In XP, every programmer is considered a skilled worker who is professional and responsible for his duties. If the team does not have this, then it is absolutely pointless to implement XP - it is better to start rebuilding the team. Development risk is reduced only in a team that is ideally suited to XP, in all other cases XP is the development process with the highest degree of risk, since there are simply no other methods to reduce commercial risks, except for the human factor, in XP.

And others.

The name of the methodology comes from the idea of applying useful traditional methods and software development practices, raising them to a new "extreme" level. So, for example, the practice of performing a code revision, which consists in checking by one programmer the code written by another programmer, in the "extreme" version is "pair programming", when one programmer is coding, and his partner at the same time continuously reviews the newly written the code.

Encyclopedic YouTube

1 / 5

Extreme Programming (XP) - Basic Techniques

Hexlet Webinar #6: Extreme Programming

life tips. Why participate in programming competitions?

032. Pair programming - Sergey Berezhnoy

Extreme Programming Channel v. 2.0

Subtitles

XP basic tricks

The Twelve Basic Techniques of Extreme Programming (according to the first edition of the book Extreme programming explained) can be grouped into four groups:

Short feedback cycle (Fine-scale feedback)
- Development through testing (Test-driven development)
- Planning game
- The customer is always there (Whole team, Onsite customer)
- Pair programming
Continuous, not batch process
- Continuous integration
- Refactoring (Design improvement, Refactoring)
- Frequent small releases
An understanding shared by all
- Simplicity
- System metaphor
- Collective code ownership or selected design patterns (Collective patterns ownership)
- Coding standard or Coding conventions
Social security of the programmer (Programmer welfare):
- 40-hour work week (Sustainable pace, Forty-hour week)

Testing

XP involves writing automated tests (program code written specifically to test the logic of another program code). Particular attention is paid to two types of testing:

unit testing of modules;

A developer cannot be sure of the correctness of the code he writes until absolutely all unit tests of the system he develops work. Unit tests (unit tests) allow developers to make sure that each of them individually works correctly. They also help other developers understand why a particular piece of code is needed and how it functions - in the course of studying the test code, the logic of the code under test becomes clear, as it is clear how it should be used. Unit tests also allow the developer to refactor without any fear.

Functional tests are designed to test the functioning of the logic formed by the interaction of several (often quite impressive size) parts. They are less detailed than unit tests, but they cover a lot more - that is, tests that, in their execution, affect a larger amount of code, obviously have a greater chance of detecting any incorrect behavior. For this reason, in industrial programming, writing functional tests often takes precedence over writing unit tests.

For XP, an approach called TDD (from the English test-driven development - development through testing) is a higher priority. In accordance with this approach, a test is first written that initially fails (since the logic that it should check simply does not exist yet), then the logic necessary for the test to pass is implemented. TDD, in a sense, allows you to write code that is more convenient to use - because when writing a test, when there is no logic yet, it is easiest to take care of the convenience of the future system.

The planning game

The main goal of the planning game is to quickly form a rough work plan and constantly update it as the conditions of the task become clearer. The artifacts of the planning game are a set of paper cards that contain the customer's wishes (customer stories) and a rough work plan for the release of the next one or more small versions of the product. The critical factor that makes this planning style effective is that in this case the customer is responsible for making business decisions and the development team is responsible for making technical decisions. If this rule is not followed, the whole process falls apart.

The customer is always there

The "customer" in XP is not the one who pays the bills, but the end user of the software product. XP claims that the customer must be in touch all the time and available for questions.

Pair programming

Pair programming assumes that all code is created by pairs of programmers working on the same computer. One of them works directly with the text of the program, the other looks at his work and follows the overall picture of what is happening. If necessary, the keyboard is freely transferred from one to another. While working on a project, the pairs are not fixed: it is recommended to mix them up so that each programmer in the team has a good idea of the whole system. In this way, pair programming enhances the interaction within the team.

Continuous Integration

If you integrate the system under development often enough, you can avoid most of the problems associated with it. In traditional methods, integration, as a rule, is performed at the very end of the work on the product, when it is considered that all the components of the system being developed are completely ready. In XP, code integration of the entire system is performed several times a day, after the developers have made sure that all unit tests work correctly.

Refactoring

Refactoring is a technique for improving code without changing its functionality. XP implies that once code is written, it will almost certainly be redone many times during the course of a project. The XP developers are ruthlessly reworking previously written code in order to improve it. This process is called refactoring. The lack of test coverage provokes the rejection of refactoring due to the fear of breaking the system, which leads to the gradual degradation of the code.

Frequent small releases

Versions (releases) of the product should go into production as often as possible. Work on each version should take as little time as possible. At the same time, each version should be meaningful enough in terms of usefulness for business.

The earlier the first working version of the product is released, the earlier the customer begins to receive additional profit due to it. Remember that money earned today is worth more than money earned tomorrow. The sooner the customer starts using the product, the sooner the developers will receive information from him about what meets the requirements of the customer. This information can be extremely helpful when planning your next release.

Ease of Design

XP proceeds from the fact that in the course of work, the conditions of the problem can change repeatedly, which means that the product being developed should not be designed in advance entirely and completely. Trying to design the system in detail at the very beginning of work is a waste of time. XP suggests that design is such an important process that it must be done continuously throughout the life of the project. Design should be carried out in small steps, taking into account constantly changing requirements. At each point in time, you should try to use the simplest design that suits the current problem, and change it as the conditions of the problem change.

System metaphor

Architecture is a representation of the components of a system and their interrelationships. Developers need to analyze the software architecture in order to understand where in the system they need to add new functionality and what the new component will interact with.

Choosing a good metaphor makes it easier for the development team to understand how the system works. Sometimes this is not easy to do.

Encoding standards

All team members must comply with the requirements of common coding standards in the course of work. Thereby:

team members do not waste time arguing about things that actually do not affect the speed of work on the project;
the effective implementation of other practices is ensured.

If the team does not use uniform coding standards, it becomes more difficult for developers to refactor; when changing partners in pairs, there are more difficulties; in general, the progress of the project is difficult. Within the framework of XP, it is necessary to ensure that it is difficult to understand who is the author of this or that piece of code - the whole team works in a unified manner, like one person. The team must form a set of rules, and then each team member must follow these rules during the coding process. The list of rules should not be exhaustive or too voluminous. The task is to formulate general guidelines that will make the code understandable for each of the team members. A coding standard should be simple at first, then it can gradually become more complex as the development team gains experience. There is no need to spend too much time pre-drafting a standard.

Collective ownership

Collective ownership means that each team member is responsible for all source code. Thus, everyone has the right to make changes to any part of the program. Pair programming supports this practice: working in different pairs, all programmers become familiar with all parts of the system's code. An important benefit of collective code ownership is that it speeds up the development process, because when a bug occurs, any programmer can fix it.

Just about the complex. Programs. Iron. Internet. Windows

The process of programming effective actions in extreme conditions. Unified development process and extreme programming. At any given time, the system should be designed as simply as possible. Do not need extra

The planning game

Release plan

Iteration planning

Standing meeting

Simplicity

Metaphor system

Customer at work site

Testing before development

Pair programming

Change of positions

Collective code ownership

Coding convention

Frequent integration

Forty hour work week

Conclusion

Anatomy of XP

XP development cycle

Stories

Version

Iteration

A task

Test

You have problems?

Examples of executing projects using XP

Acxiom: on the way to achieving a common goal

DaimlerChrysler: the best team in the world

Ford Motor: a unique combination of efficiency and quality

Tariff System: tests you can read

Encyclopedic YouTube

Subtitles

XP basic tricks

Testing

The planning game

The customer is always there

Pair programming

Continuous Integration

Refactoring

Frequent small releases

Ease of Design

System metaphor

Encoding standards

Collective ownership