Which is better - 1 mobile development team or 15?
The role of IT in banks is difficult to overestimate. This is security, and the coherence of all transactions, and much more, which the end user rarely guesses in principle.
The main thing without which it is difficult to imagine a modern bank is an adequate application for mobile devices. Man is a creature, loving comfort, and quickly getting used to it. Therefore, if we now take and return everyone to the paradigm in which the bank and any interaction with it - these are trips to the branches and filling in the papers for any ordinary operation, everyone will feel very sad.
The bank must be available, the application must give the opportunity to conduct the maximum available number of transactions, set up auto payments, transfer money to friends, pay for everything you can pay for, order cards, etc., etc., etc.
')
In Alpha Bank, we have Alpha Mobile and Alpha Business-Mobile for this.
My name is Ilya Tsarev, I am Head of iOS, and today I will tell you how we have the process of developing mobile applications.
I have been working at Alfa-Bank for more than 2 years, I started with a senior developer, and now I am responsible for all iOS development. A year ago, we had six iOS developers for everything. Now we are 19. We managed to scale the development process normally, without losing in quality and greatly adding to speed.
We had several periods of rapid development. It all started 2 years ago, we completely changed the development team, at that time it was one big team - 2 iOS, 2 android, several designers, one product, analysts, and the whole crowd (about 20 people in total) developed Alpha Mobile.
We worked in this team and once a month we released an update of the application, which included about 3 features on average.
In the second half of 2016, we divided this crowd into three parts. As a result, it turned out that there is an application "Alpha-Mobile", on which three teams work, each of which has its own specific piece of work. These teams are small, 5-8 people each. In each - one participant in each role, that is, 1 iOS developer, 1 android developer, 1 designer, 1 product, and so on.
In addition, each team can cut their pieces, regardless of the other teams. For example, the team number 1 is engaged in payments and transfers. Team number 2 - affluent-clients (these are the guys who usually spend significantly higher than average, and, of course, are quite important for the bank). Team number 3 - redesign and all sorts of general improvements.
When we did all this, it turned out that it works much better than it was within the same team. Each team made its own features, decisions within teams were made faster, and as a result, more functionality came into the release than from one big team. Well, it started, we decided to do not 3 teams, but 20 pieces.
And this is exactly what we started to do in 2017.
Today we have 15 teams (including Alfa Mobile and Alfa Business Mobile), this is all very fragmented, and each team does its own piece of work again. Someone makes payments and transfers, someone - narrowly focused features, for example, under our cooperation with FIFA. At the same time, if the guys from this team make it so that right now they have no FIFA tasks - they start doing something else, for example, they improve the authorization process and so on.
As a result, we get that we have 15 teams, they are doing something in parallel, thanks to which we are being released every 2 weeks, and each release contains much more features (about 10) and edits than before.
In words, such an alteration sounds quite simple, they say, they took and scattered people on teams, each of which does something different, but in fact it entailed quite complex changes in the technical process. After all, the team is isolated, communicates for the most part within itself, around this whole thing is also a layer - iOS, Android, design. All this needs to be synchronized, otherwise everything :)
So that all this does not fall apart on the move, we have led the technical process to the following form:
At the same time, we have a number of automatic checks, we check such code with a static analyzer (swiftlint), it allows you to quickly fix problem points, for example, there is no bracket somewhere, or there is a risk of memory leakage. Speaking a little more about swiftlint, we have included almost all the standard rules, as well as some of our own. All this allows you to save time on the code review.
Continuous Integration server (in our case Jenkins is used) runs a static code analyzer, runs tests in the application, helps build and run it, and also writes about all this to Slack. After all this, a manual code review is already underway.
When the code is accepted, our favorite jenkins builds several assemblies: for installation on test devices, for autotests and for possible release. A tester within a team checks for such a build, and if all is well, then the code can be merged into the next release.
Recently, the AppStore allows you to roll out a new release not for all people, as before, but for a certain percentage of users. Therefore, we first roll out new features to 1-5 percent of users, see what is there and how in general. If necessary, fix something, roll out already by 10 percent, and so on. In addition, we have our own solution, which allows you to roll out specific features into specific groups of users and manage all of them flexibly. These two mechanisms allow us not to be afraid to carry out both technical and product experiments.
All of this is hung inside with detailed analytics, which allows us to understand in time what went wrong and where, and how to fix it quickly. You can also determine that only 2 percent of users access some section of the application, while the remaining 98% ignore it. Usually this hints at the convenience of the location of the section or its meaning in general.
Now, 15 iOS developers are working on Alfa-Mobile. Above Alpha Business Mobile - 3.
In addition to the product teams, the guys actively participate in the so-called technical teams, which appeared in parallel with our scaling. We have a team that monitors the architecture (by the way, this team has developed its own solution , which we use in Alpha Mobile), a team that develops a design system, and a team that improves our CI / CD. All this time is given to the guys in the grocery teams.
The design system team is developing a library of UI components. When a developer writes something that can be useful to everyone, he uploads it to the general library. Therefore, when we have a new project, the team can immediately connect to this library and get a lot of ready and useful.
By the way, about the perfect number of teams. As a leader, I can say that there are already too many of us (without panic, we still actively engage mobile developers). I just mean that the more people - the more time is spent on synchronization, and this is normal. By the way, for this reason we do not consider junior developers (although, I confess, there are exceptions).
We mainly hire middle, middle + developers. These are people who are already confident enough to know the necessary technologies, but at the same time they can be sharpened for themselves and trained specifically to work in current teams. We use a lot of new technologies, for example, we have more than half of Swift code, our own architecture and there are several other things that are usually not so actively used. Of course, standing senior will also be appreciated. But we prefer to form the leads already within the company.
Right now we have an active set of mobile developers, we have a number of new teams (there are a lot of products with ideas, and they need people in the team), so if you feel the strength and desire to try yourself in developing mobile applications for Alpha Bank, do not hesitate - https://hr.alfabank.ru/vacancies/ios-dev
I would be happy to answer questions about the features of the development of mobile applications in the bank or about the general principles of our work.
The main thing without which it is difficult to imagine a modern bank is an adequate application for mobile devices. Man is a creature, loving comfort, and quickly getting used to it. Therefore, if we now take and return everyone to the paradigm in which the bank and any interaction with it - these are trips to the branches and filling in the papers for any ordinary operation, everyone will feel very sad.
The bank must be available, the application must give the opportunity to conduct the maximum available number of transactions, set up auto payments, transfer money to friends, pay for everything you can pay for, order cards, etc., etc., etc.
')
In Alpha Bank, we have Alpha Mobile and Alpha Business-Mobile for this.
My name is Ilya Tsarev, I am Head of iOS, and today I will tell you how we have the process of developing mobile applications.
I have been working at Alfa-Bank for more than 2 years, I started with a senior developer, and now I am responsible for all iOS development. A year ago, we had six iOS developers for everything. Now we are 19. We managed to scale the development process normally, without losing in quality and greatly adding to speed.
Then
We had several periods of rapid development. It all started 2 years ago, we completely changed the development team, at that time it was one big team - 2 iOS, 2 android, several designers, one product, analysts, and the whole crowd (about 20 people in total) developed Alpha Mobile.
We worked in this team and once a month we released an update of the application, which included about 3 features on average.
In the second half of 2016, we divided this crowd into three parts. As a result, it turned out that there is an application "Alpha-Mobile", on which three teams work, each of which has its own specific piece of work. These teams are small, 5-8 people each. In each - one participant in each role, that is, 1 iOS developer, 1 android developer, 1 designer, 1 product, and so on.
In addition, each team can cut their pieces, regardless of the other teams. For example, the team number 1 is engaged in payments and transfers. Team number 2 - affluent-clients (these are the guys who usually spend significantly higher than average, and, of course, are quite important for the bank). Team number 3 - redesign and all sorts of general improvements.
When we did all this, it turned out that it works much better than it was within the same team. Each team made its own features, decisions within teams were made faster, and as a result, more functionality came into the release than from one big team. Well, it started, we decided to do not 3 teams, but 20 pieces.
And this is exactly what we started to do in 2017.
Now
Today we have 15 teams (including Alfa Mobile and Alfa Business Mobile), this is all very fragmented, and each team does its own piece of work again. Someone makes payments and transfers, someone - narrowly focused features, for example, under our cooperation with FIFA. At the same time, if the guys from this team make it so that right now they have no FIFA tasks - they start doing something else, for example, they improve the authorization process and so on.
As a result, we get that we have 15 teams, they are doing something in parallel, thanks to which we are being released every 2 weeks, and each release contains much more features (about 10) and edits than before.
In words, such an alteration sounds quite simple, they say, they took and scattered people on teams, each of which does something different, but in fact it entailed quite complex changes in the technical process. After all, the team is isolated, communicates for the most part within itself, around this whole thing is also a layer - iOS, Android, design. All this needs to be synchronized, otherwise everything :)
Technical process
So that all this does not fall apart on the move, we have led the technical process to the following form:
- there is a developer who writes his code with inspiration;
- there is our common code in the remote repository;
- when the developer finishes, he creates a pull request (no less inspired) and writes to the guys, they say, I’ll do everything, let's add.
At the same time, we have a number of automatic checks, we check such code with a static analyzer (swiftlint), it allows you to quickly fix problem points, for example, there is no bracket somewhere, or there is a risk of memory leakage. Speaking a little more about swiftlint, we have included almost all the standard rules, as well as some of our own. All this allows you to save time on the code review.
Continuous Integration server (in our case Jenkins is used) runs a static code analyzer, runs tests in the application, helps build and run it, and also writes about all this to Slack. After all this, a manual code review is already underway.
When the code is accepted, our favorite jenkins builds several assemblies: for installation on test devices, for autotests and for possible release. A tester within a team checks for such a build, and if all is well, then the code can be merged into the next release.
Recently, the AppStore allows you to roll out a new release not for all people, as before, but for a certain percentage of users. Therefore, we first roll out new features to 1-5 percent of users, see what is there and how in general. If necessary, fix something, roll out already by 10 percent, and so on. In addition, we have our own solution, which allows you to roll out specific features into specific groups of users and manage all of them flexibly. These two mechanisms allow us not to be afraid to carry out both technical and product experiments.
All of this is hung inside with detailed analytics, which allows us to understand in time what went wrong and where, and how to fix it quickly. You can also determine that only 2 percent of users access some section of the application, while the remaining 98% ignore it. Usually this hints at the convenience of the location of the section or its meaning in general.
Teams
Now, 15 iOS developers are working on Alfa-Mobile. Above Alpha Business Mobile - 3.
In addition to the product teams, the guys actively participate in the so-called technical teams, which appeared in parallel with our scaling. We have a team that monitors the architecture (by the way, this team has developed its own solution , which we use in Alpha Mobile), a team that develops a design system, and a team that improves our CI / CD. All this time is given to the guys in the grocery teams.
The design system team is developing a library of UI components. When a developer writes something that can be useful to everyone, he uploads it to the general library. Therefore, when we have a new project, the team can immediately connect to this library and get a lot of ready and useful.
By the way, about the perfect number of teams. As a leader, I can say that there are already too many of us (without panic, we still actively engage mobile developers). I just mean that the more people - the more time is spent on synchronization, and this is normal. By the way, for this reason we do not consider junior developers (although, I confess, there are exceptions).
We mainly hire middle, middle + developers. These are people who are already confident enough to know the necessary technologies, but at the same time they can be sharpened for themselves and trained specifically to work in current teams. We use a lot of new technologies, for example, we have more than half of Swift code, our own architecture and there are several other things that are usually not so actively used. Of course, standing senior will also be appreciated. But we prefer to form the leads already within the company.
Right now we have an active set of mobile developers, we have a number of new teams (there are a lot of products with ideas, and they need people in the team), so if you feel the strength and desire to try yourself in developing mobile applications for Alpha Bank, do not hesitate - https://hr.alfabank.ru/vacancies/ios-dev
I would be happy to answer questions about the features of the development of mobile applications in the bank or about the general principles of our work.
Source: https://habr.com/ru/post/346298/
All Articles