Geekly Articles each Day
📜 ⬆️ ⬇️

Managing the development of technologically complex Internet applications in the context of an acute shortage of time

Introduction


This article is about how to speed up the development of technologically complex Internet applications and not pay an excessive price for it. It was written to generalize and put in order the author's own experience, but it may be useful to other technical managers of Internet projects. The reader may be interested in a note as a source of information for making a decision about joining a similar project now or in the future - when he is faced with a similar proposal.


The note also addresses the sore issue of wage difficulties and how they can be effectively addressed.


Under the Internet applications in the note refers to both websites in their pure form, and client-server systems with clients in a browser such as a one-page site or a mobile application. Sometimes specificity is important and it will be negotiated specifically.


Many of the thoughts expressed in the note are applicable to other types of IT projects. Be careful with this, as the author wrote only about what he had direct experience with. The reality of other IT projects may look similar, but their reality requires completely opposite steps to achieve success. Only a deep understanding of your project allows you to transfer receptions between neighboring types of projects and receive significant benefits from it.


In the note, the role of the project manager is divided into the roles of technical manager and business leader. For IT projects, this is the traditional division. Depending on the type of organization, a business leader is usually referred to simply as a project manager, project manager or CEO. Technical managers are usually referred to as CTO, department head, architect, team leader, chief programmer, or lead programmer — again, depending on the type of organization and priority in favor of managerial, programmer, or architectural skills.


Throughout the text, a business leader could be called simply a project manager and it would be understandable to everyone, but he will always be called the business leader. This is done so that you understand the simple truth: a technologically complex IT project always has two managers, one of them is leading (business), the other is driven (technical), but there are two of them. If a technical manager forgets that he is also a manager and also has some responsibility for the success of the project, then in the conditions of an acute time limit this will most likely lead to the collapse of the project.


The note turned out to be about 80 thousand characters in size and would require about two and a half hours with fast reading. It will be of interest to project managers, investors and those of developers who are interested in start-ups and project-based development approaches.


about the author


The author of this article has some experience in implementing applications as a hired CTO of various startups, plus the experience of implementing a pair of projects in integrators from scratch. Basically, this is the creation of actively communicating with the servers of Internet applications: technologically sophisticated websites and mobile applications.


A typical work scheme is “hiring from the market, developing architecture, hiring a development team from the market, developing by hands of developers, self-implementing the most complex functionality, launching an application, and after a while exiting the project” is a real hardcore.


There is an experience of successful exit from the project with a problem ending of financing.


What does the lack of time


Miscalculations in planning. Timing and budget are under pressure. They are fixed before the amount of work on the project is determined more or less accurately. This leads to the need to optimize the time reserves and redistribute them from the sphere of management to the benefit of direct work, since otherwise even the planned deadlines based on the work schedule will not meet the already sold deadlines for the project completion. The argument that time is not enough, the business manager is not satisfied with absolutely. He usually understands this and is himself a hostage to the situation. Hence, there is an understanding that this is a project with an acute shortage of time. As a result, the schedule will be obviously unrealistic, with the hope of all participants in this transaction, that in the course of the project time expenses will be constantly optimized. Sometimes it works, sometimes not.


The difficulties of hiring good developers at the beginning of the project. Timing is under pressure. The developers market is not rich, especially those who are not willing to work with the non-standardized working day. Therefore, there is a great desire to take more or less suitable developers from the market and start developing with them as soon as possible. Should not give in to this urge. It is better to hire high-quality developers than to meet the deadlines for employment - by breaking the first and second reporting periods, the project management will receive a much higher development speed by the end of the project. Your goal is a project, not interim reporting.


Growing hiring difficulties with project development. The longer the project is developed, the more code is written, the more complex logic is implemented, and the beginner has to understand the existing code more. In addition, the constant postponement of refactoring, even in the conditions of a high-quality CodeReview, leads to the fact that in some places the code becomes difficult to understand. This may lead to the fact that within three months after the start of writing code, the new hired programmers will quickly go away and the turnover on new developers will reach 100%. An experienced technical manager can cope with this difficulty in advance, a beginner - no.


The problem of firing people. Since you cannot hire people, problems arise with dismissal. Fired needs to be replaced. Replacing means hiring a new developer, but they do not linger. Therefore, the project management and the team may be forced to endure someone whom they would have fired long ago in a normal project. Again we return to the fact that despite the pressure of intermediate deadlines, the hiring of quality developers is more important than the first reporting periods.


The contradiction between the creation of new functionality and error correction. Time is limited. The amount of work done, too. And if at the beginning of development errors are usually not paid much attention to, then by the middle and, especially, the third quarter of the project errors become a serious factor influencing the opinion of the project of all participants and stakeholders. Including the developers themselves. At the same time, the need to advance in functionality is not canceled. Therefore, errors are best divided into fatal, critical, non-critical and low-priority. Fatal rules before writing a new functional. Critical rules for a new daily release. Non-critical accumulate and correct at the end of the next stage. Low priority rule after the completion of the project by unidentified good elves.


From personal practice. An experienced business project manager drew the attention of the tmilid and the architect to the fact that there are many mistakes in the developed product of increased reliability, that he understands everything, but it becomes difficult for him even to endure. He suggested adding another well-tested tester to the project. Timlid, in the person of the author of the note, inquired of the priorities of the architect who was the technical project manager: we rule mistakes or continue to write the functionality as quickly as possible. After deciding in favor of speed of development, the team leader told the business project manager that the team could take another tester, but because of the lack of developers, it doesn’t fix most of the errors found by the tester. That is, the new tester will only increase the pool of known errors, but not the number of corrections. The quality of the code will remain the same. As a result, they refused to attract a new tester.

Everyone understood everything. The project was launched on time with a code quality much higher than the market average for large companies.

Accumulating bad code due to postponing refactoring. An acute shortage of time leads to the fact that time is allocated for refactoring only in a situation when the code is obviously difficult to refine. Moreover, when adding functionality to a given section of code leads to a large amount of work on debugging errors. If the project management is lucky and the timblid is good, then he will be able to keep track of the most problematic parts of the code and inform him of when they will require refactoring and to what extent. Usually, such areas are frequently updated code: a couple of lines were added in one task, another three in another, a line in the third and tenth edits in the vermicelli code. There are no guilty programmers. At the same time, it is very problematic to protect against the formation of such vermicelli even with the help of CodeReview and the advanced team leader. Such code needs to refactor from time to time, and the project has an acute lack of time.


Conflicts. In projects with an acute shortage of time are very frequent. The solution here is only one thing - the soft skills of the technical project manager should be and alone should be very strong. Accordingly, before the developer moves from the position of a developer-specialist to the position of a developer-manager, he needs to actively develop his human, communication and conflict resolution skills. Actually, the fact that a developer is ready for management activities is determined by the ability to negotiate with people for mutual agreement.


Conflict resolution will be greatly helped by understanding that conflict in a development team usually arises from the participants' desire to do a better and faster job. In this case, the solutions for this are different. Sometimes with different priorities for speed or quality. These are industrial conflicts, not personal ones. Such conflicts are best addressed by training the parties and joint decision making, rather than finding the right or the one who is guilty.


The predominance of tactical decisions over strategic and growth of tactical decisions. The situation is very similar to the situation with refactoring and hiring staff. The project has a deadline and there are intermediate. For the next intermediate, they will definitely hit on the head, depending on the tactical successes, and the final one will not be soon, and some of them will fall out of the planning horizon. This is not a problem of a particular person. This is role play. The individual can only follow the role or try to overcome it. If you feel that the role strongly presses the strategic goal, it is better to talk about it with the business manager of the project, to outline the advantages and disadvantages of the solution options and do what the business manager of the project decides.


Project Business Manager


The project business manager is the most important person on the project. He is the source of ideas, the point of contact with the final audience and the representative of users in the project. In the case of a customer, he is also a representative of the customer’s interests. It should be remembered that the project works for the end user - only the end user will decide whether the project was successful and whether the created product can be used. In a startup, the role of a business leader is performed by an entrepreneur, one of the founders of a startup.


The practice of work has shown that such a fundamental factor as time constantly puts pressure on a business project manager. In the case of a corporate project, this is a strict deadline set during the conclusion of the contract. Some integrators already in the sale of the project lay a 20% shortage of time, forcing developers to work the 20% of the time for free. In the case of a startup, this is the money that the development team members need to pay. In the case of an invested startup, it is reporting to investors for unrealistic periods in the name of receiving investments. All other problems of project management are directly derived from this factor. The main of them were considered a little higher.


The quality of a business project manager is determined precisely by the ability to work under time constraints. First, do not panic in the development team by constantly changing priorities. Secondly, to understand the miscalculations with understanding and to help solve problems that arise. Third, to be able to build tactical business objectives in such a way that the strategic goal of successfully completing the project is achieved.


Circumstances force the project's business manager to make insane, at first glance, decisions. Moreover, in the case of group decision making, the development team often supports these decisions, since other, formally correct and optimal, it is simply unrealistic to implement in these specific conditions. A wise business project manager is able to soften this blow of madness by explaining what is happening and showing that he understands everything perfectly.


Actually, when meeting with a business project manager, it is necessary to find out exactly how well he understands the difference between theory and practice, how well he is able to combine the understanding of project management with situational decision-making. This is clearly seen in the interviews, including from the questions that he himself asks.


In any case, no matter what the business leader does during the project, you need to be with him and help him. No matter how strange his actions and requests would seem. His actions are always aimed at the success of the project and he is guided only by this goal, and the success of the project is your main goal.


Who should not be contacted


You should not enter into a project headed by people who do not understand IT and do not have experience in IT. The stall owner will treat the development team as a stall staff. The owner of a construction company is like a Tajik. Former head of security as permanent security offenders. A person is difficult to change leadership style.


Avoid entering the project, which is headed by people who are not engaged in the main activity characteristic of the project. The former high-class system administrator is not the best business manager of a mobile application development project. On the other hand, if such a person has been managing IT projects for more than 5 years, then, on the contrary, he can contribute a lot to the project.


Dogmatics having their own clear views independent of the situation is also not the best choice. When the situation changes, they will continue to insist on abstract solutions that are suitable for spherical horses in a vacuum. Before starting a collaboration, always test people for their ability to understand the situation, apply their theoretical knowledge in it and revise them if they are not applicable.


The technical project manager is unlikely to be interested in people who have nothing to learn. The question “Why am I working for him, and not he, but me?” Will constantly arise with them. On the other hand, for a number of people this is quite a comfortable situation, which can be greatly mitigated by a high salary.


Avoid entering the project with people who cannot make decisions quickly. Quickly does not mean thoughtlessly. Preliminary reflections sometimes last for weeks, and the decision is made instantly and on the situation with a full understanding of the consequences and prices of this decision. If a person does not know how to do this, then he will delay with urgent solutions, pile up problems and increase the pressure of deadlines. This will surely kill the project.


Technical Project Manager


If the project is organized by an integrator or a large company, then the technical project manager needs to know deeply the whole stack of development technologies traditional for this department, and have extensive experience working with him. The author of the note will not dwell on this type of projects in this section.


If a technical manager wanders from company to company or is attracted to start-ups, then everything becomes more interesting, since each project has its own needs. Sometimes the business requirements are such that at the design stage of the architecture, the technical manager suddenly realizes that using familiar technology stacks is not profitable. And then you have to learn a new stack, and he is already in a situation of acute shortage of time, and at the beginning of the project, it is on a critical path.


Take, for example, the main stacks of the author’s technologies:



Non-stack languages: C ++, Assembler, various dialects of Visual Basic, JavaScript, TypeScript, Go, Java, Formula, and all sorts of Fortran and Pascal in their youth.


From operating systems, we managed to develop in all MS DOS starting from 3.0, all Windows starting from 3.1, OS / 2, CentOS, Ubuntu, Debian, openSUSE, AstraLinux and for a long time already on FreeBSD.


It was managed to administer mainly CentOS, Ubuntu, Debian, openSUSE and AstraLinux.


From frameworks: Symfony2, Symfony3, Kohana 3, Yii 2, React Native, SailsJS, ExpressJS, MFC, Bootstrap 3, OWL for C ++, etc.


Among other tools, we had to understand and use ElasticSearch, MongoDB, Beanstalk, BerkeleyDB, Docker, Composer, Capyfony, RabbitMQ, Memcached, Git, Jira, RedMine, PHPUnit, SphinxSearch, Axshare, WinAPI and a variety of APIs for the C-part, with the C, and the various APIs for the C, with the C-items, and with the C, you will have to use the same template for the C, and you will get the same template for the C-part, and you will get the same template for the C-part, and you will have to use the same template for the C-part, and you will get the same template for the C, and you will get to use the same C, and you will get to use the same template for the C, and you will get to use the same C, you will get an understanding of the C, and you will get the same template for the C, you will have to use the same C, you will get the same template for the C, and you will get the same template for the C, you will get the same template for your Syntra. , Domino.Doc and others.


From IDE: NetBeans, PhpStorm, Visual Studio, Notepad, mc and vi editor.


It is crowned with all this skill to impose a point-to-point page in situations where middle-level designers do not cope and say that it is impossible to impose this.


Above, we mentioned only technical skills of a specialist directly related to the development. But there are still architectural, executive, managerial and organizational. And the technical project manager, they also need to own.


The second half of this article is devoted to architectural skills in a wide variety of views, angles and sections. They are key to the technical project manager. Therefore, we will consider them further separately and in great detail.


There remain executive, managerial and organizational. The so-called soft skills. Soft skills are desirable for increasing in the order specified above. That is, first, managers, then management, then organizational.


Leadership skills allow you to distribute the scope of activities between developers, explain to them exactly what to do and why, and also help them solve current issues, resolve conflicts of interest and teach instead of criticizing. They are also critical when hiring developers - it is they who make it clear who came to the interview, what he really can do and how he will fit into the development now and with time.


Management skills allow you to structure the project, make a good plan, adjust it along the way, understand the general course of development and ahead of time eliminate difficulties and avoid problems. They also make it possible to understand how to equip the workflow: which tools for team communication will work better, how to choose code design rules, what instructions to write and how to build work with code, servers, tools, errors, etc. These are design and construction skills development infrastructure so that developers are comfortable creating the product as fast as possible without directly telling them what to do.


Organizational skills allow you to structure roles in a team, select the most suitable people for the roles, and launch self-organizing mechanisms within the resulting organization so that the participants of the development team line up the development process as necessary.


In small projects up to 5-6 developers, a technical manager of the project will be enough leadership skills with a general understanding of management. The organization will line up automatically, with all the errors of its functioning in teams of this size can be easily resolved within the framework of leadership skills. An assessment of the human skills of people hired can usually be helped by a business leader. The lack of management skills can also be largely compensated during the direct leadership of developers, but the development process will still have to be built and the speed of development depends on its quality three months after the start of the project, as well as the overall quality of the product.


Is it possible in a small development group to get along with poorly developed leadership and management skills? Can. For this, it is enough to organize Scrum by Scrum Guide. It is a pure framework for leadership without leadership and management without management. In the conditions of an acute shortage of time, it is usually inapplicable due to the psychological characteristics of the business project manager and sponsor.


Is it possible in a small development team to do with underdeveloped leadership and organizing skills? Can. To do this, you should consider the development process, prescribe the regulations, correct them according to the wishes of the team, draw up a plan, negotiate with the team members and update it once a week. In the conditions of an acute shortage of time, this scheme usually loses much to the direct leadership because of its excessive rigidity of the structure and the difficulty of adjusting to the constantly changing situation.


Developers


In the section “What the lack of time leads to,” it was described why the project management will not be able to dismiss developers until the product launch. When deciding whether to hire, remember that you will have to work with this person all this time. Most likely, you will not be able to dismiss him for many years. Even after the launch of the product, dismissal will lead to an unacceptable decrease in the speed of its development.


Therefore, if you do not pass on skills - do not hire. He will not have time to pump the necessary skills. If you are blunt, lethargic or mumble - do not hire. He will not be able to work quickly. If you are not ready to take responsibility for your decisions - do not hire. In the first months, the technical project manager will not have time to clearly set all the tasks, so each developer will have to make decisions close to the key ones within their development area and take responsibility for them. If you do not like the person - do not hire. Working with people who have to endure, gradually saps the spirit and over time makes the work painful and sad. If he believes that he knows the truth - do not hire. Rapid development is about the ability to choose between two fairly good options, knowing how to do the best, why there is no time for it, and why the project will survive after making such decisions and will not survive with the implementation according to the best practice.


Many restrictions? Lot. And they are more serious than an unsophisticated person might think.


The best developer for a project with an acute shortage of time is the one who knows what he wants, wants to grow as part of his specialization and is able to bring solutions to the end. He has the necessary skills, he is vital and takes the need to act differently in different situations. He is also comfortable in communication for hired and not yet hired team members, while other not yet hired members are comfortable for him - otherwise the team will reject him, which is critical in this type of project. These are minimum requirements, but they also radically narrow the range of eligible candidates.


Depending on its internal structure, the projects will impose other requirements. It is the projects, not you. Understanding the project, you see its needs and in this regard, the project itself decides, as it were, who will be the ideal developer, and the role of project management only to understand this. Although, of course, all decisions are made by people and “the project itself decides” only means that the business leader once had to impose such restrictions on the project that lead to these “project requirements”.


For some projects, perfectionists are required to achieve a high quality product. For others, people who are able to overcome the desire to make ideally perfect in order to quickly make a working first version are crucial. For the third, narrow specialists are required and the technical project manager acts as an integrator of their labor into a single product. For the fourth - developers with a broad outlook and one of the developers, and maybe a technical manager, appeals to the fact that the layout designer cannot create them; fixes in javascript something that the frontend developer cannot fix; implements in the server part what the backend programmer does not cope with. For the fifth, it is impossible to do without active communication within the development team, and this requirement for the ability to communicate in business and help each other will even outweigh the professional skills.


And that is not all. In the conditions of an acute shortage of time, the project management cannot wait two weeks until the developer leaves the current place of work. Also, it cannot accept the risk that during these two weeks the developer will have time to change his mind or will have an interview and get a job in another company “forgetting” to write to you about it. The project management needs a person who is ready to go out within a few days and, if he doesn’t like something, then replace him within the next couple of days.


These are the restrictions on candidates.


Planning


Managing a complex project is impossible without a good plan. It will definitely not be respected. , . , — .


, . , . , . , , . . . .


. -, , . . -, , . -, , . , , . -, , . -, . , .


— , . , , . , . .


, , . . - , - .


. -, .


. Excel . Excel . , - . Jira. , — , — .


Jira - . . . , . . . . , .


: , . .


Excel , . 300-500 , . . , « » , « -», « - », « » « » — , . . Jira . Jira , . , , , . . . , Jira, « » «» — .


, - . , : , , , , , . , , . .


- , , . 60% , 5% «» , 20% « » 15% , .


, : , .


. — . , . , . , — 1/4 . (, 5 , , , ), -, . , 10 , Code Review. - Code Review 10-15% .


. , , , , . , , . 30 , . ?


, , . , .


, - . , , . — .



, - . . , 10 24 . , . 24 . 30 . «» . . 30 — 24 = 6 ?


, 8 . - 8 . — , . . , 6-6.5 . 7 , — . - - .


6- . , , 6 . . , , Jira , — .


- . 8 , 6 , 8- 6- . , . .


, , 8 . .



. . . . - . - . - . - , , .


, , - . ? -, . , . -, . , , . -, . - , , .


— . . . . . .


Start of development


- , , . , .


. Android-, iOS- NodeJS-, ( , — — ), . , : , .

, - - Axure/Axshare - Photoshop, - , . ?


. , . : , , , , .. .


, - , - — / , - — , - (, ). . . , IOPS — — - .


, , , , . , , .


( , , , , .) , , . . , .


. , . - . , Sphinx Docker. Lua, NodeJS, Tarantool, React Native .

. . — /. , , , — .


The bottom level of interfaces are repositories. Repositories are responsible only for sending the data requested from external sources (database, search engine, cache) and transferring data to external systems (database, search engine, mail sending applications, etc.). The big advantage of repositories is a radical weakening of the connection between the application code and external systems. The decision on the choice of SMS delivery service provider or the final database can be made at the last moment.


From personal practice. In practice, the author of the note was two projects that lived the first months of writing code without a database. That is, the interfaces of the repositories were written down, simple storages were written under them, and at a certain moment they switched from storages to real databases without changing the application code.

In one of these projects, it was clear that according to the documentation Tarantool was ideally suited to the project, but none of the team had any experience of using it, there was no time to study it in the first month either, and it was decided to write code without a base. Tarantool was planned to be used as a base for storing data of a key-value type, including for massively retrievable and massively updated records. Due to limited use, the interfaces were laconic and their number hardly exceeded a dozen methods. In the case of epic problems with the base, it was planned to organize work with Redis on the basis of the same interfaces.
')
The result was a successful embedding in the Tarantool application, it fully met the expectations.

The top level is the API. In the case of a client-server application, this is the traditional REST API or Websocket API. In the case of a more traditional site with an MVC architecture, this is an intermediate layer from one class between the domain model and the controller. Also in the case of a traditional site, it is important to prescribe the rules for naming links, a list of the links themselves and the comparison of controllers with them.


After describing this small set of data, an application can be developed by a sufficiently large number of developers in an arbitrary order, and assigning tasks is limited to the list of interfaces and APIs for implementation as part of the task or the final API-based functionality. Arbitrary order means that regardless of the order of hiring programmers, they can write code to implement the tasks assigned to them, while the rest of the team members are hired. Arbitrary order also means that we managed to get rid of the synchronization of the programmers' work on the code: for some functionality, the backend takes more time than the front-end, and for some, on the contrary. And now it is only important to list the order of execution of tasks instead of one of the programmers constantly waiting for others, until they finish their part of the functionality and it would be possible to test the assembly.


If the technical project manager was lucky and was able to justify hiring a tester, then he can provide a great service to everyone. Namely, write functional and integration tests on the API. Since the API completely covers the backend of the functional, then with these tests you can track the actual progress of the development of the backend of the Internet application - this is just a fraction of the successfully tested API tests. Also, these tests will let you know which of the API methods and with which parameters it stopped working. This becomes critical after 5-6 months of rapid development.


You should also pay attention to the test data. They are still needed. The sooner they become available to developers, the more time will be saved on debugging. It is optimal to score them in the application immediately after the application database structure has been worked out and through this to test the completeness of the data links. Test data is best implemented in the form of fixtures that allow you to delete old data and fill in fresh.


The author of the note did not write about the importance of organizing the development environment, code formatting standards, rules for naming branches of the Git repository, CI, CD, etc. Everybody knows it. And this is really important. But it is much more important to follow these important practices than just to know about their importance.


Testing


Testing is necessary to guarantee some predetermined level of product quality. If a technical project manager can achieve this quality without testing or with the simplest manual testing, then let it work. If for some reason he is not satisfied with the quality of simple manual testing, then he will have to think about other options. It should be remembered that even in team development, you can maintain acceptable code quality for some time with simple manual testing. In the practice of the author of the article, this period is usually half a year.


Testing can be divided into:



The need to move to complex test options can be delayed due to a competent application architecture. The fewer inside the application there are complex connections and connections in general, the easier it is to manually test it. If each developed module is completely independent of the others, then when developing a new module, it is enough to manually test only it. The following module testing is required only if you make any changes to it.


Unrelated code is an unattainable ideal, since the smaller the internal connectivity of the application, the smaller the part of the code that is reused, the more complex and expensive the development. Therefore, much of the code will be related. The mastery of the architect is the ability to organize this connectivity in such a way that it is obvious when testing a new or revised functionality: the person performing the testing should be able to guess what else has been affected by this editing.


And so, with a certain dexterity for the first six months, one can do without automatic tests without special consequences. The key to this is a well-thought-out architecture with minimal coherence of various parts of the application and a constant Code Review: tracking violations in the architecture, overcoming implicit dependencies, and teaching programmers how to write more clearly, more clearly, and more correctly with the example of their own code.


The exception is complex functionality, which should always be covered with unit tests. Typically, this functionality is one or two percent of the entire code. But the cost of debugging such code, including debugging when making changes, will always exceed the cost of writing tests. Remember that tests allow you to make changes without danger of breaking something. In practice, the functionality is recognized as complex at the time of writing the technical specifications and this facilitates both the planning of tests and the protection of their need for a business leader.


Let's say programmers started writing code. Tests they do not write. A critical part of the work of the technical project manager in this area is to track errors in those parts of the application that have not been formally affected. That is, the programmer implemented something in the client part and this led to sudden errors on the main page. Several of these calls suggest that it is time to make a decision about code coverage with automatic tests. A project business manager may not agree with this. In this case, it is worth waiting until he decides that there are a lot of mistakes.


The tests at this stage, the stage of unstable code, should cover the API: it takes little time to write these tests and it quickly becomes clear where it fell. It is easiest to “sell” these tests to the business manager of the project, since he understands what is being optimized and that these tests directly solve a problem already realized by him: programmers rule in one place, but fall in another.


After about nine months of project development, it becomes clear that large-scale functional tests no longer save. Now came the turn of unit tests and active refactoring.


Under the conditions of an acute shortage of time, no one will ever give time to write unit tests, even realizing the need for these tests. Business requirements are arranged in such a way that the project business manager is forced to regularly issue a new result. The option “we will stop development, spend a third of the time already spent — about three months — on writing unit tests and the application will again become stable” will not work. The author of the note did not encounter that someone agreed to implement this option. The author did not hear the notes that someone could punch him. The author of the note did not even read about such miracles in literature.


A commonly used approach with a smooth code coverage tests. Either only the new functionality is covered, and the old one gradually becomes a legacy; or that functionality that is affected by changes and corrections of errors is covered; or use the “touched class - cover it with tests” scheme.


The choice of test coverage depends on funding and level of decision making. The first option is due to the apparent lack of money with a clear understanding of the need to stabilize the system. The decision is made by the business manager of the project. The second option is associated with good financing, but unavailability of the product to an avalanche-like increase in use. The decision is made by the business manager of the project with the consent of the investor. The third option is obtained in a situation where money is received under the rapid scaling of the product. The decision is made by the investor. It is in the third variant that the quality of the existing code and its radical stabilization become critical.


What to do if the problem is overdue, but there is no money, that is, the project is developing in the first embodiment? In such a situation, only the most problematic code should be covered with tests. It can be distinguished either by localization of previously found errors, or by places of the longest error correction, or by studying the code for the presence in the code sections of a large number of links, dependencies and complex logic. To do this, from the beginning of the project, it is necessary to keep a log of errors (for example, in the form of tickets for correcting errors in Jira), measure the time for correcting errors, interview developers to find out which parts of the code they find difficult and understand the code yourself. The latter is required rather to discard those suggestions of programmers that affect the improvement of an already quite useful code (that is, not as terrible as the rest).


And the last. It is noticed that if all the tests are performed for less than 3 seconds, then it is not difficult for programmers to run them. Especially if their launch is displayed in the browser and is done by simply updating the page. If the tests are performed for more than 10 seconds, then the programmers start to be lazy and send the code to the server, which was edited at the last moment, and did not want to wait for the tests to run. It is also noted that the regular presence of uncompleted tests in the main branch strongly demotivates developers to launch tests.


Writing a complete test suite takes up 30% of the development time. Manual testing, correction, retesting and so on until 40% of the total time is working. At the same time, automated tests guarantee some predetermined level of code quality. The choice is yours.


Infrastructure


The project's infrastructure can be divided into development infrastructure, communication infrastructure, and the infrastructure of environments (development landscapes, testing, deployment, etc.).


It should be understood that infrastructure is always about communication. Each member of the development team must understand how the entire infrastructure is arranged in each of its parts. The infrastructure must be documented and the documents must be accessible to all team members.


Of the features it should be noted that at the beginning of development only the development landscape is created. At the same time, a business project manager at a certain stage begins to use it as a demo stand for external users: investors, clients, management, etc. At the first such use, it is desirable to create a new environment. It will either become a demonstration and then the development environment will remain the development environment, or the development environment and then a part of the development environment (usually servers) will become a demonstration.


An indication of the need for such a division is the desire of the business manager to save data on a test server. If the technical project manager sees that some data has become valuable, then he should be offered to divide the environment into two: with stable data and with test data.


After the appearance of the demonstration environment, it is usually quite often that there is a perceived need for a test environment. Its purpose is to enable the business manager to make sure that the application is working before placing the version on the demo environment.


When entering the beta test, the business manager has a keen desire to have the product environment data on the test bench. In this case, the author recommends the following configuration:



If you choose hosting with modern virtualization technologies, then creating a demo environment with a small data set is a very simple procedure for cloning a production environment without stopping it. Moreover, some hosting companies allow you to clone production environments consisting of a large number of nodes. When choosing a hosting service, you should pay special attention to this option; it will save a large number of hours, which otherwise would have been spent on creating environments manually or automating the cloning of environments.


Documenting


The purpose of documentation is the understanding by the participants of the development of what was once done. On documentation in the conditions of an acute shortage of time they save almost always. And rightly so. In fact, the following is important:



To do this, simply do the following:



It is also advisable to fully document the infrastructure.


There is another useful type of documentation is the documentation on the architecture of the software product. It should describe how the system was developed, how it was built in general, what key decisions were made and why they were made just like that. This is indeed an important document because it allows you to continue development with a new technical project manager. In a situation of acute shortage of time from the technical project manager, it will be required only in the case of the termination of the project development and in the event of dismissal. A sophisticated business executive will require this documentation before starting work on a project in code - in order to understand the reason for making certain architectural decisions and, if anything, to influence them.


Start of operation


The product starts to be used suddenly. , , , , . , .


. -, . -, , . -, , — .


, . , , , , . , - . . , .


, . , MVP. .



, . . - , , , , .


, , - , , - . , . .


, , , . - . - — . - .


, - , - , - . , . , . , , — .


, . , , , . , SMS- .


.


. , — , . , . . , . 15- .


:



, , , - . .



, MVP . MVP: , , , .


. . . , , , .


, , . . : , : , , .


— MVP. -, , . -, « ». -, - . , , .


MVP : . . , MVP.


, — . - . , , , . , .


, , .



. , . . — . , - .


, — MVP, — .


. . . , , MVP — .


, - . , . , — .



. . - . , . , .


- . , . . . , .


, , , . , . , . , -. , , - . .


, , , . . . 25 40% .


, , . , , . , , - , . , , . , . , . — .


? , , . - — . , . , , .


, , . , - . , , , , .


, , «» . ?


-, , , , , . . , , .


-, , . , , , .


-, , . , . , - ( ). .


( — ) .


, . , , , . — - . , , . , — . .



35 , . . , .


- , . — . , .


, . . . .


— , . , , , , , , , .


. , - , . . , . . , . - « ».


. , , .


Conclusion


? , . , , .

Source: https://habr.com/ru/post/336540/

More articles:


All Articles