Part of the team, part of the ship
The processing of the Internet bank has been brewing for a long time, not only in the bright heads of managers and vice-presidents, but also in the inquisitive minds of developers.
Tinkoff Bank ekubyshin, the head of the web development department, decided to share how the work on this large-scale project was structured and conducted.
Rumors about the upcoming development of a new Internet bank went all over the office already while working on the portal redesign in February 2014. At the beginning of the year it was clear that there would be a very large amount of work, and it would have to be done in a short time, without harming the quality of the product, and as you know, the speed of development is the direct enemy of quality.
')
Therefore, in order not to release a raw product and not process it on weekends and evenings, driving the whole team to the underworld, it was necessary to think up a development plan long before the problem was set, and also to understand what the new Internet bank should be like and how to speed it up. development in technical terms.
Obviously, some of the work is completely independent of the formulation of the problem or the timing of the preparation of designs.
After thinking about the upcoming project, about what can already be started to do, and in passing after seeing the upcoming changes at the prototype level, it became clear that there would be more work than originally thought.
As a result, the picture according to the preliminary preparation was the following:
1. selection of technical lead, which will work out the architecture and lead the entire project;
2. selection of the team and its recruitment;
3. study of the project architecture;
4. choice of technologies, frameworks and tools;
5. build a working prototype without designs.
The most important and decisive condition for the successful development and launch of the project is an excellent team that will work on it.
Obviously, in addition to developing a new Internet bank, there are also other projects that need to be maintained and developed, therefore, some of the developers' resources had to be left free.
The management approved the hiring of additional developers, without which the team would not be able to be staffed. The first thing to do was to find a great one. Lead, who will lead all other team members and develop a project framework with which his colleagues will work.
Finding a technical lead, and indeed a technically advanced developer in a bank, is quite difficult, since developers, especially the front-end, have a false prejudice that it is not interesting to work in a bank. Therefore, a beautiful job full of cool keywords such as NodeJS and AngularJS is important for selection, and we still need a lot of perseverance and patience in selecting from a huge number of resumes and searching on the Internet beyond the well-known “resume portal”. Every day, the Tinkoff HR department did a tremendous job of finding developers, fulfilling all the whims of customers.
I will say briefly: it was very difficult to find a technical lead, and it was not without banal luck and the coincidence of the moon phase. And the miracle happened - I managed to interest a fairly strong developer.
Then it went on the knurled, and the team was completed quite quickly: apparently, the period of activity of the applicants and the launch of the new portal design had played. As a result, we managed to assemble a very strong team of professionals to whom we are grateful for the heroic and difficult work.
When we found the technical lead, it is time to start working on the architecture and analysis of the technologies and tools that we will use.
The hardest part is to prove to managers who want to release as many tasks as possible as quickly as possible, that one or two developers should be pulled out of the current project support sprint, so that they can start working on some kind of obscure magic called “project architecture”, which is not clear when will run.
We managed to do this step by step, initially pulling out only 50% of each developer, and then already saying alpha-masculine “SO NEED” and pulling out the necessary developers 100% - and then it was already gone.
And what did we do? And about the following.
We spent a week or two on the analysis of various frameworks, their features and capabilities, on all sorts of holivars and games to do-lists. We analyzed our experience of using BackboneJS, EmberJS, estimated about a new project and realized that for many reasons they are not suitable for it. Played with different collectors, reasoned that it was better - BEM or SMACSS, LESS or Stylus and so on. In general, they didn’t deny themselves practically in anything, but at the same time they tried not to go deep, as there was not so much time.
After all searches, we stopped at AngularJS, as it gave a number of advantages:
1. two-way data-bindings;
2. A bunch of ready-made “boxed” solutions: services, caching, dependency injection, routing, quite convenient syntax of directives and filters;
3. a new and interesting framework, under which you can recruit new developers pretty well and quickly;
4. interest of developers to the project on a new framework;
5. fairly quick and easy entry, which was very important to us.
AngularJS did not seem complicated or incomprehensible, and everything that a developer needs for familiarization was on the official website, and then we went by trial and error.
While they were doing all this, the very, very distant prototype of the new Internet bank was already in time.
Then the lead began to develop a platform for a new project.
This part of the work consisted of:
1. study of the architecture of modules: initialization, drawing, configuration;
2. routing and rendering pages;
3. assembly and deployment of the project on test benches;
4. Request service to work with our API with the possibility of caching and validation.
In parallel, we began to try NodeJS + Express + MongoDB to prepare a platform for a secret project.
The result was the following technology stack:
1. AngularJS
2. RequireJS
3. BEM (but only naming, without bemtools)
4. LESS
5. Gulp
For the new IB, it is enough for nginx to give index.html with the build and all the statics, and everything else remains on the shoulders of the browser.
The output was a platform a la AngularJS Bootstrap, on which you can build SPA applications. Who knows, maybe we will post the code on github.
When the prototype was already in principle ready, the designs arrived.
What's next? Immediately take to impose and pull on the finished code? Not! Now we had to draw up plans for launching and developing, a Gantt chart (for You-Know-Whom) and to prove that if you make a new Internet bank, it will be completely new, not only in design and functionality, but also technically new.
The banking sector is a very aggressive and fast market, and in the conditions of tough competition everything has to be done rather quickly. And here time plays a decisive role - when and in what form the product will be released to the market.
It was not easy to prove to managers and business customers who want everything to be done quickly and beautifully, the need to completely redesign the architecture and rewrite all the client’s business logic, but we had serious reasons that worked:
1. old and technically imperfect code is difficult to maintain, and support will ultimately be more expensive than new code without errors, flaws and blunders that have arisen because of the rush to develop;
2. a ready-made prototype, which is already working and on which you can build up business logic;
3. trust in the team, which we deserve the hard work.
We decided to develop everything from scratch, and the team as a whole began its work.
To hell with SCRUM, give KANBAN! It is impossible to imagine how you can develop such a large and complex project, the requirements for which are constantly changing during the work, using SCRUM, wasting time on planning and sprints. Here SCRUM will not work - it is good only when the project is already running and there is some kind of road map.
So, we already have a little bit of a working prototype, several designs, technical task and team.
It's time to get close to JIRA. It's easier here, the main thing is to make the project decomposition as thoroughly as possible.
Algorithm like this:
1. we have broken the project into several enlarged tasks according to functional requirements and business logic, based on the terms of reference and the available screen designs;
2. added architecture tasks, common modules, UI components;
3. once again ran through all the tasks and decomposed them into smaller ones, allocating resources for HTML coding and JS coding.
The result was a huge pool of tasks and the launch date of the project. Work has begun to boil.
Internet banking is a complex and large project, and we need to start it with caution, so we decided to launch it in several iterations:
1. testing by our QA department;
2. internal testing, in which all employees of the bank participate;
3. launch of private beta version for a limited circle of people;
4. public launch.
Simultaneously with the launch of the new Internet bank, we decided to leave the old one - for those who do not like everything new or just for users who do not want to drastically change their habits.
Each iteration, of course, did not do without collecting feedback from users, debugging and refinement. At the same time, the developers were refining the new functionality that was planned to be launched.
The launch turned out smooth and painless, and we also gained time to develop a new functionality that we didn’t manage to finish by the first iteration.
The scope of the tasks was very large, and if at the beginning of the project the team had a lot of strength and inspiration with new technologies, then towards the end of the development, the forces were running out, and when they reached the debugging stage with a bunch of bugs found, it became even harder.
The most important thing here is the attitude in the team, its cohesion and interest in the whole project, and still needs optimism from the helmsman, and the whole “crew of the ship”.
What is there to be modest, one of the main merits is the successfully assembled team of professionals, which is ready to work until everything is done perfectly. There was this invaluable sense of responsibility inside the team, when everyone realizes that the overall result depends on his actions and that the team is one big organism that can die completely due to the failure of one organ.
Tinkoff Bank's front-end team are professionals and responsible developers. As a manager, I am very proud of them, without them the project would not have turned out so successful.
One of the developers said a phrase from the famous film "Pirates of the Caribbean", which sunk into the soul of everyone: "Part of the crew, part of the ship." This is true, the team worked by repeating this phrase, and did not lose heart. Even when it was no laughing matter, the work did not stop.
That team spirit allowed to bring the project to completion in such a short time.
So, a huge pool of found bugs appeared at the first iteration, and we had to deal with this somehow. A simple KANBAN was no longer suitable, and the soulless control definitely could not produce results. And here we came up with a small but pleasant life hack.
In a hurry, they threw a sign at Google Docs, collected a pool of important tasks, and started digging. Every day, the developer who corrected most of the bugs was awarded something tasty or useful: it was cakes, pastries, good thermomugs, or simply invigorating coffee. On the first day, of course, it didn’t work very well, but due to the fact that one developer of the team still had strength, he showed by his example that you could unload a bunch of bugs in a day, and received something tasty as a prize for it. The next day, other developers came up, the team got a second wind. Yes, I had to listen a little - all the developers received prizes, and every day there were not one, but even a few, in order to maintain the fighting spirit. It worked, and hence the conclusion - do not be afraid to sacrifice your finances and personal time for the project, because the team and its attitude is much more important than all these little things.
As a result, almost all the bugs were closed in a week - the team coped with the first iteration, and then with the launch of the entire project.
1. The team and its attitude decide everything.
2. We must begin to develop the project in advance, without waiting for the designs and the finished technical task, which in the end may not come.
3. Do not be afraid to experiment.
4. Stand on your point of view and prove it to the authorities and business.
5. Respect your team, believe in it and in the result.
6. Be optimistic: the whole team watches its lead and reacts like it.
Come to Tinkoff Bank - we are very cool and interesting, we are not afraid to experiment and create cool services.
And here they are - heroes and great fellows of Tinkoff Bank, who in the course of the year developed two large and complex projects (fanfare sounds, from all sides there is a roar of applause).
Tinkoff Bank ekubyshin, the head of the web development department, decided to share how the work on this large-scale project was structured and conducted.
Training
Rumors about the upcoming development of a new Internet bank went all over the office already while working on the portal redesign in February 2014. At the beginning of the year it was clear that there would be a very large amount of work, and it would have to be done in a short time, without harming the quality of the product, and as you know, the speed of development is the direct enemy of quality.
')
Therefore, in order not to release a raw product and not process it on weekends and evenings, driving the whole team to the underworld, it was necessary to think up a development plan long before the problem was set, and also to understand what the new Internet bank should be like and how to speed it up. development in technical terms.
Obviously, some of the work is completely independent of the formulation of the problem or the timing of the preparation of designs.
After thinking about the upcoming project, about what can already be started to do, and in passing after seeing the upcoming changes at the prototype level, it became clear that there would be more work than originally thought.
As a result, the picture according to the preliminary preparation was the following:
1. selection of technical lead, which will work out the architecture and lead the entire project;
2. selection of the team and its recruitment;
3. study of the project architecture;
4. choice of technologies, frameworks and tools;
5. build a working prototype without designs.
Team - the key to success
The most important and decisive condition for the successful development and launch of the project is an excellent team that will work on it.
Obviously, in addition to developing a new Internet bank, there are also other projects that need to be maintained and developed, therefore, some of the developers' resources had to be left free.
The management approved the hiring of additional developers, without which the team would not be able to be staffed. The first thing to do was to find a great one. Lead, who will lead all other team members and develop a project framework with which his colleagues will work.
Finding a technical lead, and indeed a technically advanced developer in a bank, is quite difficult, since developers, especially the front-end, have a false prejudice that it is not interesting to work in a bank. Therefore, a beautiful job full of cool keywords such as NodeJS and AngularJS is important for selection, and we still need a lot of perseverance and patience in selecting from a huge number of resumes and searching on the Internet beyond the well-known “resume portal”. Every day, the Tinkoff HR department did a tremendous job of finding developers, fulfilling all the whims of customers.
I will say briefly: it was very difficult to find a technical lead, and it was not without banal luck and the coincidence of the moon phase. And the miracle happened - I managed to interest a fairly strong developer.
Then it went on the knurled, and the team was completed quite quickly: apparently, the period of activity of the applicants and the launch of the new portal design had played. As a result, we managed to assemble a very strong team of professionals to whom we are grateful for the heroic and difficult work.
Architecture and not only
When we found the technical lead, it is time to start working on the architecture and analysis of the technologies and tools that we will use.
The hardest part is to prove to managers who want to release as many tasks as possible as quickly as possible, that one or two developers should be pulled out of the current project support sprint, so that they can start working on some kind of obscure magic called “project architecture”, which is not clear when will run.
We managed to do this step by step, initially pulling out only 50% of each developer, and then already saying alpha-masculine “SO NEED” and pulling out the necessary developers 100% - and then it was already gone.
And what did we do? And about the following.
We spent a week or two on the analysis of various frameworks, their features and capabilities, on all sorts of holivars and games to do-lists. We analyzed our experience of using BackboneJS, EmberJS, estimated about a new project and realized that for many reasons they are not suitable for it. Played with different collectors, reasoned that it was better - BEM or SMACSS, LESS or Stylus and so on. In general, they didn’t deny themselves practically in anything, but at the same time they tried not to go deep, as there was not so much time.
After all searches, we stopped at AngularJS, as it gave a number of advantages:
1. two-way data-bindings;
2. A bunch of ready-made “boxed” solutions: services, caching, dependency injection, routing, quite convenient syntax of directives and filters;
3. a new and interesting framework, under which you can recruit new developers pretty well and quickly;
4. interest of developers to the project on a new framework;
5. fairly quick and easy entry, which was very important to us.
AngularJS did not seem complicated or incomprehensible, and everything that a developer needs for familiarization was on the official website, and then we went by trial and error.
While they were doing all this, the very, very distant prototype of the new Internet bank was already in time.
Then the lead began to develop a platform for a new project.
This part of the work consisted of:
1. study of the architecture of modules: initialization, drawing, configuration;
2. routing and rendering pages;
3. assembly and deployment of the project on test benches;
4. Request service to work with our API with the possibility of caching and validation.
In parallel, we began to try NodeJS + Express + MongoDB to prepare a platform for a secret project.
The result was the following technology stack:
1. AngularJS
2. RequireJS
3. BEM (but only naming, without bemtools)
4. LESS
5. Gulp
For the new IB, it is enough for nginx to give index.html with the build and all the statics, and everything else remains on the shoulders of the browser.
The output was a platform a la AngularJS Bootstrap, on which you can build SPA applications. Who knows, maybe we will post the code on github.
Here are the first designs
When the prototype was already in principle ready, the designs arrived.
What's next? Immediately take to impose and pull on the finished code? Not! Now we had to draw up plans for launching and developing, a Gantt chart (for You-Know-Whom) and to prove that if you make a new Internet bank, it will be completely new, not only in design and functionality, but also technically new.
The banking sector is a very aggressive and fast market, and in the conditions of tough competition everything has to be done rather quickly. And here time plays a decisive role - when and in what form the product will be released to the market.
It was not easy to prove to managers and business customers who want everything to be done quickly and beautifully, the need to completely redesign the architecture and rewrite all the client’s business logic, but we had serious reasons that worked:
1. old and technically imperfect code is difficult to maintain, and support will ultimately be more expensive than new code without errors, flaws and blunders that have arisen because of the rush to develop;
2. a ready-made prototype, which is already working and on which you can build up business logic;
3. trust in the team, which we deserve the hard work.
We decided to develop everything from scratch, and the team as a whole began its work.
Process
To hell with SCRUM, give KANBAN! It is impossible to imagine how you can develop such a large and complex project, the requirements for which are constantly changing during the work, using SCRUM, wasting time on planning and sprints. Here SCRUM will not work - it is good only when the project is already running and there is some kind of road map.
So, we already have a little bit of a working prototype, several designs, technical task and team.
It's time to get close to JIRA. It's easier here, the main thing is to make the project decomposition as thoroughly as possible.
Algorithm like this:
1. we have broken the project into several enlarged tasks according to functional requirements and business logic, based on the terms of reference and the available screen designs;
2. added architecture tasks, common modules, UI components;
3. once again ran through all the tasks and decomposed them into smaller ones, allocating resources for HTML coding and JS coding.
The result was a huge pool of tasks and the launch date of the project. Work has begun to boil.
About launch
Internet banking is a complex and large project, and we need to start it with caution, so we decided to launch it in several iterations:
1. testing by our QA department;
2. internal testing, in which all employees of the bank participate;
3. launch of private beta version for a limited circle of people;
4. public launch.
Simultaneously with the launch of the new Internet bank, we decided to leave the old one - for those who do not like everything new or just for users who do not want to drastically change their habits.
Each iteration, of course, did not do without collecting feedback from users, debugging and refinement. At the same time, the developers were refining the new functionality that was planned to be launched.
The launch turned out smooth and painless, and we also gained time to develop a new functionality that we didn’t manage to finish by the first iteration.
Project crisis
The scope of the tasks was very large, and if at the beginning of the project the team had a lot of strength and inspiration with new technologies, then towards the end of the development, the forces were running out, and when they reached the debugging stage with a bunch of bugs found, it became even harder.
The most important thing here is the attitude in the team, its cohesion and interest in the whole project, and still needs optimism from the helmsman, and the whole “crew of the ship”.
What is there to be modest, one of the main merits is the successfully assembled team of professionals, which is ready to work until everything is done perfectly. There was this invaluable sense of responsibility inside the team, when everyone realizes that the overall result depends on his actions and that the team is one big organism that can die completely due to the failure of one organ.
Tinkoff Bank's front-end team are professionals and responsible developers. As a manager, I am very proud of them, without them the project would not have turned out so successful.
One of the developers said a phrase from the famous film "Pirates of the Caribbean", which sunk into the soul of everyone: "Part of the crew, part of the ship." This is true, the team worked by repeating this phrase, and did not lose heart. Even when it was no laughing matter, the work did not stop.
That team spirit allowed to bring the project to completion in such a short time.
So, a huge pool of found bugs appeared at the first iteration, and we had to deal with this somehow. A simple KANBAN was no longer suitable, and the soulless control definitely could not produce results. And here we came up with a small but pleasant life hack.
In a hurry, they threw a sign at Google Docs, collected a pool of important tasks, and started digging. Every day, the developer who corrected most of the bugs was awarded something tasty or useful: it was cakes, pastries, good thermomugs, or simply invigorating coffee. On the first day, of course, it didn’t work very well, but due to the fact that one developer of the team still had strength, he showed by his example that you could unload a bunch of bugs in a day, and received something tasty as a prize for it. The next day, other developers came up, the team got a second wind. Yes, I had to listen a little - all the developers received prizes, and every day there were not one, but even a few, in order to maintain the fighting spirit. It worked, and hence the conclusion - do not be afraid to sacrifice your finances and personal time for the project, because the team and its attitude is much more important than all these little things.
As a result, almost all the bugs were closed in a week - the team coped with the first iteration, and then with the launch of the entire project.
PS
1. The team and its attitude decide everything.
2. We must begin to develop the project in advance, without waiting for the designs and the finished technical task, which in the end may not come.
3. Do not be afraid to experiment.
4. Stand on your point of view and prove it to the authorities and business.
5. Respect your team, believe in it and in the result.
6. Be optimistic: the whole team watches its lead and reacts like it.
Come to Tinkoff Bank - we are very cool and interesting, we are not afraid to experiment and create cool services.
And here they are - heroes and great fellows of Tinkoff Bank, who in the course of the year developed two large and complex projects (fanfare sounds, from all sides there is a roar of applause).
Source: https://habr.com/ru/post/251103/
All Articles