Tribes, guilds, build train and no TDD: how does mobile development work in Uber, Spotify, Odnoklassniki and Avito

    On the eve of AppsConf 2018, we interviewed specialists from large companies about the features and processes of large teams involved in the development of mobile applications. What approaches to work are used, what pitfalls await rowers entering the huge galley. Whether the foreign origin of the company imposes an imprint on the workflow - read about it all under the cut.

    Philip Uvarov, Android developer in Spotify. The company has been working for the last six months - in one of the platform teams that support other developers in Spotify. He lives in Sweden. Before Spotify, he worked in a Swedish startup, and even earlier in Avito.

    Artem Olkov, Lead IOS Developer in Odnoklassniki.  He is currently leading the iOS development of one of the products. In addition to the actual development, he is responsible for the architecture, design, distribution of tasks, coordination with the design, backend API, etc. In total, Odnoklassniki now has about 60 mobile engineers, who are divided into smaller teams. The team Artem - 11 people.

    Maxim Efimov, Senior software engineer in Uber.In the company works two years, is engaged in Android-development. Included in the “rider payments” team, which handles everything related to payments in the Uber passenger application. Prior to that, he developed for Android in other companies - mainly to order, and even earlier - he wrote in C ++ (server solutions for SCADA systems). In Uber, within the division that deals with payments, there are several other similar teams for other applications, as well as infrastructure teams - a total of several dozen teams.

    Evgeny Suvorov, head of mobile unit development at Avito: Mobile applications development has been around for eight years. I tried games, freelance, worked in outsourcing companies, in a large company, and then switched to product development.

    Let's start with the features. What distinguishes the work of teams with a large staff of developers in the company?

    Artyom Olkov (Odnoklassniki): In my opinion, the peculiarities are connected not with the scale of the company, but with how the processes are arranged inside it and what role the team plays in these processes. Roughly speaking, if your team makes a mobile platform, on which other applications or services of the company are based, 1000 requests from different corners will arrive to it and without a good product manager, development will drown. If the team makes a stand-alone service without complex integrations, the process will look much simpler.

    Maxim Efimov (Uber): In my opinion, the most characteristic feature is the speed of work.

    Small teams work much faster in principle. But at the same time, large teams have a final gross product of a developer, of course, more, because a whole group of people is doing about the same thing. And from this follows a different view on how projects are being implemented.

    In small companies, we often fit into the terms, conditionally, up to a day or a week. We can calculate and plan everything in advance. In large teams, this is difficult to do, because everything is tied to a large number of people. Therefore, the approach to planning is somewhat different. Projects are made with certain tolerances in terms, and the focus is on quality and the features themselves that we make. And only after that - the need to fit into the timeline.

    Another interesting point: how teams agree with each other. If the project employs five to ten people, they can be easily put together in a negotiation room and, having spent two to three hours, solve all the issues. And you can go on to do the project. But when hundreds of people are involved in the project, this will not work. We in Uber have certain communication mechanisms that allow teams not to interfere with each other, to effectively unite, etc. In small companies, in principle, this does not exist.

    Philip Uvarov (Spotify) : I think the main feature is that I don’t know all Android developers by sight. And we have very much shared responsibilities. This allows you to always be in the context of what you are doing, and quickly enough to deliver products in its direction.

    How does your team sync with others within the company?

    Yevgeny Suvorov (Avito): Our teams are connected by one mobile application - Avito. All of them contribute to this product, that is, we have a synchronization point in the code base and functionality.

    Philip Uvarov (Spotify) : We have cross-functional teams that deal with specific issues (for example, like us, developing analytics for mobile clients), are united into one big department - we call it “tribe” (tribe). As a rule, teams within one tribe are closely connected with each other, they have an active exchange of experience. Plus, of course, we have clients - these are other developers, so we support the solutions that we create for them.

    Maxim Efimov (Uber): We have small teams, each with no more than 20 people. They are integrated into structural units that are responsible for large areas, for example, a mobile application. At the same time, the teams themselves are quite autonomous, because if everything is reduced to a single management system with direct subordination, we will get a very inefficient system.

    The overall product idea is delivered to individual teams through product managers or owners. There is a separate structure that unites these people and helps to form an understanding of how and where we go. At some upper level, strategic goals such as concern for passenger safety can be defined. Well, the details are solved one to two levels lower. For example, we have certain security arrangements in countries where people mostly use cash to pay.

    Artem Olkov (Odnoklassniki): We are engaged in a separate service. So let's say we are a startup inside a big company. Understandably, we live in the same infrastructure. For the rest, we are very much separated. Even as part of the integration, we often use the public API of our own tools.

    Are there any problems typical for big teams? What do you have to face?

    Yevgeny Suvorov (Avito) : In my opinion, processes in a large team are the first to suffer.

    All guys are usually experienced, even juniors are able to solve technical problems. But problems with processes can easily slow down everyone, so processes are better automated.

    And that means high-quality Continuous Integration, Continuous Delivery, test automation.

    Philip Uvarov (Spotify) : I think the biggest problem is the spread of knowledge within the company. I may not have an idea of ​​what is happening in some distant teams. And the same is true in the opposite direction: many teams have no idea that we have an analytics team in Spotify. This is where the scale is felt.

    The second point is the speed of making innovative decisions: the adaptation of the same Kotlin and other new technologies. It's one thing to come and tell the five developers: “From now on, we write on Kotlin,” but it's quite another to say this to 100 developers. There is a huge infrastructure that needs to be translated, to somehow support these innovations (CI, etc.).

    Artem Olkov (Odnoklassniki): Yes, there are really two problems: the transfer of knowledge and coordination of actions, including modernization.

    Do large companies have any proven ways to solve these problems?

    Philip Uvarov (Spotify): To solve the first problem - sharing of knowledge - we have such a thing as guilds. This is a combination of developers by function, for example, the Android guild, which every two weeks holds some events: presentations, lunches, where you can discuss pressing problems or share something, etc. We also have, again, guilds , are internal conferences. Plus there are mailings, etc. A simple human problem remains: it's difficult to keep up with all this.

    I would like to highlight internal training (advanced training) as a separate line. We have our own Data University, where you can learn to a data engineer. Now colleagues are thinking about creating the same scheme for mobile learning.

    Artem Olkov (Classmates): We do not have pronounced guilds.

    Anyway, the guys united by one task intersect at different meetings - they know each other, communicate in a smoking room or at lunch. There are separate chatki, for example, purely for iOS-nicks. Inside the team, of course, the issue is resolved easier - we all sit behind the same “daisy”.

    If you have any questions, raise your hand, wave to the one you need - and he will answer you. For the transfer of knowledge, we use 15-minute morning rallies at which everyone tells how, what, why and why they did. There is also a certain layer of documentation, where the main points are put.

    The second problem - coordination of actions - is solved by competent management.

    Maxim Efimov (Uber): In fact, I don’t see a problem in the same sharing of knowledge. I see that the mechanism of sharing is different. In small teams, this is simply done in any way. Gathered - talked. And we have convenient processes that allow us to organize everything so that it works. By the way, I will talk about them in my speechon AppsConf 2018. The idea is that in our company almost all development is fairly transparent. People from any team can look at what other developers are doing, and use some of this for themselves.

    Evgeny Suvorov (Avito): We also organize meetings 2 times a week. We love automation, and this task is also automated. There is a process when, during the week, people cover topics that they would like to talk about at a general meeting of iOS or Android developers. And if there is a subpoena, we are going. During the meetings, the food teams tell about the features that they implemented in the product, because otherwise it’s difficult to keep track of everything that happens.

    We met from the very beginning, but it was with the growth of the company that these meetings became most relevant.

    Plus there are chat rooms where you can discuss any specific issues.

    By what principle does it make sense to divide a lot of developers in a company - by platform, by functionality or in some other way?

    Artem Olkov (Classmates): It still depends on what you do and how you earn money.

    I can, in theory, imagine the structure of an outsourcing company in which the division, for example, by platform will work. But for a grocery company, I can hardly imagine a different form of division, except by functional teams.

    Because if you gather in a bunch of all iOS nicknames, throw tasks into them, without having a very short bridge of communication with design, backend or testing, you will have to spend too much time on coordination.

    Philip Uvarov (Spotify) : We are all divided by product. For example, our team is engaged in analytics and it includes both iOS, backend developers, and many others. In my opinion, this is a very reasonable division of teams, which also leads to certain problems, but it works well on such a scale.

    Maxim Efimov (Uber):It seems to me that the idea of ​​dividing teams across platforms — iOS, Android, backend — on a large scale will not work very well. It separates developers quite strongly from each other, and as a result, synchronization of, for example, two mobile applications for different platforms will cost much more. And the profit from the fact that people in a team see only people from their platform, it seems to me, not so much. Yes, sharing knowledge is easier, but is it worth it? It seems to me no.

    Plus, the idea that some commands do basic things used by everyone else, such as buttons, lists, text input fields, seems interesting to me.

    Evgeny Suvorov (Avito): I agree . Such a structure is quite successful and we just recently introduced it in our Avito, at least in the grocery part of the business.

    Our team became a big one, probably, when we had five developers, since self-organization was difficult at this number. It became more difficult for the guys to cut one feature, they had to somehow separate them, plant them in different corners, according to different features. Disagreements began in architectural and other issues, and communication became more complicated.

    At one point, Avito had two big teams — iOS and Android development, 15 people each. And at this stage we began to break up into grocery teams: the “customer experience”, “seller experience”, messenger, delivery, etc. were distinguished. This resolved the issue of priorities. Previously, many project managers came to the teams with requests for features, and for them each of these features had priority number one. As a result, we have 20 projects and their cross-cutting priorities are not clear. Higher people had to manage it manually. After the allocation of multi-functional teams, each of which has its own development pipeline, its own priorities and resources, everything has become easier.

    At the same time, we still have small platform teams that make, as we call it, “horizontal” solutions that roll out to all product teams.

    How often do teams reorganize?

    Philip Uvarov (Spotify) : Some movements occur every week. In our company, the teams are small and autonomous. If you wish, you can very easily go from one to another. How often this happens depends on the team and the direction in which you work. Where I work, it is not pronounced. But Spotify is famous for the fact that we work on agile and in many ways things like OKR, etc., have come from us. Therefore, the company’s management is not afraid to change priorities if it suddenly realizes that something is not working. We just switch to something else.

    Maxim Efimov (Uber):We had large-scale reforms related primarily to the very rapid growth of the Amsterdam office. During the year, the number of employees almost doubled. Those teams, where people were recruited, became very large and it was difficult for one manager to manage such a structure. In this regard, the teams were simply divided into several "subcommands", each of which was engaged in a narrower sphere. I think this is a natural process.

    Do you agree with the idea that in a large team, so that the quality of the code does not suffer, it is worth avoiding hiring over-qualified juniors and seniors?

    Philip Uvarov (Spotify): I think neither one nor the other. Every year Spotify recruits quite a few university graduates through summer practice (some of the people after the practice receive an invitation to work). Similarly, we easily take people with several PhDs.

    Technical qualification is cool, but it can be taught. If a person does not know how to work in a team, then it will be extremely difficult. Therefore, in such companies almost more attention is paid to software skills.

    And so that the quality does not suffer, we need good interviews that will allow selecting developers who are not below a certain basic level.

    Maxim Efimov (Uber): We are repelled by a slightly different principle. We have the desirable mix of experienced developers and junas. Just so that there is no situation when there is a crowd of June, and there is no one to help them and explain how to work. Therefore, we try to keep a balance.

    I do not see the point of sticking to the principle of “not gaining too many seniors”. The quest for the seigneur is a rather difficult quest. There are a lot of companies on the market, and the competition for developers is serious. People with experience successfully work in almost any place, so it’s unrealistic to refuse qualified personnel today and then recruit them tomorrow. These people will not sit and wait until we want to invite them. And in my practice, if a person has good competencies, it is not a problem to find him a place in the company. But we must build on the specific situation. We need to make a decision depending on what ambitions each person in the team has, look at the upcoming projects, whether we can pull them out on our own, who we need. That is, it is necessary to go down on low-level planning.

    Yevgeny Suvorov (Avito): In my opinion, when recruiting seniors, you should not be afraid that they have their own king in their heads or that they will not obey.
    In our company, the developers themselves offer ways to solve these or other problems. And seniors often have these quality solutions. They have experience, therefore with their participation problems can be solved more quickly. There is another problem - your tasks may not seem interesting or ambitious to the seniors.

    For juniors, too, must be approached individually. When we were still one team, an intuitive feeling periodically appeared that the team could take out another jun. And at that moment it was possible to take a beautiful ambitious guy who quickly grew to a quality engineer. In a team with well-established processes, learning is really fast. Yes, and juny are different - some come after high school with glowing eyes, but they don’t know how, while others have seven years of experience backend, they just have just switched to mobile apps.

    That is, we are not afraid of juniors, but we are guided by the feelings of the team - whether it needs it or not.

    Planning, synchronization, task distribution

    How much effort does planning and synchronization of developers take within a large company (even if in small teams)?

    Philip Uvarov (Spotify) : This is just a plus of dividing teams by product, not by function: we only plan our small product within the company and we often don’t care what the rest million developers do there.

    Artem Olkov (Odnoklassniki): Here I can only tell you about our specific team. We have the beginning of development, and it gives certain concessions - allows you to be freer. At the moment we only have daily 15-minute rallies on the current status and hourly closing of the previous / planning the next sprint once a week. Everything else is decided in a personal manner.

    Maxim Efimov (Uber):In our case - not very big. Perhaps, times in 1,5 - 2 more than it took me when I worked at an outsource.

    True, there are some processes in the company, such as code review, which inhibit development. Roughly speaking, until a team responsible for its piece of code looks at your commit, it may take just some time. But I don’t think it refers to a sync fee. It’s rather about how the whole scheme is set up at a low level - who is reviewing whom, how is waiting organized, etc.

    Evgeny Suvorov (Avito): We initially solved the synchronization problem with frequent releases. As a result, now synchronization itself takes a bit. Everything is almost automated.

    Do I need to distribute tasks in a special way so that the quality of the code does not suffer?

    Philip Uvarov (Spotify) : In large teams, it makes sense to distribute the product by area of ​​responsibility. Thus, on tasks there will always be people who approach them responsibly, because they also live with it later. They do not change the context, i.e. there is no situation when all the developers are involved in absolutely everything (Peter wrote 10 lines here, Vasily added 5 more below and as a result there is a mess that cannot be maintained later).

    Moreover, if you work inside a small “product inside a product,” you should more or less understand how this whole system works from the backend to the client.

    Evgeny Suvorov (Avito): As for quality, it is better to rely on testing and code review. For example, in my team now the guys with the mobile development background are sawing microservices on the backend in three languages ​​- Python, PHP, Go - which must withstand the load of Avito. But communications, test automation, etc. provide at the entrance of the junior, and the output - high-quality piece.

    Can you remember one or two of the most interesting tasks that your team has been facing lately?

    Artem Olkov (Classmates):As I said, we are making a new product. The most interesting task for me personally, as for the person who leads him, is his planning and design: build architecture, think through what the user will have and what will not, and how the developers live with it.

    Evgeny Suvorov (Avito): The most interesting thing we encountered in mobile applications was modularization - breaking our code base into separate modules that can develop independently without interfering with each other.

    For example, viewing ads and delivery screen in principle with each other are not related. But in the code base they were not separated, and when the developers did something, their colleagues were blocked. My team was just gathered around this division task. It took us about six months and it was interesting first of all technically.

    On backend microservices originated a long time ago, and in mobile applications this trend appeared quite recently - maybe a year or two ago. And then in large foreign teams, in Russia there are so few.

    Technology stack

    Have you encountered any revolutionary changes in the technological stack in your company / team recently? And in general, how do such processes take place?

    Philip Uvarov (Spotify) : We rarely practice this. There are experiments on the introduction of new technologies, in particular, with the Gradle move to Bazel or with Teamcity to our internal system, but no more. I think that such revolutions are impossible with us.

    Maxim Efimov (Uber):Before Uber, I had this experience, but here it is an ongoing process. There are a few people, including me, who favor Kotlin. There are certain things we need to figure out how to work. But overall this is possible. We are working on it now. We do not have to sit and wait until the "most important developer" says: "Now you write on Kotlin." Kotlin is already used in part of our codebase, but still in process.

    On the whole, global changes in architecture are taking place, and they also come from our team. The initiative from people who want to solve some kind of personal pain, we have quite acceptable. If everything is done correctly, these changes are accepted.

    Evgeny Suvorov (Avito):We have two platform commands that saw tools for internal use. Company growth and modularization have changed the way these teams work. They had to communicate a lot in order to understand what the final consumers (developers) need.

    In terms of technological change, we have Technology Radar. Often, developers say: “Let's introduce this thing instead of the one that we have been doing for 5 years, because it is morally obsolete. ” To deal with these proposals, we have brought Technology Radar, in which the one who has the initiative, has to climb into a small bureaucracy, do some research, express in digital metrics that innovation will speed us up, but something will slow us down. That there are some risks regarding the new technology. This will be reviewed by several colleagues and, if all is well, the technology will be applied. True, with Technology Radar offers become less.

    Is it harder to carry out such reforms with the growth of the company?

    Maxim Efimov (Uber):More difficult, but not much. Suppose there are 10 people in a small company and someone alone wants to change something. To do this, he needs to negotiate with nine people. If you have 100 developers, this does not mean that you will need to come to an agreement with 99. Of course, not everyone will be actively involved in this, it is not as difficult as it could be.

    Which of the latest technologies do you personally find most interesting from the point of view of application in large teams (even if they do not work in your company)?

    Evgeny Suvorov (Avito): Probably, the key ones are microservices, the division by domain areas, the division into teams that have their own priorities. In terms of technology - everywhere its features.

    For large teams, you need to be a little retrograde and not get into the alpha-beta versions of the tools, because you never know what this will lead to.

    Although there are exceptions. Due to the module partitioning, the Android project suffered - the IDE took the project model for a very long time and only the new early adopted preview versions helped. There were experimental ticks, with which everything became steeper to work.

    Philip Uvarov (Spotify) : I think Kotlin is one of the super-promising things. It seems to me that soon everyone will forget about Java on Android, especially if Kotlin gets a little better with builds and we can go to it. As far as I know, many big teams - like Facebook - have long opposed Kotlin just because there are huge projects that have been going for three years without these problems, and Kotlin will have six years together.

    From the last one personally seems to me quite interesting Flutter.

    Artem Olkov (Classmates):I believe that the best technology stack in the context of iOS development is native, which Apple provides. Additional frameworks are often not needed. There are interesting tools, but they are built by very large teams only for their own needs. Outside of these teams, they often add just more pain.

    There are a couple of very interesting approaches that are now in trend, and some of them are deservedly so. I would like to mention specifically Unidirectional Data Flow.

    What do you think about the gradual transition to Swift?

    Artem Olkov (Classmates): This is a complex topic. Now we have started a new project and we are all on Swift, but there are 150 lines on Objective-C, because for some reason, we were unable to do what we needed with the help of Swift in a relatively laconic way.

    If you have everything in Objective-C and it suits you completely, is there any point in switching to Swift? For many guys I know, the transfer of the code base to Swift is exactly the HR-PR story, because there are a lot of new developers on the market who simply don’t know Objective-C and don’t want to learn it.

    Evgeny Suvorov (Avito): This is our case. We got into Swift at one time and he slowed down our build time. In general, there were a lot of drawbacks, but for us one of the key points was that this is such a hype, which we can hire many developers for. In general, it justified itself to a certain extent. Swift is developing now, but in Objective-C it would probably be faster, more convenient and fewer problems.

    The idea of ​​long-term support may be a reason for the transition (there should be more developers in the future)?

    Artem Olkov (Classmates): This question is not so easy to answer. Apple is still in a position where they can say that Swift is no longer supported, and give it to the development of open source. The probability of such a development of events is very small today, but it is not zero. Objective-C is still getting improvements.

    Personally, my opinion (they may not agree with him on Odnoklassniki) - if you just take objective facts - in five to seven years both languages ​​will live, and developers will just need to be able to work with that and with that. It is not difficult if you understand the basic concepts. Knowing one, learning the other is not such a big problem. Today, iOS development is no longer about language proficiency, but about knowledge of the framework on which you work.

    Development and Testing

    When do you write tests? TDD or after writing the code?

    Philip Uvarov (Spotify) : To be honest, given the launch of builds on Android, I don’t believe that you can effectively write tests before the code. We usually write tests in parallel, along with development.

    Artem Olkov (Classmates): It all depends on what tests we are talking about. Unit-tests on the conscience of the developer team.

    Specifically, in our team, we cover Unit-tests with only certain layers, in which we need to be sure (we see problems on other layers right away). If these are integration tests (API, UI, etc.), testers are responsible for them as they become available.

    Maxim Efimov (Uber): I know, part of our backend loves TDD, but I don’t know such people among mobile developers. It is important to us what happened in the end, and the sequence in which the person wrote it is his own business.

    Evgeny Suvorov (Avito): A tester is present throughout the entire life cycle of a feature. At the very beginning, it helps in the formulation of the problem, determines the functional requirements, describes the acceptance test cases. UI- and unit-tests are written by the developer himself. In principle, the tester can also write them - we have a separate team that deals with a tool for writing UI tests.

    The tests themselves can be written independently at any stage. On which - small teams decide on their own. They may or may not use TDD.

    In general, the practice of TDD is not very popular. We in the Android community have a person who really practiced it and tried to find like-minded people. He is speaking at AppsConf 2018 with a talk about TDD.

    But mostly tests are written after the feature has been written.

    Do you have any coverage standards?

    Philip Uvarov (Spotify) : They can be different, depending on the task. But 100% coverage of business logic with unit-tests is mandatory.

    Maxim Efimov (Uber): We have a general understanding of what we are doing tests. But no one anywhere says what the percentage of coverage should be. Teams define it themselves.

    Is there any “golden” ratio of testing and development in the project from your point of view?

    Philip Uvarov (Spotify) : I can’t name the ideal proportion - it all depends on the task.

    For example, if we make a prototype of something (proof of concept of some idea), probably, here testing will tend to zero. If we make a product that will be used by the entire company with a high load, then the same time should be allocated for testing as for development.

    Evgeny Suvorov (Avito): We have two QA engineers who test not only the mobile part, but also the backend, frontend and everything else for the largest team including four mobile developers. But the ideal ratio depends on the details of the organization of the process. For example, there are six engineers in my platform team, but in principle there is no QA.

    Do you have code quality control procedures within the developer community?

    Philip Uvarov (Spotify) : Yes, code review is one of the basic checks. Plus, we have a lot of checks performed on CI: we have several tools connected to static code analysis, which check the code style and everything, and I’ll partly talk about this in my report on AppsConf 2018.

    Artem Olkov: In Odnoklassniki there is a pull request, there is a control of the code style provided by formatters; There are linters that reveal simple errors. There are builds with tests, rules for maintaining git. All are very small steps towards a great goal: to make the codebase good.

    Maxim Efimov (Uber): Code review is such a thing that cannot be avoided. You can not fill a commit, if no one looked. But the process teams set up themselves.

    Evgeny Suvorov (Avito): We also provide code review-processes through pull-requests. When a developer implements a new feature, contributing code, he creates a pull request, which passes a series of automatic checks, including quality checks. Then the code is looked at by the neighbors developers.

    We started this process as soon as the second developer appeared in the team. As the company developed, the process itself changed. At first it was manual, then automation appeared. A little later, we increased the number of units from one to four, otherwise people were not ready to make decisions affecting the growing code base (“what if I misjudged?”). When divided into multi-functional teams, when people scattered across different units, we slowed down the number of units to two.

    In fact, it is a regulated process. As the company grows, the code base evolves, repeating the structure of the company. The team broke into units, we also began to modularize the code base, so that the individual units do not interfere with each other and can be developed relatively independently. This was a long story. Naturally, this was reflected in pool-requests and code review. In parallel, we are trying to automate what is possible.

    How often does it make sense to release releases in a large company project?

    Philip Uvarov (Spotify) : The more often, the better.

    Artem Olkov (Classmates):It also very much depends on the business, users, distribution model. For example, prior to Odnoklassniki, I worked at Akronis. There, the mobile application is a component of a large desktop product, and its releases were tied to desktop releases. The big product had two big releases a year — summer and winter — that’s historically. Therefore, the mobile application was released in summer and winter. In between there were only hotfixes and some quick fixes.

    In Odnoklassniki it also depends on the team. For example, Android developers will be released hard every week.

    Maxim Efimov (Uber): It seems to me that the way it is organized here is quite reasonable and convenient. We have releases on a regular basis.

    There is a so-called build train, which departs every Monday. If something is not in it - waiting for the next release. Because otherwise, synchronization will be very expensive.

    In general, this is a matter of business level. We had two situations in which we did not submit to weekly releases: this is when we completely rewrote our application for passengers and drivers. But in the ordinary life of major changes, we do not, it is more convenient regular releases.

    Evgeny Suvorov (Avito): Initially, we had releases once a month - these are only 12 releases per year. If you do not have time to make a feature in a certain release, then you wait another month. As a result, people tried to delay releases, because of this, other teams were inhibited and the quality suffered (some features were completed in a hurry, anyhow).

    As a result, we also came to the popular release trains, which are not waiting for anyone. We increased the frequency of releases. The first point was releases every three weeks. The second point is once every two weeks. We are now at this point and are striving to make it technically possible to release once a week. Not the fact that we will use this opportunity - there is a possibility that users will not want to see updates of our application so often. And it's not a fact that developers will have time to implement some full-fledged functionality in a week. Therefore, while two weeks for us look optimal.

    But I definitely cannot recommend a two-week or weekly cycle to all developers. As a colleague mentioned, there are products that have a release cycle measured in months and this is due to very thorough functional testing. But there are quite complex processes. And we try to simplify everything. We are more comfortable with the high frequency of releases, so that teams can not think about when the next date, but simply do the necessary functionality. In the worst case, in two weeks he will be in production.

    Large teams have other differences. The speakers and their colleagues will talk about the details at AppsConf 2018ApplsConf 2018 . There will be talk about tools and principles of organizing large-scale teams.

    Also popular now: