Methods and principles of extreme programming. Within XP, incremental planning is used, as a result of which the overall project plan emerges quite quickly, but it is understood that this plan evolves throughout the entire project.

Submitted by on Wed, 01/25/2012 - 02:28

7. Adaptive development process models: Scrum

Currently, they are becoming more widespread adaptive or lightweight e, “live” (agile) development processes
They do not require such strict regulation, admit possibility of frequent and significant changes in customer requirements

Adaptive Processes focus on using good developers rather than well-established development processes
They avoid fixing clear patterns of action to provide greater flexibility in each specific project and do not require the development of additional intermediate documents

Principles of live development

Basic principles of live software development recorded in the manifesto that appeared in 2000: =

The people involved in a project and their communication are more important than processes and tools
A working program is more important than comprehensive documentation
Cooperation with the customer is more important than discussing contract details
Working through changes is more important than sticking to plans

Extreme Programming

The most commonly used adaptive model is extreme programming model(eXtreme Programming, XP process)
XP process oriented into small and medium-sized teams developing software under conditions of uncertain or rapidly changing requirements

XP Process (Extreme Programming)

The basic idea of the XP process – eliminate the high cost of making changes. This is achieved by sharply (up to two weeks) reducing the duration of individual iterations.
The basic actions of xp are:=

coding,
testing,
listening to the customer,
design

XP Principles

High dynamism development is ensured by the following principles:=

continuous communication with the customer,
simplicity of the chosen solutions,
fast feedback based on operational testing,
risk prevention

XP development practices

The implementation of these principles is achieved by using the following methods:=

Metaphor– all development is based on a simple, publicly available story about how the system works
Simple design– the simplest possible design solutions are adopted
Continuous testing both individual modules and the system as a whole; the input criterion for writing code is a failed test case
Reorganization(Refactoring) - improving the structure of the system while maintaining its behavior
Pair programming e – code is written by two programmers on one computer
Collective code ownership– any developer can improve the code of any system module
Continuous Integration – the system is integrated as often as possible; Continuous regression testing ensures functionality remains the same as requirements change
Local customer– a competent representative of the customer must be in the group at all times
Coding Standards– rules must be followed to ensure the same presentation of code in all parts of the system

XP development diagram

XP image (XP development diagram):

Scrum model

Is another example of an adaptive development process (we previously looked at)
The main ideas of the model were formulated by Hirotaka Takeuchi and Ikujiro Nonaka in 1986

The main idea of the Scrum model

Experimental fact: projects worked on by small, cross-functional teams tend to systematically produce better results

Takeuki and Nonata explained it as "rugby approach" and introduced the term itself

"scrum"- “crush; scrum around the ball (in rugby)"

The Scrum method was first presented in documented form in 1996 jointly by Sutherland and Schwaber

Roles

ScrumMaster, the one who deals with processes and works as a project manager,
Product Owner, a person who represents the interests of end users and other parties interested in the product,
Team, which includes developers

Development stages

The development process is broken down into separate stages of a certain duration - sprints(usually 15-30 days)
Every sprint preceded by a stage called product backlog– documenting work requests

Sprint planning

Work requests are determined during the Sprint Planning Board stage − sprint planning meeting

Sprint planning
During this meeting, the Product Owner informs about the tasks that need to be completed
The team determines how much of what they want to accomplish to complete the required parts during the next sprint

Executing a sprint

During a sprint, the team completes a specific fixed list of tasks - backlog items, increasing the functionality of the software product

During this period no one has the right to change the list of job requirements, which should be understood as freezing requirements during a sprint

Scrum diagram =

text of the reference answer (I do not position it as mandatory)

Extreme Programming

Basic XP Techniques

· Short feedback cycle (Fine scale feedback)

o Test driven development

o Planning game

o The customer is always nearby (Whole team, Onsite customer)

o Pair programming

Continuous rather than batch process

o Continuous Integration

o Refactoring (Design Improvement, Refactor)

o Frequent Small Releases

· Understanding shared by all

o Simplicity (Simple design)

o System metaphor

o Collective code ownership or selected design patterns (Collective patterns ownership)

o Coding standard or Coding conventions

· Programmer welfare:

o 40-hour work week (Sustainable pace, Forty hour week)

Testing

XP places particular emphasis on two types of testing:

· unit testing;

· acceptance testing.

A developer cannot be sure of the correctness of the code he has written until absolutely all tests of the modules of the system he is developing have worked. 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 worries.

Acceptance tests ensure that the system actually has the stated capabilities. In addition, acceptance tests allow you to verify the correct functioning of the product being developed.

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

Planning game

The main goal of the planning game is to quickly formulate a rough work plan and constantly update it as the problem conditions become clearer. The artifacts of the planning game are a set of paper cards on which customer wishes are written down (customer stories), and a rough work plan for releasing the next one or more small versions of the product. The critical factor that makes this style of planning 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 one who actually uses the system. XP states that the customer must be in touch at all times and available for questions.

Pair programming

Pair programming involves all the code being created by pairs of programmers working on the same computer. One of them works directly with the program text, the other looks at its work and monitors 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 on the team has a good understanding of the entire system. In this way, pair programming enhances collaboration within the team.

Continuous Integration

If you integrate the system you are developing often enough, you can avoid most of the problems associated with it. In traditional methods, integration is usually performed at the very end of work on a 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 are confident that all unit tests are firing correctly.

Refactoring

This is a technique for improving code without changing its functionality. XP means that once code is written, it will almost certainly be rewritten several times during the course of a project. XP developers ruthlessly rework previously written code in order to improve it. This process is called refactoring. The lack of test coverage provokes a refusal to refactor due to the fear of breaking the system, which leads to gradual degradation of the code.

Frequent small releases

Versions (releases) of the product should be released into service as often as possible. Each version should take as little time as possible to complete. Moreover, each version must be sufficiently meaningful in terms of usefulness for business.

The sooner we release the first working version of the product, the sooner the customer will begin to receive additional profit from 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 customer's requirements. This information can be extremely helpful when planning your next release.

Simplicity of design

XP proceeds from the fact that during the process of work, the conditions of the problem can change repeatedly, which means that the product being developed should not be designed in advance in its entirety. If you try to design a system in detail from start to finish when you first start, you're wasting your time. XP assumes that design is such an important process that it must be done continuously throughout the project. Design must be carried out in small steps, taking into account constantly changing requirements. At each moment we try to use the simplest design that is suitable for solving the current problem. At the same time, we change it as the conditions of the problem change.

System metaphor

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

The system metaphor is an analogue of what is called architecture in most techniques. The system metaphor gives the team a sense of how the system currently operates, where new components are being added, and what form they should take.

By choosing a good metaphor, you make it easier for your team to understand how your system works. Sometimes this is not easy to do.

Coding Standards

All team members must adhere to common coding standards while working. Thereby:

· team members do not waste time on stupid arguments about things that actually do not affect the speed of work on the project;

· ensures effective implementation of other practices.

If a team doesn't use consistent coding standards, it becomes more difficult for developers to refactor; when changing partners in couples, more difficulties arise; in general, the progress of the project is becoming difficult. Within XP, it is necessary to ensure that it is difficult to understand who is the author of this or that piece of code - the entire team works unifiedly, like one person. The team must form a set of rules, and then each team member must follow those rules during the coding process. The list of rules should not be exhaustive or too lengthy. The goal is to provide general guidelines that make the code understandable to everyone on the team. The coding standard should start out simple and then evolve as the team gains experience. You should not spend too much time on the preliminary development of the 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 advantage of shared code ownership is that it speeds up the development process, since if an error occurs, any programmer can fix it.

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

Scrum is a set of principles on which the development process is built, allowing, in strictly fixed short periods of time (sprints from 2 to 4 weeks), to provide the end user with working software with new features for which the highest priority has been determined. Software capabilities for implementation in the next sprint are determined at the beginning of the sprint at the planning stage and cannot change throughout its entire duration. At the same time, the strictly fixed short duration of the sprint gives the development process predictability and flexibility.

The main acting roles in Scrum: ScrumMaster is the one who leads Scrum meetings and ensures that all Scrum principles are followed (the role does not imply anything other than the correct conduct of Scrum itself, the project manager is more likely to be a Product Owner and should not be a ScrumMaster) ; Product Owner - a person who represents the interests of end users and other parties interested in the product; and a cross-functional Team (Scrum Team), consisting of both developers and testers, architects, analysts, etc. (the ideal team size is 7±2 people). The team is the only fully involved participant in the development, and is responsible for the result as a single whole. No one other than the team can interfere with the development process during the sprint.

During each sprint, functional growth of the software is created. The set of features that are delivered in each sprint comes from a stage called the product backlog, which has the highest priority in terms of the level of work requirements that must be completed. Backlog items identified during the sprint planning meeting are moved to the sprint stage. During this meeting, the Product Owner communicates the tasks that need to be completed. The Team then determines how much of what they want to accomplish to complete the required parts during the next sprint. During a sprint, the team completes a certain fixed list of tasks (the so-called sprint backlog). During this period, no one has the right to change the list of work requirements, which should be understood as freezing requirements during the sprint.

_____________
Mathematics Faculty of VSU and other classics =)

Extreme Programming is a methodology for rapid software development. It consists of a set of techniques and principles that allow, both individually and in combination, to optimize the development process. This approach also regulates the rights of developers and customers.

Rights and roles

In Extreme Programming, all roles are clearly described. Each role comes with a characteristic set of rights and responsibilities. There are two key roles here: the customer and the developer.

Customer

A person or group of people interested in creating a specific software product. He has the following rights and obligations:

fix the release dates for product versions;
make decisions regarding the planned components of the program;
know the estimated cost of each functional component;
make important business decisions;
know the current state of the system;
change system requirements when it really matters.

To successfully exercise its rights, the customer must rely on the data provided by the developers.

Developer

One or a group of two to ten people directly involved in programming and related engineering issues. The developer has the following rights and responsibilities:

obtain sufficient knowledge of the issues to be programmed;
be able to clarify details during the development process;
provide indicative but frank estimates of the effort required for each feature or user story;
adjust estimates in favor of more accurate ones during the development process;
provide an assessment of the risks associated with the use of specific technologies.

Roles within a role

Each of the basic roles of Extreme Programming can be refined by smaller roles. XP allows the combination of roles within one person.

Customer side

Story Compiler- a subject matter specialist with the ability to clearly state and describe the requirements for the system being developed. This person or group of people is responsible for writing user stories and clearing up misunderstandings on the part of programmers.

Receiver- a person who monitors the correct functioning of the system. Good knowledge of the subject area. Responsibilities include writing acceptance tests.

Big boss- monitors the work of all levels, from developers to end users. He controls the implementation of the system and related organizational issues. Can also be an investor in the project.

Developer side

Programmer- a person involved in low-level coding and design. He is competent enough to solve current development problems and provide honest estimates of planned tasks.

Instructor- an experienced developer with good knowledge of the entire development process and its techniques. Responsible for training the team in aspects of the development process. Implements and monitors the correct implementation of the process methods used. Draws the team's attention to important, but for some reason, missed development points. At the same time, the instructor, like any other person, is not all-knowing and pays attention to the ideas of other team members.

Observer- a member of the development team, trusted by the entire group, who monitors the progress of development. It compares preliminary estimates of labor costs with those actually spent, deriving quantitative indicators of the team’s performance. These are such as the average speed and percentage of completed and planned tasks. This information is provided to the customer for timely control of the situation. Some of this information is unobtrusively provided to developers, so they know the status of the project, where difficulties arise, and what else can be done.

Diplomat- a sociable person who initiates communication between team members. Since document flow is minimized, constant communication and transfer of experience within the team, a better understanding of the requirements for the system, are important. The diplomat regulates and simplifies communication between customers and developers. Is an important link in meetings. It prevents omissions, heightened passions and unnecessary quarrels. A diplomat cannot impose his opinion on those discussing.

External roles

Consultant- a specialist with specific technical skills to help developers solve difficult problems. Usually brought in from outside.

Rules of Extreme Programming

Coding convention

Therefore, everyone must obey common coding standards - code formatting, naming of classes, variables, constants, comment style. This way, we will be sure that when we make changes to someone else's code (which is necessary to move aggressively and extremely forward), we will not turn it into Babel Pandemonium.

The above means that all team members must agree on common coding standards. It doesn't matter which ones. The rule is that everyone obeys them. Those who do not want to comply with them leave the team.

Collective code ownership

Shared 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 extend functionality, fix bugs, or refactor.

At first glance it looks like chaos. However, taking into account that at least any code was created by a couple of developers, that Unit 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 ownership of the code greatly simplifies making changes and reduces risk associated with the high specialization of one or another team member.

CRC Session

Use Class, Responsibilities, Collaboration (CRC) cards to design a system as a team. Using cards makes it easier to learn to think in terms of objects rather than functions and procedures. Cards also allow more people to participate in the design process (ideally the whole team), and the more people doing the design, the more interesting ideas will be brought to the table.

Each CRC card represents an instance of an object. An object's class can be written on top, responsibilities on the left, interactions on the right. We say "may be written" because when a CRC session is in progress, participants usually need a small number of class name cards and do not necessarily need them completely filled out.

A CRC session goes like this: each participant reproduces the system saying what messages he is sending to what objects. It goes through the entire process message by message. Weaknesses and problems are immediately identified. Design alternatives are also clearly visible in the process simulation.

To restore order, limiting the number of simultaneously interacting to two is often used.

Customer

One of the requirements of XP is that the customer is always available. He should not just help the development team, but be a member of it. All phases of an XP project require communication with the customer, preferably face to face - on site. It's best to simply assign one or more customers to the development team. Beware, the customer will be needed for a long time, and the customer's office may try to give you some intern as an expert. You need an expert.

User Stories written by the customer with the help of developers. The customer helps make sure that most of the desired system functions are covered by the User Story.

During release planning, the customer needs to discuss the choice of User Stories that will be included in the planned release. It may also be necessary to agree on the release period itself. The customer makes decisions related to business goals.

Choose the simplest solution

A simple design is always easier to implement than a complex one. So always go for the simplest solution that can work. If you find something complicated, replace it with something simple. It always turns out to be faster and cheaper to replace complex code with simple one before you begin to understand the complex code.

Refactor someone else's code if it seems complicated to you. If something looks complicated, this is a sure sign of a problem in the code.

Keep solutions as simple as possible for as long as possible. Never add functionality for the future - before it is needed. However, keep in mind: keeping a design simple is hard work.

Functional tests

Acceptance tests (previously also called Functional tests) are written based on User Story. They view the system as a black box. The customer is responsible for verifying the correctness of the functional tests. These tests are used to verify the functionality of a system before releasing it into production. Functional tests are automated so that they can be run frequently. The result is reported to the team and the team is responsible for planning functional test fixes.

Frequent integration

Each pair of developers should contribute their code as soon as reasonably possible. This can be when all UnitTests pass 100%. By submitting changes several times a day, you reduce integration problems to almost zero. Integration is a “pay now or pay more later” activity. Therefore, by integrating changes daily in small portions, you will not find yourself having to spend a week connecting the system into one whole just before the project is delivered. Always work on the latest version of the system.

For the manager. If a developer doesn't submit changes for more than a day, this is a clear indicator of a serious problem. You must immediately figure out what's going on. The entire experience of XP teams says that the reason for the delay is always poor design and it always has to be redone later.

Iteration Planning

An Iteration Planning Meeting is convened before the start of each iteration to plan the tasks that will be done in that iteration. For iteration, User Stories are selected that were selected by the customer in release plan starting with the most important for the customer and the worst (involving risk) for the developers. Also, broken Functional tests are included in the iteration.

User Stories and backlogs Functional tests are broken down into tasks. Tasks are written on cards. These cards are the detailed plan for the iteration. Each task should be between 1 and 3 ideal days in duration.

Developers break down tasks and estimate the length of time needed to complete them. Thus, each developer estimates how long the task will take him. It is important that the final assessment of the scope of work is made by the developer himself.

Project speed determines whether your tasks fit into an iteration or not. The total duration of tasks planned for an iteration should not exceed the speed achieved in the previous iteration. If you have typed too many, then the customer must decide which User Stories to postpone for the next iteration. If you typed too little, then you need to add the next User Story. In some cases, you can ask the customer to split one of the User Story into two in order to include part in the current iteration.

Putting off a User Story for the next iteration may seem scary, but don't let yourself sacrifice refactorings and Unit Tests to get more done. Debt in these categories will quickly slow down your speed. Don't do what you think will be needed in the next iterations - do only what is necessary to complete the current User Stories.

Monitor the speed of the project and pending User Stories. It is possible that the release plan will have to be redone every three to five iterations. This is fine. After all, a release plan is a look into the future and it is natural to expect that your predictions will have to be adjusted.

Iterations

Iterative development increases process flexibility. Divide your plan into iterations of 2 to 3 weeks. Maintain a constant iteration length for the duration of the project. Let iteration be the pulse of your project. This is the rhythm that will make measuring progress and planning simple and reliable.

Don't plan tasks in advance. Collect instead Iteration Planning at the beginning of each iteration to plan what will be done. It is also considered a violation of the rules to get ahead of yourself and do something that is not planned in this iteration. Thus, it becomes possible to keep the changing requirements of the Customer under control.

Take iteration completion deadlines seriously. Measure progress as you work. If it is clear that you will not be able to complete all planned tasks by the deadline, then collect Iteration Planning again and re-evaluate the tasks and postpone some of the tasks.

Concentrate efforts on completing the most important tasks selected by the Customer, rather than having several unfinished tasks selected by the developer.

Swap tasks

It is necessary to periodically change tasks for developers to reduce the risk of knowledge concentration and bottlenecks in the code. If only one person on your team can work in a given area and that person leaves, or you simply have a lot to do in a given segment of the program, you will find that your project is barely moving forward.

Cross Training is usually an important aspect in companies that try to avoid concentration of knowledge in one person. Moving people through code in combination with pair programming quietly makes Cross Training for you. Instead of one person knowing everything about a given piece of code, everyone on your team knows a lot about the code in each module.

The team becomes much more flexible if everyone knows enough about each part of the system to start working on it. Instead of waiting for the "guru" to finish working on a critical piece of code, several programmers can work on it simultaneously.

When starting a new iterations every developer must move to a new task. Pair programming helps overcome the onboarding problem (meaning that a new developer can start working in pairs with an experienced developer in the field).

This practice also encourages new ideas and improved code.

Leave optimization for later

Never optimize anything until coding is complete. Never try to guess where performance bottlenecks will be. Measure!

Make it work, then make it work correctly, then make it work quickly.

Pair programming

All code for the production system (and this means with the exception of trial solutions) is written in pairs. Two developers are sitting next to each other. One is typing, the other is watching. They change from time to time. It is not allowed to work alone. If for some reason the second of the pair missed something (sick, retired, etc.), he is obliged to review all the changes made by the first.

It sounds unusual, but XP claims that after a short period of adaptation, most people work well in pairs. They even like it because the work gets done noticeably faster. The principle “One head is good, but two is better” applies. Couples usually find better solutions. In addition, the quality of the code significantly increases, the number of errors decreases, and the exchange of knowledge between developers is accelerated.

Refactor Ruthlessly!

We programmers tend to stick with a design long after it becomes clunky. We keep reusing unmaintainable code because it still somehow works and we're afraid of breaking it. But is it really beneficial? XP takes the view that this is not profitable. When we remove redundancy, improve an outdated design, remove unused pieces - we do refactoring. Refactoring ultimately saves time and improves the quality of the product.

Review any code ruthlessly to keep your design simple as you develop it. Keep your code clear and understandable so that it is easy to understand, modify and extend. Make sure everything is written once and only once. Ultimately, it takes less time than polishing a complex system.

Release Plan

The Release Plan is developed at the Release planning meeting. Release Plans describe a view of the entire project and are subsequently used to plan iterations.

It is important that technical people make technical decisions and business people make business decisions. Release Planning defines a set of rules that allow everyone to make their decisions. These rules define the method for developing a work plan that satisfies everyone.

The essence of the release planning meeting for the development team is to estimate each User Story in ideal weeks. An ideal week is how long you think it will take to complete a task if nothing else distracts you. No dependencies, no additional tasks, but including tests. The customer then decides which tasks are most important or have a higher priority.

User Stories are written on cards. The developers and the Customer together shuffle the cards on the table until they get a set of User Stories that together will make up the first (or next) Release. Everyone wants to release a useful system that can be tested as early as possible.

The release can be planned by time or volume. In order to determine how many User Stories can be implemented by a specific date or how much real time a given set of tasks will take, use the project speed. If you plan by time, multiply the number of iterations by the speed of the project to find out how many User Story can be implemented. When planning by volume, divide the total number of ideal weeks needed for all User Stories by the speed of the project and you will get the number of iterations required to complete the release.

If management is not satisfied with the completion date, it may be tempting to reduce the scope estimates. You should never do this. Low estimates are sure to create a lot of problems later. Instead, negotiate with managers, developers, and customers until you come up with a release plan that everyone can agree on.

Frequent Releases

Developers should release versions of the system to users (or beta testers) as often as possible.

Release Planning used to find small pieces of functionality that have significant business meaning and that can be released into the real environment in the early stages of development. This is critical to getting useful feedback in a timely manner to influence the development process. The longer you delay releasing an important part of the system, the less time you will have to fix it.

Trial solution

Create trial solutions to answer complex technical questions and justify certain technological solutions. There is risk involved in any technology decision and trial solutions are designed to mitigate this risk.

Make a program that reproduces the problem under investigation and ignores everything else. Most trial solutions are not meant to be used, so expect them to be thrown away. The purpose of their creation is to reduce the risk of making the wrong technical decision or to more accurately estimate the time to implement a User Story.

Meeting standing

In a typical meeting, most participants contribute nothing, 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, having everyone in meetings takes resources away from the project and creates chaos in planning.

This kind of communication requires a standing meeting. 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 necessary and will bring something to the table. Moreover, it is even possible to avoid some meetings. With participants limited, 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 another waste of time. It will allow you to avoid many other meetings and save you more time than you spend on it.

Metaphor of the System

Always choose System Metaphor - a simple and clear concept so that team members call everything by the same name. To understand the system and eliminate duplicate code, it is extremely important how you name objects. If you can guess what an object in the system is called (if you know what it does) and it really is called that, you will save a lot of time and effort. Create a naming system for your objects so that each team member can use it without special knowledge of the system.

Unit Tests

Unit tests play a key role in XP. They allow you to quickly change code without fear of making new mistakes. A unit test is written for each class, the test should check all aspects of the class - test everything that may not work.

The trick here is that the test for the class must be written before the class itself. This means that as soon as you release the first working result, it will be supported by the testing system. To conduct tests, a special testing system with its own interface is written.

The Unit test for a class is stored in a common repository along with the class code. No code can be released without a Unit test. Before releasing the code, the developer must make sure that all tests pass without errors. No one can give away the code unless everyone passes 100%. In other words, since all tests passed before your changes, if you have errors, then this is the result of your changes. It's up to you to fix it. Sometimes the test code is incorrect or incomplete. In this case, you need to correct it.

A huge temptation is to save money on Unit tests when time is short. But by doing this you are only deceiving yourself. The more difficult it is to write a test, the more time it will save later. This has been proven by practice.

Unit tests allow for collective ownership of code. They make it relatively easy to review bad code. Unit tests also allow you to have a stable working system at any time.

User Story

User Story (something like a user's 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. Form - one or two paragraphs of text that is understandable to the user (not very technical).

User Story is written by the Customer. These are similar to system use cases, but are not limited to the user interface. For each story, functional tests are written to confirm that this story is implemented correctly - they are also called acceptance tests.

Each User Story is given a priority from the business side (user, customer, marketing department) and an estimate of execution time from the developers. Each story is divided into tasks and assigned a time when it will begin to be implemented.

User Stories are used in XP instead of traditional requirements. The main difference between a User Story and requirements is the level of detail. The User Story contains the minimum information necessary to make a reasonable estimate of how much time it will take to implement it.

A typical User Story takes 1-3 weeks of ideal time. A story requiring less than 1 week is too detailed. A story requiring more than 3 weeks can be divided into parts - separate stories.

Project speed

Project Velocity (or simply velocity) is a measure of how quickly the work on your project is completed.

To measure the speed of a project, you simply have to count the volume of User Stories, or how many (in time) tasks were completed per iteration. Just calculate the total time for estimating the amount of work (ideal time).

During release planning, project velocity is used to estimate how many User Stories can be produced.

During iteration planning, the velocity of the project in the previous iteration is used to determine how many User Stories to plan in the current iteration.

This simple mechanism allows developers to recover from a difficult iteration. If you still have free time after recovery, go to the customer and ask for another User Story. As a result, the speed will increase again.

There is no need to use this parameter as an absolute parameter. It is not suitable for comparing the productivity of two projects, since each team has its own characteristics. This parameter is only important for the team to keep it on an even keel.

You should expect slight changes in the speed of the project as you work. But if the speed changes significantly, it is necessary to reschedule the release. Once the new system goes to users, expect a change in the speed of the project as you have support tasks.

When an error is detected

If a bug is found, a test is created to prevent it from happening again. An error occurring on a production system (already installed) requires writing a functional test. Creating a functional test immediately before diagnosing a bug allows customers to clearly describe the problem and communicate the problem to developers.

A failed functional test requires creation Unit Test. This helps focus debugging efforts and clearly indicates when a bug has been fixed.

You won't need it

Refrain from filling the system with things you will need in the future. Only 10% of what you expected will actually be needed in its original form, meaning 90% of your time will be wasted.

There is always a temptation to add functionality now rather than later, because we see how to add it now and feel that the system will be much better. But we must always remind ourselves that we will never need it. Additional functionality only slows down progress and eats up resources. Forget about future requirements and additional flexibility. Concentrate on what needs to be done now.

A thorough economic justification for all actions - only what the customer needs is done and does not lead to the unprofitability of the project.

Formation of the basic architecture as early as possible.

Using component architecture.

Prototyping, incremental development and testing.

Regular assessments of the current state.

Change management, constant development of changes from outside the project.

Focus on creating a product that works in a real environment.

Focus on quality.

Adaptation of the process to the needs of the project.

Extreme Programming

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

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

The people involved in a project and their communication are 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.

Working through changes is more important than sticking to plans.

“Living” 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 when carrying out a project in accordance with most “heavy” processes, additional work to support the fixed process of the organization, like this required within, for example, CMM. Most of such work 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 developers to focus most of their efforts on development tasks and meeting real user needs. The absence of piles of documents and the need to maintain them in a coherent state allows you to respond more quickly and efficiently to changes in requirements and in the environment in which the future program will have to work.

However, XP has its own development process diagram (although, generally speaking, the widely used understanding of the “development process” as a fairly rigid scheme of actions contradicts the very idea of “lively” development), shown in Fig. 15.

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 its use, development is considered not to be XP, according to Kent Beck, one of the authors of this approach, along with Ward Cunningham and Ron Jeffries.

Live planning game

Its task is to determine as quickly as possible the amount of work that needs to be done before the next software version. The decision is made, first of all, based on the customer’s priorities (i.e. his needs, what he needs from the system for more successful

running your business) and, secondly, on the basis of technical assessments (i.e. assessments of the complexity of development, compatibility with other elements of the system, etc.). Plans are changed as soon as they begin to diverge from reality or the wishes of the customer.

				Test
		use		scenarios
			New story
	Requirements		use
	Requirements		Project speed

	Metaphor		Version plan
		Planning	Version plan	Iteration	Acceptance	Small
architecture				Last
						OK
						users
Unreliable			Confident	New iteration

"Throwing in" solutions

Figure 15. Workflow diagram in XP.

Frequent version changes (small releases)

The very first working version should appear as quickly as possible and should begin to be used immediately. Subsequent versions are prepared at fairly short intervals (from several hours for small changes in a small program, to a month or two for a major rework of a large system).

Metaphor of the system

The metaphor, in a fairly simple and understandable form for the team, should describe the basic mechanism of the system. This concept is reminiscent of architecture, but should describe the main essence of the technical decisions made much more simply, in just one or two phrases.

Simple design solutions

At any given time, the system should be designed as simply as possible. There is no need to add features in advance - only after an explicit request for it. All unnecessary complexity is removed as soon as it is discovered.

Test Driven Development(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 capabilities of the system so that they can see that the system actually works.

Continuous 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 rework 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 redesigned components should be identified during test execution and rolled back to the last intact state (along with the components that depend on them).

Pair programming

Coding is performed by two programmers on one computer. Pairing is arbitrary and varies from task to task. The one in whose hands the keyboard is trying to solve the current problem in the best way. The second programmer analyzes the work

first and gives advice, considers the consequences of certain decisions, new tests, less direct, but more flexible solutions.

Collective ownership of code

IN Any member of the team can change any part of the code at any time. No one should have their own area of responsibility; the entire team as a whole is responsible for all the code.

Continuous integration

The system is assembled and undergoes integration testing as often as possible, several times a day, every time a couple of programmers finish implementing the next function.

40 hour work week

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

Inclusion of the customer in the team(on-site customer)

IN The development team always includes a customer representative who is available throughout the working day and is able to answer all questions about the system. His responsibility is to promptly answer questions of any type regarding the functions of the system, its interface, required performance, correct operation of the system in difficult situations, the need to maintain communication with other applications, etc.

Using code as a means of communication

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

Open workspace

The team is housed in one fairly spacious room to facilitate communication and enable group discussions when planning and making important technical decisions.

Changing the rules as needed (just rules)

Each team member must accept the rules listed, 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 for use within small teams (no more than 10 programmers), which is emphasized by the authors of this technique. A larger team size destroys the ease of communication necessary for success and makes it impossible to implement many of the techniques listed.

The advantages of XP, if it can be implemented, are greater flexibility, the ability to quickly and accurately make changes to the software in response to changing requirements and individual customer wishes, high quality of the resulting code, and the absence of the need to convince customers that the result meets their expectations.

The disadvantages of this approach are the impracticability of sufficiently large and complex projects in this style, the inability to plan the timing and complexity of the project for a sufficiently long term and clearly predict the results of a long-term project in terms of the ratio of the quality of the result and the costs of time and resources. It can also be noted that XP is not suitable for those cases in which possible solutions are not immediately found on the basis of previously gained experience, but require preliminary research

XP as a set of described techniques was first used during work on the C3 project (Chrysler Comprehensive Compensation System, development of a payment accounting system

employees of Daimler Chrysler). Of the 20 participants in this project, 5 (including the above-mentioned 3 main authors of XP) published 3 books and a huge number of articles devoted to XP during the project itself and subsequently. This project is repeatedly mentioned in various sources as an example of the use of this technique. The following data is compiled from the articles mentioned, minus anecdotal evidence, and illustrates the problems with some XP techniques when applied to fairly complex projects.

The project started in January 1995. Since March 1996, following the inclusion of Kent Beck, it has been run using XP. By this time, it had already gone beyond the budget and plans for phased implementation of functions. The development team was cut, and for about six months after that the project developed quite successfully. In August 1998, a prototype appeared that could serve about 10,000 employees. The project was originally expected to be completed in mid-1999 and the resulting software would be used to manage benefits for the company's 87,000 employees. It was stopped in February 2000 after 4 years of running XP due to complete failure to meet time frames and budget. The software created has never been used to work with data on more than 10,000 employees, although it has been shown that it can handle data on 30,000 company employees. The person who played the role of the customer included in the project team quit after a few months of such work, unable to withstand the workload, and never received an adequate replacement until the end of the project.

Literature for Lecture 3

W. Royce. Software project management. M.: Lori, 2002.

A. Jacobson, G. Butch, J. Rambo. Unified software development process. St. Petersburg: Peter, 2002.

Kroll, The Spirit of the RUP. www-106.ibm.com/developerworks/rational/library/ content/RationalEdge/dec01/TheSpiritoftheRUPDec01.pdf

K. Beck. Extreme Programming. St. Petersburg: Peter, 2002.

http://www.agilemanifesto.org/

K. Beck, et. al. Chrysler goes to “Extremes”. Distributed Computing, 10/1998.

A. Cockburn. Selecting a Project's Methodology. IEEE Software, 04/2000.

L. Williams, R. R. Kessler, W. Cunningham, R. Jeffries. Strengthening the Case for Pair Programming. IEEE Software 4/2000.

G. Keefer. Extreme Programming Considered Harmful for Reliable Software Development. AVOCA Technical Report, 2002.

Available as http://www.avoca-vsm.com/Dateien-Download/ExtremeProgramming.pdf.

Development (development driven by system functions), etc.

Live planning game
Its task is to determine as quickly as possible the amount of work that needs to be done before the next software version. The decision is made, first of all, based on the customer’s priorities (i.e., his needs, what he needs from the system to run his business more successfully) and, secondly, on the basis of technical assessments (i.e., estimates of the complexity of development , compatibility with other elements of the system, etc.). Plans are changed as soon as they begin to diverge from reality or the wishes of the customer.
Frequent version changes (small releases)
The very first working version should appear as quickly as possible and should begin to be used immediately. Subsequent versions are prepared at fairly short intervals (from several hours for small changes in a small program, to a month or two for a major rework of a large system).
Metaphor of the system
The metaphor, in a fairly simple and understandable form for the team, should describe the basic mechanism of the system. This concept is reminiscent of architecture, but should describe the main essence of the technical decisions made much more simply, in just one or two phrases.
Simple design solutions
At any given time, the system should be designed as simply as possible. There is no need to add features in advance - only after an explicit request for it. All unnecessary complexity is removed as soon as it is discovered.
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 capabilities of the system so that they can see that the system actually works.
Continuous 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 rework 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 redesigned components should be identified during test execution and rolled back to the last intact state (along with the components that depend on them).
Pair programming
Coding is performed by two programmers on one computer. Pairing is arbitrary and varies from task to task. The one in whose hands the keyboard is trying to solve the current problem in the best way. 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.
Collective ownership of code
At any time, any team member can change any part of the code. No one should have their own area of responsibility; the entire team as a whole is responsible for all the code.
Continuous integration
The system is assembled and undergoes integration testing as often as possible, several times a day, every time a couple of programmers finish implementing the next function.
40 hour work week
Working overtime is seen as a sign of larger problems in the project. Overtime work for 2 weeks in a row is not allowed - this exhausts programmers and makes their work significantly less productive.
Including the customer in the team (on-site customer)
The development team always includes a customer representative who is available throughout the working day and is able to answer all questions about the system. His responsibility is to promptly answer questions of any type regarding the functions of the system, its interface, required performance, correct operation of the system in difficult situations, the need to maintain communication with other applications, etc.
Using code as a means of communication
Code is seen as the most important means of communication within a team. Code clarity is one of the main priorities. Following coding standards that provide this clarity is imperative. Such standards, in addition to code clarity, should ensure minimal language (no duplication of code and information) and should be accepted by all team members.
Open workspace
The team is housed in one fairly spacious room to facilitate communication and enable group discussions when planning and making important technical decisions.
Changing the rules as needed (just rules)
Each team member must accept the rules listed, but if the need arises, the team can change them if all its members agree on this change.

XP as a set of described techniques was first used during work on the C3 project (Chrysler Comprehensive Compensation System, development of a system for accounting for employee benefits at Daimler Chrysler). Of the 20 participants in this project, 5 (including the above-mentioned 3 main authors of XP) published 3 books and a huge number of articles devoted to XP during the project itself and subsequently. This project is repeatedly mentioned in various sources as an example of the use of this technique. The following data is compiled from the articles mentioned, minus anecdotal evidence, and illustrates the problems with some XP techniques when applied to fairly complex projects.

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.

Planning game

Our world is too changeable and unpredictable to rely on the constancy of the situation. The same thing happens in software development: with a rare system, you can say that its final form was known in advance in detail at the very beginning of development. Typically, the customer’s appetite comes while eating: he constantly wants to change something, improve something, or throw something out of the system altogether. This is the variability of requirements that everyone is so afraid of. Fortunately, a person 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. The fulcrum, the technique that allows you to predict the situation and painlessly put up with changes, is the planning game. During such a game, known system requirements can be quickly collected, assessed and planned according to priority.
Like any other game, planning has its participants and its goal. The key figure is, of course, the customer. It is he who communicates the need for this or that functionality. Programmers give an approximate assessment of each functionality. The beauty of the planning game 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 his own way to victory: the customer selects 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 it will take them to complete their tasks and which of them would be more willing to solve one problem and who another.
In an ideal situation, the planning game between the customer and the programmer should be played every 3-6 weeks, until the next development iteration begins. This makes it fairly easy to make adjustments based on the successes and failures of the previous iteration.

Release plan

The release plan defines the release dates and user statements that will be implemented in each of them. Based on this, you can choose formulations for the next iteration. During an iteration, acceptance tests are produced and run within that iteration and all subsequent ones to ensure that the program operates correctly. The plan may be revised if there is a significant lag or lead at the end of one of the iterations.
Iterations. Iteration makes the development process dynamic. There is no need to plan your software tasks long in advance. Instead, it's better to have a planning meeting at the beginning of each iteration. There is no point in trying to implement something that was not planned. You will still have time to implement these ideas when they are released according to the release plan.
By getting into the habit of not adding functionality up front and using forward 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 solve software problems. Each iteration should last from one to three weeks. Formulations within an iteration are sorted in order of their importance to the customer. In addition, tasks are added that could not pass the acceptance tests and require further work. Test statements and results are translated into software problems. Tasks are written down on cards that form a detailed iteration plan. It takes from one to three days to solve each problem. Tasks that require less than one day can be grouped together, and large tasks can be divided into several smaller ones. Developers estimate tasks and deadlines for their completion. It is very important for a developer to accurately determine the execution time of a task. It may be necessary to re-evaluate some language and revise the release plan after every three or five iterations - this is completely acceptable. If you implement the most important areas of work first, then you will always have time to do the maximum possible for your clients. An iterative development style improves the development process.

Meeting standing

Every morning a meeting is held to discuss problems, their solutions and to strengthen the team's concentration. The meeting is held standing to avoid lengthy discussions that are not interesting to all team members.
In a typical meeting, most participants contribute nothing, 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, having everyone in meetings takes resources away from the project and creates chaos in planning.
This kind of communication requires a standing meeting. 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 necessary and will bring something to the table. Moreover, it is even possible to avoid some meetings. With participants limited, 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 another waste of time. It will allow you to avoid many other meetings and save you more time than you spend on it.

Simplicity

A simple design always takes less time than a complex one. So always do the simplest things that will 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 planned. Keep in mind: keeping a design simple is hard work.

System of metaphors

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

Customer at the work site

The main problem in software development is the lack of knowledge of programmers in the subject area being developed. Extreme programming has found a way out of this situation. No, this is not a developer 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.
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. The easiest way to overcome this inconvenience - and Extreme Programming teaches us to find the simplest solutions - is to 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 is more expensive. Real experience in running 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 the customer or his representative, sometimes it is advisable to temporarily hire a specialist in the field being developed. This 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 is sometimes significantly higher than the salary of specialists in other industries.
User Story. User Story (something like a user's 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. These are similar to system use cases, but are not limited to the user interface. For each story, functional tests are written to confirm that this story is implemented correctly - they are also called acceptance tests.

Testing before development begins

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 the opportunity to change jobs arises.
In extreme programming, the role of testing is more interesting: now the test comes first, and then the code. How to test something that doesn’t exist yet? The answer is simple and banal: test your thoughts - what to expect from a future piece of program 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 may not work either. So what, write 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 are they doing for this? Screw the second nut close to the first, so that each nut prevents the adjacent 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 sell parts that are not currently in demand.

Pair programming

All code for the production system is written in pairs. Two developers are sitting next to each other. One is typing, the other is watching. They change from time to time. It is not allowed to work alone. If for some reason the second of the pair missed something (sick, retired, etc.), he is obliged to review all the changes made by the first.
It sounds unusual, but after a short period of adaptation, most people work well in pairs. They even like it because the work gets done noticeably faster. The principle “One head is good, but two is better” applies. Couples usually find better solutions. In addition, the quality of the code significantly increases, the number of errors decreases, and the exchange of knowledge between developers is accelerated. While one person focuses on the strategic vision of the 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 knowledge isolation and eliminate bottlenecks. Particularly fruitful is replacing one of the developers in pair programming.

Collective code ownership

Shared 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 expand functionality and fix bugs.
At first glance it looks like chaos. However, taking into account 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 ownership of the code makes it much easier to make changes and reduces the risk associated with the high specialization of one or another team member.

Coding convention

You are on a team that has been working on this project for a long time. People come and go. No one codes alone and code belongs to everyone. There will always be times when you need to understand and adjust someone else's code. Developers will remove or change duplicate code, analyze and improve other people's classes, etc. Over time, it will be impossible to say who the author of a particular class is.
Therefore, everyone must obey common coding standards - code formatting, naming of classes, variables, constants, comment style. This way, we will be sure that when we make changes to someone else's code (which is necessary to move aggressively and extremely forward), we will not turn it into Babel Pandemonium.
The above means that all team members must agree on common coding standards. It doesn't matter which ones. The rule is that everyone obeys them. Those who do not want to comply with them leave the team.

Frequent integration

Developers should integrate and release their code every few hours if possible. In any case, you should never keep changes for more than one day. Frequent integration avoids alienation and fragmentation in development, where developers cannot communicate in the sense of sharing ideas or reusing code. Everyone should be running the latest version.
Each pair of developers should contribute their code as soon as it is reasonably possible to do so. This can be when all UnitTests pass 100%. By submitting changes several times a day, you reduce integration problems to almost zero. Integration is a “pay now or pay more later” activity. Therefore, by integrating changes in small increments every day, you will not find yourself having to spend a week trying 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: staying late at work, going to work on weekends, giving up vacation, staying awake for several days while sitting at the keyboard... In general, what can you do for the sake of your favorite activity. But extreme programming is categorically against such self-sacrifice and violation of accepted labor law standards.
This is dictated not only by considerations of legality and humanity, but, first of all, by the need to increase work efficiency and strict organization. After all, extreme programming is a collective game, designed not for individuals, but for the entire group. And such a thing as, for example, pair programming is possible only when 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 inconvenient.
But the most important thing is that in order to maintain health and performance, a person needs proper rest. The eight-hour working day and five-day working week are established precisely for reasons of maximum productivity. In many Western companies, leaving work late is regarded as failure to perform well or an inability to properly manage one's working time. In most cases this is true. And from a medical point of view, delays at work lead to constant fatigue, irritability and decreased brain activity. Is this effective? How can we organize constant open communication between developers in such a team, and will pair programming be possible? The answer is negative. Standards are standards and should be followed.

Conclusion

These methods are not put together by chance. Their consistent combination can bring the development process into intellectual resonance, significantly increasing the quality of the product and hastening its release time. The main beauty of all extreme programming is predictability and minimization of development costs; providing the customer with the product that he wishes to receive at the time of release; and of course, communication and training of developers on the job.

Bibliography:

Methods and principles of extreme programming. Within XP, incremental planning is used, as a result of which the overall project plan emerges quite quickly, but it is understood that this plan evolves throughout the entire project.

7. Adaptive development process models: Scrum

Principles of live development

Extreme Programming

XP Process (Extreme Programming)

XP Principles

XP development practices

XP development diagram

Scrum model

The main idea of ​​the Scrum model

Roles

Development stages

Sprint planning

Executing a sprint

text of the reference answer (I do not position it as mandatory)

Rights and roles

Customer

Developer

Roles within a role

Customer side

Developer side

External roles

Rules of Extreme Programming

Coding convention

Collective code ownership

CRC Session

Customer

Choose the simplest solution

Functional tests

Frequent integration

Iteration Planning

Iterations

Swap tasks

Leave optimization for later

Pair programming

Refactor Ruthlessly!

Release Plan

Frequent Releases

Trial solution

Meeting standing

Metaphor of the System

Unit Tests

User Story

Project speed

When an error is detected

You won't need it

Extreme Programming

Literature for Lecture 3

Planning game

Release plan

Iteration planning

Meeting standing

Simplicity

System of metaphors

Customer at the work site

Testing before development begins

Pair programming

Changing positions

Collective code ownership

Coding convention

Frequent integration

Forty hour work week

Conclusion

The main idea of the Scrum model