Methods and principles of extreme programming
Extreme Programming (Extreme Programming, XP) is one of the flexible software development methodologies. The authors of the methodology are Kent Beck, Ward Cunningham, Martin Fowler and others.
Our world is too volatile and unpredictable to rely on the constancy of the situation. The same thing happens with software development: a rare system can be said that its final form was previously known in detail at the very beginning of development. Usually, the customer comes with an appetite while eating: he always wants to change something, improve something, and throw something out of the system. This is the variability of demands that everyone is so afraid of. Fortunately, the person is given the ability to predict possible options and, thus, to keep the situation under control.
In extreme programming, planning is an integral part of the development and the fact that plans can change is taken into account from the very beginning. That point of support, a technique that allows you to predict a situation and put up with changes without serious consequences, is a planning game. In the course of such a game, you can quickly assemble known system requirements, evaluate and plan their development in accordance with priority.
Like any other game, planning has its participants and its goal. The key figure is, of course, the customer. It is he who reports the need for this or that functionality. Programmers 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 the victory in his own way: the customer selects the most important tasks in accordance with the budget, and the programmer evaluates the tasks in accordance with their capabilities for their implementation.
Extreme programming assumes that developers are able to decide for themselves over what period of time they will cope with their tasks and which of them would be more willing to solve one task, and who the other.
In an ideal situation, a planning game involving a customer and a programmer should be conducted every 3-6 weeks, before the next iteration of the development begins. This makes it quite easy to make adjustments in accordance with the successes and failures of the previous iteration.
The release plan determines the release dates and the wording of the users, which will be implemented in each of them. Based on this, you can choose the wording for the next iteration. During the iteration, acceptance tests are made that are performed within this iteration and all subsequent ones to ensure the correct operation of the program. The plan may be revised in the event of a significant lag or advance following one of the iterations.
Iterations Iterations make the development process dynamic. No need to plan your software tasks for a long time to come. It is better to arrange a meeting for planning at the beginning of each iteration instead. Do not even try to implement what was not planned. You will still have time to implement these ideas when the turn comes according to the release plan.
By getting used to, not adding functionality in advance and using immediate planning, you can easily adapt to changing customer requirements.
Planning of iterations begins with a meeting at the beginning of each iteration in order to develop a plan of steps for solving program tasks. Each iteration should last from one to three weeks. The wording within the iteration is sorted in order of importance to the customer. In addition, tasks are added that could not pass the acceptance tests and need to be improved. Formulations and test results are translated into software tasks. Tasks are recorded on cards that form a detailed iteration plan. To solve each of the tasks required from one to three days. Tasks that require less than one day can be grouped together, and large tasks can be divided into several smaller ones. Developers evaluate tasks and deadlines for their implementation. It is very important for the developer to set the exact time of the task. It may be necessary to overestimate some formulations and revise the release plan after every three or five iterations — this is perfectly acceptable. If you primarily implement the most important areas of work, then you will always have time to do the maximum possible for your customers. Development style based on iteration sequence improves development process.
')
Every morning, a meeting is held to discuss the problems, their solutions and to increase the concentration of the team. The meeting is held standing to avoid long discussions not interesting to all team members.
In a typical meeting, most of the participants contribute nothing, just participate to hear what others say. A large amount of time people spend to get 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 and need a meeting of standing. It is much better to have one short mandatory meeting than many long ones at which most developers should still be present.
If your daily meetings are held standing, then all other meetings should be attended only by those people who are necessary and will contribute something. Moreover, it is possible to even avoid some meetings. With the restriction of participants, the majority of meetings can be held spontaneously in front of the monitor, where the exchange of ideas is much more intense.
A daily morning meeting is not another waste of time. It will allow you to avoid many other meetings and save you more time than you spent on it.
A simple design always takes less time than a complex one. Therefore, always do the simplest things that can only work. It is always faster and cheaper to replace a complex code immediately before you spend a lot of time working with it. Keep things as simple as possible, without adding functionality before it is planned. Keep in mind: keeping the design simple is hard work.
The choice of a system of metaphors is needed to keep the team in the same framework when naming classes and methods. The way you name your objects is very important for understanding the overall design of the system and reusing codes. If the developer is able to correctly predict what an existing object can be called, this will save time. Use a name system for your objects that everyone can understand without specific knowledge of the system.
The main problem of software development is the lack of knowledge of programmers in the developed subject area. Extreme programming has found a way out of this situation. No, this is not a developer's internship at the customer’s enterprise — he will not want to program then. 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 question and not being a telepath, guess what the customer wants? The answer is obvious. The easiest way to overcome this inconvenience - and extreme programming teaches us to find the simplest solutions - will ask the customer a direct question. More rigorous approaches require a comprehensive preliminary analysis of the field 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 requirements are currently collected, there will still be one bottleneck: programs, like everything else in nature, are not created instantly, but in the meantime business processes may change. This should be considered.
Many doubt the ability to attract customers to the development process. Indeed, customers are different. If it is not possible to attract a customer or his representative, it is sometimes advisable 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. This can 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 has a logical meaning from the point of view of the Customer. Form one or two paragraphs of text understandable to the user (not very technical).
User Story is written by the Customer. They are similar to system usage scenarios, but are not limited to the user interface. For each story, functional tests are written, confirming that the story is correctly implemented - they are also called Acceptance tests.
Testing, in its classic 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 the opportunity to change jobs appears.
In extreme programming, the role of testing is more interesting: now at first there is a test, and then a code. How to test what is not yet? The answer is simple and trivial: test your thoughts - what to expect from a future piece of program or functionality. This will allow a better understanding of what programmers need to do, and test the functionality of the code as soon as it is written.
But the test may not work either. Well, write a test for the test? And then the test for the test, and so on to infinity? 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 are they doing for this? Screw the second nut close to the first, so that each nut does not allow the neighboring one to turn. It is the same in programming: the test tests the code, and the code tests the test.
Experience shows that such an approach not only does not slow down, but also speeds up development. After all, the knowledge of what needs to be done and the required amount of work will save time by refusing to sell the unclaimed parts at the moment.
All code for the production system is written in pairs. Two developers are sitting next to each other. One is gaining, the other is looking. They change from time to time. Not allowed to work alone. If for some reason the second of the couple missed something (was sick, departed, etc.), he is obliged to review all the changes made first.
It sounds unusual, but after a short period of adaptation, most people work fine in pairs. They even like it, because the work is done much faster. The principle of "One head is good, but two is better." Couples usually find better solutions. In addition, the quality of the code increases significantly, the number of errors decreases, and the exchange of knowledge between developers is accelerated. While one person focuses on a strategic idea of ​​an object, the second implements its properties and methods.
During the next iteration, all workers should be moved to new areas of work. Such movements are necessary to avoid the isolation of knowledge and eliminate “bottlenecks”. Particularly fruitful is the replacement of one of the developers with pair programming.
Collective ownership of the code encourages developers to submit ideas for all parts of the project, not just for their modules. Any developer can modify any code to extend the functionality and correct errors.
At first glance, it looks like chaos. However, taking into account that at least any code was created by a couple of developers, that tests allow checking the correctness of the changes made and that in real life one way or another still has to understand another's code, it becomes clear that collective ownership of the code greatly simplifies making changes and reduces the risk associated with the high specialization of a team member.
You are in a team that has been working on this project for a long time. People come and go. Nobody encodes 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 modify duplicate code, analyze and improve other people's classes, etc. Over time, you can not tell who the author of a particular class.
Therefore, everyone should follow the general coding standards - code formatting, naming of classes, variables, constants, style of comments. Thus, we will be sure that by making changes to someone else's code (which is necessary for aggressive and extreme progress), we will not turn it into the Babylon Towering.
The above means that all team members must agree on common coding standards. No matter what. The rule is that everyone obeys them. Those who do not want to comply with them leave the team.
Developers should, if possible, integrate and release their code every few hours. In any case, you can never keep changes longer than one day. Frequent integration avoids alienation and fragmentation in development, when developers cannot communicate in the sense of sharing ideas or reusing code. Everyone should work with the latest version.
Each pair of developers must give away their code as soon as a reasonable opportunity arises. This may be when all UnitTests are 100% complete. By giving changes several times a day, you reduce integration problems to almost nothing. Integration is an activity of the “pay now or pay more later” type. Therefore, by integrating changes daily in small portions, you will not be faced with the need to spend a week to tie the system into one immediately before the delivery of the project. Always work on the latest version of the system.
A person, especially if he is a programmer, is capable of many things for the sake of things: linger at work, go to work for the weekend, refuse to leave, do not sleep for several days sitting at the keyboard ... In general, what can you not do for the sake of your favorite activity. But extreme programming is categorically against such self-sacrifice and violation of accepted norms of labor law.
This is dictated not only by considerations of legality and humanity, but - first and foremost - by the need to improve work efficiency and strict organization. After all, extreme programming is a collective game designed not for individuals, but for the whole group. And such a thing as, for example, pair programming, is possible only with synchronization of the biorhythms of its participants. And it is impossible if one person comes to work at nine, and the second to twelve, or one decides that it is better for him to work on Saturday and Sunday, and the other is uncomfortable.
But the most important thing is that a person needs a good rest in order to maintain his health and performance. The eight-hour working day and the five-day working week are established precisely for reasons of maximum productivity. In many Western firms, late departure from work is regarded as failure or inability to properly manage their working time. In most cases it is. And from a medical point of view, delays at work lead to constant fatigue, irritability and a decrease in brain activity. Is it effective? And how in such a team to organize a constant open communication between developers, and whether it will be possible to pair programming? The answer is negative. Norms are norms, and they are worth adhering to.
These techniques are collected together not by chance. Their consistent aggregate is capable of introducing the development process into an intellectual resonance, markedly increasing the quality of the product and bringing its release time closer. The main charm of all extreme programming is predictability and minimizing development costs; providing the customer with the product he wishes to receive at the time of release; and of course, communication and training of developers on the job.
Bibliography:
Planning game
Our world is too volatile and unpredictable to rely on the constancy of the situation. The same thing happens with software development: a rare system can be said that its final form was previously known in detail at the very beginning of development. Usually, the customer comes with an appetite while eating: he always wants to change something, improve something, and throw something out of the system. This is the variability of demands that everyone is so afraid of. Fortunately, the person is given the ability to predict possible options and, thus, to keep the situation under control.
In extreme programming, planning is an integral part of the development and the fact that plans can change is taken into account from the very beginning. That point of support, a technique that allows you to predict a situation and put up with changes without serious consequences, is a planning game. In the course of such a game, you can quickly assemble known system requirements, evaluate and plan their development in accordance with priority.
Like any other game, planning has its participants and its goal. The key figure is, of course, the customer. It is he who reports the need for this or that functionality. Programmers 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 the victory in his own way: the customer selects the most important tasks in accordance with the budget, and the programmer evaluates the tasks in accordance with their capabilities for their implementation.
Extreme programming assumes that developers are able to decide for themselves over what period of time they will cope with their tasks and which of them would be more willing to solve one task, and who the other.
In an ideal situation, a planning game involving a customer and a programmer should be conducted every 3-6 weeks, before the next iteration of the development begins. This makes it quite easy to make adjustments in accordance with the successes and failures of the previous iteration.
Release plan
The release plan determines the release dates and the wording of the users, which will be implemented in each of them. Based on this, you can choose the wording for the next iteration. During the iteration, acceptance tests are made that are performed within this iteration and all subsequent ones to ensure the correct operation of the program. The plan may be revised in the event of a significant lag or advance following one of the iterations.
Iterations Iterations make the development process dynamic. No need to plan your software tasks for a long time to come. It is better to arrange a meeting for planning at the beginning of each iteration instead. Do not even try to implement what was not planned. You will still have time to implement these ideas when the turn comes according to the release plan.
By getting used to, not adding functionality in advance and using immediate planning, you can easily adapt to changing customer requirements.
Iteration planning
Planning of iterations begins with a meeting at the beginning of each iteration in order to develop a plan of steps for solving program tasks. Each iteration should last from one to three weeks. The wording within the iteration is sorted in order of importance to the customer. In addition, tasks are added that could not pass the acceptance tests and need to be improved. Formulations and test results are translated into software tasks. Tasks are recorded on cards that form a detailed iteration plan. To solve each of the tasks required from one to three days. Tasks that require less than one day can be grouped together, and large tasks can be divided into several smaller ones. Developers evaluate tasks and deadlines for their implementation. It is very important for the developer to set the exact time of the task. It may be necessary to overestimate some formulations and revise the release plan after every three or five iterations — this is perfectly acceptable. If you primarily implement the most important areas of work, then you will always have time to do the maximum possible for your customers. Development style based on iteration sequence improves development process.
')
Standing meeting
Every morning, a meeting is held to discuss the problems, their solutions and to increase the concentration of the team. The meeting is held standing to avoid long discussions not interesting to all team members.
In a typical meeting, most of the participants contribute nothing, just participate to hear what others say. A large amount of time people spend to get 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 and need a meeting of standing. It is much better to have one short mandatory meeting than many long ones at which most developers should still be present.
If your daily meetings are held standing, then all other meetings should be attended only by those people who are necessary and will contribute something. Moreover, it is possible to even avoid some meetings. With the restriction of participants, the majority of meetings can be held spontaneously in front of the monitor, where the exchange of ideas is much more intense.
A daily morning meeting is not another waste of time. It will allow you to avoid many other meetings and save you more time than you spent on it.
Simplicity
A simple design always takes less time than a complex one. Therefore, always do the simplest things that can only work. It is always faster and cheaper to replace a complex code immediately before you spend a lot of time working with it. Keep things as simple as possible, without adding functionality before it is planned. Keep in mind: keeping the design simple is hard work.
System metaphors
The choice of a system of metaphors is needed to keep the team in the same framework when naming classes and methods. The way you name your objects is very important for understanding the overall design of the system and reusing codes. If the developer is able to correctly predict what an existing object can be called, this will save time. Use a name system for your objects that everyone can understand without specific knowledge of the system.
Customer on the job site
The main problem of software development is the lack of knowledge of programmers in the developed subject area. Extreme programming has found a way out of this situation. No, this is not a developer's internship at the customer’s enterprise — he will not want to program then. 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 question and not being a telepath, guess what the customer wants? The answer is obvious. The easiest way to overcome this inconvenience - and extreme programming teaches us to find the simplest solutions - will ask the customer a direct question. More rigorous approaches require a comprehensive preliminary analysis of the field 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 requirements are currently collected, there will still be one bottleneck: programs, like everything else in nature, are not created instantly, but in the meantime business processes may change. This should be considered.
Many doubt the ability to attract customers to the development process. Indeed, customers are different. If it is not possible to attract a customer or his representative, it is sometimes advisable 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. This can 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 has a logical meaning from the point of view of the Customer. Form one or two paragraphs of text understandable to the user (not very technical).
User Story is written by the Customer. They are similar to system usage scenarios, but are not limited to the user interface. For each story, functional tests are written, confirming that the story is correctly implemented - they are also called Acceptance tests.
Testing before development
Testing, in its classic 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 the opportunity to change jobs appears.
In extreme programming, the role of testing is more interesting: now at first there is a test, and then a code. How to test what is not yet? The answer is simple and trivial: test your thoughts - what to expect from a future piece of program or functionality. This will allow a better understanding of what programmers need to do, and test the functionality of the code as soon as it is written.
But the test may not work either. Well, write a test for the test? And then the test for the test, and so on to infinity? 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 are they doing for this? Screw the second nut close to the first, so that each nut does not allow the neighboring one to turn. It is the same in programming: the test tests the code, and the code tests the test.
Experience shows that such an approach not only does not slow down, but also speeds up development. After all, the knowledge of what needs to be done and the required amount of work will save time by refusing to sell the unclaimed parts at the moment.
Pair programming
All code for the production system is written in pairs. Two developers are sitting next to each other. One is gaining, the other is looking. They change from time to time. Not allowed to work alone. If for some reason the second of the couple missed something (was sick, departed, etc.), he is obliged to review all the changes made first.
It sounds unusual, but after a short period of adaptation, most people work fine in pairs. They even like it, because the work is done much faster. The principle of "One head is good, but two is better." Couples usually find better solutions. In addition, the quality of the code increases significantly, the number of errors decreases, and the exchange of knowledge between developers is accelerated. While one person focuses on a strategic idea of ​​an object, the second implements its properties and methods.
Changing positions
During the next iteration, all workers should be moved to new areas of work. Such movements are necessary to avoid the isolation of knowledge and eliminate “bottlenecks”. Particularly fruitful is the replacement of one of the developers with pair programming.
Collective possession of code
Collective ownership of the code encourages developers to submit ideas for all parts of the project, not just for their modules. Any developer can modify any code to extend the functionality and correct errors.
At first glance, it looks like chaos. However, taking into account that at least any code was created by a couple of developers, that tests allow checking the correctness of the changes made and that in real life one way or another still has to understand another's code, it becomes clear that collective ownership of the code greatly simplifies making changes and reduces the risk associated with the high specialization of a team member.
Coding Agreement
You are in a team that has been working on this project for a long time. People come and go. Nobody encodes 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 modify duplicate code, analyze and improve other people's classes, etc. Over time, you can not tell who the author of a particular class.
Therefore, everyone should follow the general coding standards - code formatting, naming of classes, variables, constants, style of comments. Thus, we will be sure that by making changes to someone else's code (which is necessary for aggressive and extreme progress), we will not turn it into the Babylon Towering.
The above means that all team members must agree on common coding standards. No matter what. The rule is that everyone obeys them. Those who do not want to comply with them leave the team.
Frequent integration
Developers should, if possible, integrate and release their code every few hours. In any case, you can never keep changes longer than one day. Frequent integration avoids alienation and fragmentation in development, when developers cannot communicate in the sense of sharing ideas or reusing code. Everyone should work with the latest version.
Each pair of developers must give away their code as soon as a reasonable opportunity arises. This may be when all UnitTests are 100% complete. By giving changes several times a day, you reduce integration problems to almost nothing. Integration is an activity of the “pay now or pay more later” type. Therefore, by integrating changes daily in small portions, you will not be faced with the need to spend a week to tie the system into one immediately before the delivery of the project. Always work on the latest version of the system.
Forty hour week
A person, especially if he is a programmer, is capable of many things for the sake of things: linger at work, go to work for the weekend, refuse to leave, do not sleep for several days sitting at the keyboard ... In general, what can you not do for the sake of your favorite activity. But extreme programming is categorically against such self-sacrifice and violation of accepted norms of labor law.
This is dictated not only by considerations of legality and humanity, but - first and foremost - by the need to improve work efficiency and strict organization. After all, extreme programming is a collective game designed not for individuals, but for the whole group. And such a thing as, for example, pair programming, is possible only with synchronization of the biorhythms of its participants. And it is impossible if one person comes to work at nine, and the second to twelve, or one decides that it is better for him to work on Saturday and Sunday, and the other is uncomfortable.
But the most important thing is that a person needs a good rest in order to maintain his health and performance. The eight-hour working day and the five-day working week are established precisely for reasons of maximum productivity. In many Western firms, late departure from work is regarded as failure or inability to properly manage their working time. In most cases it is. And from a medical point of view, delays at work lead to constant fatigue, irritability and a decrease in brain activity. Is it effective? And how in such a team to organize a constant open communication between developers, and whether it will be possible to pair programming? The answer is negative. Norms are norms, and they are worth adhering to.
Conclusion
These techniques are collected together not by chance. Their consistent aggregate is capable of introducing the development process into an intellectual resonance, markedly increasing the quality of the product and bringing its release time closer. The main charm of all extreme programming is predictability and minimizing development costs; providing the customer with the product he wishes to receive at the time of release; and of course, communication and training of developers on the job.
Bibliography:
- Wikipedia
- Extreme Programming / K. Auer, R. Miller - St. Petersburg .: Peter, 2004. - 368 pp., Ill.
Source: https://habr.com/ru/post/197760/
All Articles