Part of the team, part of the ship
The processing of Internet banking has been brewing for a long time, not only in the bright minds of managers and vice presidents, but also in the inquisitive minds of developers.
Ekubyshin, Head of Tinkoff Bank Web Intervention Development Department, decided to share how this large-scale project was built and worked.
Rumors about the upcoming development of a new Internet bank went around the office while working on a portal redesign in February 2014. At the beginning of the year, it was clear that a very large amount of work had to be done, and it would need to be done in a short time, while not harming the quality of the product, and as you know, development speed is a direct enemy of quality.
Therefore, in order not to produce a raw product and not to process it on weekends and evenings, driving the whole team to hell, it was necessary to think out a development plan long before the task was formulated, and also to understand what approximately a new Internet bank should be and how to speed it up development in technical terms.
Obviously, part of the work is completely independent of the statement of the problem or the timing of the preparation of designs.
After thinking about the upcoming project, what we can already start to do, and having casually seen the upcoming changes at the prototype level, it became clear that there would be more work than originally seemed.
As a result, the picture of the pre-
training was as follows: 1. selection of technical lead, which will work on the architecture and lead the entire project;
2. selection of the team and its staffing;
3. study of the architecture of the project;
4. the choice of technologies, frameworks and tools;
5. building a working prototype without designs.
The most important and decisive condition for the successful development and launch of a project is an excellent team that will work on it.
Obviously, in addition to developing a new Internet banking, there are other projects that need to be supported and developed, so some of the developer’s resources had to be left free.
The management approved the hiring of additional developers, without which the team could not be understaffed. The first thing to do was to find a great tech. a lead that will lead all the other members of the team and develop the framework of the project with which its colleagues will work.
Finding a technical lead, and indeed a technically advanced developer in the bank is quite difficult, since developers, especially the front-end, have a false prejudice that it is not interesting to work in the bank. Therefore, a beautiful vacancy, saturated with cool keywords such as NodeJS and AngularJS, is important for selection, and you also need a lot of perseverance and patience in selecting from a huge number of resumes and searching on the Internet outside the well-known “resume portal”. Every day, the Tinkoff HR department did a great 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 could not do without banal luck and coincidence of the phase of the moon. And a miracle happened - I managed to interest a rather strong developer.
Then things went smoothly, and understaffed the team fairly quickly: apparently, the period of activity of the applicants and the launch of a new portal design 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 was time to begin to study the architecture and analyze the technologies and tools that we will use.
The most difficult thing is to prove to managers who want to release as many tasks as possible as quickly as possible, that they need to get one or two developers out of the sprint to support current projects, so that they begin to work on some obscure magic called “project architecture”, which is not clear when will be launched.
It was possible to do this in stages, at first pulling out only 50% of each developer, and then saying alpha-male “SO NECESSARY” and pulling out the necessary developers 100% - and then things went.
And what did we do? And about the following.
Spent a week or two on the analysis of various frameworks, their features and capabilities, on all sorts of holivars and games in to do-lists. We analyzed our experience in using BackboneJS, EmberJS, figured out about a new project and realized that for many reasons they were not suitable for it. Played with different collectors, reasoned that it is better - BEM or SMACSS, LESS or Stylus and so on. In general, they did not deny themselves practically nothing, but at the same time they tried not to go deep, since there was not so much time.
After all the searches, we stopped at AngularJS, as it provided a number of advantages:
1. two-way data-bindings;
2. a bunch of ready-made in a “boxed” solution: services, caching, dependency injection, routing, pretty convenient syntax for directives and filters;
3. A new and interesting framework for which you can recruit new developers pretty well and quickly;
4. interest of developers in the project on the new framework;
5. fairly quick and easy entry, which was very important to us.
AngularJS did not seem complicated or incomprehensible, and all that the developer needed to familiarize himself with was on the official website, and then we went on by trial and error.
While we were doing all this, the very, very distant prototype of the new Internet banking arrived in time.
Next, the leader began to develop a platform for a new project.
This part of the work consisted of:
1. elaboration of the architecture of the modules: initialization, rendering, configuration;
2. routing and rendering of pages;
3. assembly and deployment of the project to test stands;
4. Request service to work with our API with the ability to cache and validate.
At the same time, they started trying NodeJS + Express + MongoDB to prepare the secret project platform.
As a result, we got the following technology stack:
1. AngularJS
2. RequireJS
3. BEM (but only naming, without bemtools)
4. LESS
5. Gulp
For a new IB, it is enough for nginx to give index.html with the assembly and all the statics, and everything else remained 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 ready, in principle, the designs arrived.
What's next? To immediately make up and pull on the finished code? Not! Now it was necessary to draw up plans for launch and development, a gantt chart (for You-Know-Who) and prove that if you make a new Internet bank, then 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 fierce competition everything needs to be done fairly quickly. And here the decisive role is played by time - when and in what form the product will be released to the market.
To prove to managers and business customers who want everything to be done quickly and beautifully, the need to completely redo the architecture and rewrite the entire business logic of the client, was rather difficult, but we had serious arguments that worked:
1. old and technically imperfect the code is difficult to maintain, and support in the end will be more expensive than the new code without errors, flaws and mistakes that arose due to the rush during development;
2. a ready-made prototype that is already working and on which you can build up business logic;
3. trust in the team, which we deserve hard work.
We decided to develop everything from scratch, and the team as a whole began to work.
To hell with SCRUM, give KANBAN! It is impossible to imagine how it is possible to develop such a large and complex project, the requirements for which are constantly changing during the work, using SCRUM, spending 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 working prototype, several designs, terms of reference and a team.
It's time to get to JIRA. It’s easier here, the main thing is to make the decomposition of the project as thorough as possible.
The algorithm is approximately the following:
1. we divided the project into several enlarged tasks according to functional requirements and business logic, based on the terms of reference and available screen designs;
2. Added tasks on architecture, general modules, UI-components;
3. ran through all the tasks again and decomposed them into smaller ones, allocating resources for HTML coding and JS coding.
The result was a huge task pool and project launch date. The work began to boil.
Internet banking is a complex and large project, and it is necessary to launch it with caution, so we decided to launch it in several iterations:
1. testing by our QA department;
2. internal testing, in which all bank employees participate;
3. launch of a private beta version for a limited circle of people;
4. public launch.
Along with the launch of the new Internet banking, we decided to leave the old one - for those who do not like everything new or just for users who do not want to dramatically change habits.
Each iteration, of course, could not do without collecting feedback from users, debugging and refinement. Along with this, developers were developing new functionality that was planned to be launched.
The launch turned out to be smooth and painless, and we also bought time to develop a new functionality that we did not manage to finish by the first iteration.
The volume of tasks was very large, and if at the beginning of the work on 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 more difficult.
The most important thing here is the mood in the team, its cohesion and interest in the whole project, and we also need optimism from the helmsman, and indeed from the whole “crew of the ship”.
Why be shy, one of the main merits is a well-assembled team of professionals who are ready to work until everything is done perfectly. Inside the team was this invaluable sense of responsibility, when everyone understands that the overall result depends on his actions and that the team is one large organism, which, due to the failure of one organ, can die completely.
Tinkoff Bank's front-end team consists of professionals and responsible developers. As a leader, 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 everyone's soul: "Part of the team, part of the ship." This is true, the team worked repeating this phrase and did not lose heart. Even when it was not at all laughable, the work did not stop.
It was team spirit that allowed to bring the project to completion in such a short time.
So, there was a huge pool of bugs found at the first iteration, and we had to deal with this somehow. A simple KANBAN was no longer suitable, and soulless control certainly could not give a result. And here we came up with a small but pleasant life hack.
They whipped up a tablet in Google Docs, gathered a pool of tasks distributed by importance and started raking. Every day, the developer who fixed the most bugs was rewarded with something tasty or healthy: they were cakes, pastries, good thermo mugs or just invigorating coffee. On the first day, of course, this didn’t work much, but thanks to the fact that one developer of the team still had strength, he showed by his example that he could clear a bunch of bugs in a day, and got something tasty for it as a prize. The next day, other developers pulled themselves up, the team got a second wind. Yes, I had to cheat a little - all the developers received prizes, and every day there were not one, but even several, in order to maintain the fighting spirit. It worked
As a result, over the week almost all the bugs were closed - the team coped with the first iteration, and then with the launch of the entire project.
1. The team and its mood decide everything.
2. It is necessary to start developing 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 one’s point of view and prove it to the authorities and business.
5. Respect your team, believe in it and the result.
6. Be optimistic: the whole team follows its leader and reacts like it does.
Come to Tinkoff Bank - it’s very cool and interesting here, we are not afraid to experiment and create cool services.
And here they are - the heroes and great fellows of Tinkoff Bank, who developed two large and complex projects over the course of a year (Fanfare sounds, a rumble of applause is heard from all sides).
Ekubyshin, Head of Tinkoff Bank Web Intervention Development Department, decided to share how this large-scale project was built and worked.
Training
Rumors about the upcoming development of a new Internet bank went around the office while working on a portal redesign in February 2014. At the beginning of the year, it was clear that a very large amount of work had to be done, and it would need to be done in a short time, while not harming the quality of the product, and as you know, development speed is a direct enemy of quality.
Therefore, in order not to produce a raw product and not to process it on weekends and evenings, driving the whole team to hell, it was necessary to think out a development plan long before the task was formulated, and also to understand what approximately a new Internet bank should be and how to speed it up development in technical terms.
Obviously, part of the work is completely independent of the statement of the problem or the timing of the preparation of designs.
After thinking about the upcoming project, what we can already start to do, and having casually seen the upcoming changes at the prototype level, it became clear that there would be more work than originally seemed.
As a result, the picture of the pre-
training was as follows: 1. selection of technical lead, which will work on the architecture and lead the entire project;
2. selection of the team and its staffing;
3. study of the architecture of the project;
4. the choice of technologies, frameworks and tools;
5. building a working prototype without designs.
Team is the key to success
The most important and decisive condition for the successful development and launch of a project is an excellent team that will work on it.
Obviously, in addition to developing a new Internet banking, there are other projects that need to be supported and developed, so some of the developer’s resources had to be left free.
The management approved the hiring of additional developers, without which the team could not be understaffed. The first thing to do was to find a great tech. a lead that will lead all the other members of the team and develop the framework of the project with which its colleagues will work.
Finding a technical lead, and indeed a technically advanced developer in the bank is quite difficult, since developers, especially the front-end, have a false prejudice that it is not interesting to work in the bank. Therefore, a beautiful vacancy, saturated with cool keywords such as NodeJS and AngularJS, is important for selection, and you also need a lot of perseverance and patience in selecting from a huge number of resumes and searching on the Internet outside the well-known “resume portal”. Every day, the Tinkoff HR department did a great 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 could not do without banal luck and coincidence of the phase of the moon. And a miracle happened - I managed to interest a rather strong developer.
Then things went smoothly, and understaffed the team fairly quickly: apparently, the period of activity of the applicants and the launch of a new portal design 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 more
When we found the technical lead, it was time to begin to study the architecture and analyze the technologies and tools that we will use.
The most difficult thing is to prove to managers who want to release as many tasks as possible as quickly as possible, that they need to get one or two developers out of the sprint to support current projects, so that they begin to work on some obscure magic called “project architecture”, which is not clear when will be launched.
It was possible to do this in stages, at first pulling out only 50% of each developer, and then saying alpha-male “SO NECESSARY” and pulling out the necessary developers 100% - and then things went.
And what did we do? And about the following.
Spent a week or two on the analysis of various frameworks, their features and capabilities, on all sorts of holivars and games in to do-lists. We analyzed our experience in using BackboneJS, EmberJS, figured out about a new project and realized that for many reasons they were not suitable for it. Played with different collectors, reasoned that it is better - BEM or SMACSS, LESS or Stylus and so on. In general, they did not deny themselves practically nothing, but at the same time they tried not to go deep, since there was not so much time.
After all the searches, we stopped at AngularJS, as it provided a number of advantages:
1. two-way data-bindings;
2. a bunch of ready-made in a “boxed” solution: services, caching, dependency injection, routing, pretty convenient syntax for directives and filters;
3. A new and interesting framework for which you can recruit new developers pretty well and quickly;
4. interest of developers in the project on the new framework;
5. fairly quick and easy entry, which was very important to us.
AngularJS did not seem complicated or incomprehensible, and all that the developer needed to familiarize himself with was on the official website, and then we went on by trial and error.
While we were doing all this, the very, very distant prototype of the new Internet banking arrived in time.
Next, the leader began to develop a platform for a new project.
This part of the work consisted of:
1. elaboration of the architecture of the modules: initialization, rendering, configuration;
2. routing and rendering of pages;
3. assembly and deployment of the project to test stands;
4. Request service to work with our API with the ability to cache and validate.
At the same time, they started trying NodeJS + Express + MongoDB to prepare the secret project platform.
As a result, we got the following technology stack:
1. AngularJS
2. RequireJS
3. BEM (but only naming, without bemtools)
4. LESS
5. Gulp
For a new IB, it is enough for nginx to give index.html with the assembly and all the statics, and everything else remained 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.
And here are the first designs
When the prototype was already ready, in principle, the designs arrived.
What's next? To immediately make up and pull on the finished code? Not! Now it was necessary to draw up plans for launch and development, a gantt chart (for You-Know-Who) and prove that if you make a new Internet bank, then 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 fierce competition everything needs to be done fairly quickly. And here the decisive role is played by time - when and in what form the product will be released to the market.
To prove to managers and business customers who want everything to be done quickly and beautifully, the need to completely redo the architecture and rewrite the entire business logic of the client, was rather difficult, but we had serious arguments that worked:
1. old and technically imperfect the code is difficult to maintain, and support in the end will be more expensive than the new code without errors, flaws and mistakes that arose due to the rush during development;
2. a ready-made prototype that is already working and on which you can build up business logic;
3. trust in the team, which we deserve hard work.
We decided to develop everything from scratch, and the team as a whole began to work.
Process
To hell with SCRUM, give KANBAN! It is impossible to imagine how it is possible to develop such a large and complex project, the requirements for which are constantly changing during the work, using SCRUM, spending 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 working prototype, several designs, terms of reference and a team.
It's time to get to JIRA. It’s easier here, the main thing is to make the decomposition of the project as thorough as possible.
The algorithm is approximately the following:
1. we divided the project into several enlarged tasks according to functional requirements and business logic, based on the terms of reference and available screen designs;
2. Added tasks on architecture, general modules, UI-components;
3. ran through all the tasks again and decomposed them into smaller ones, allocating resources for HTML coding and JS coding.
The result was a huge task pool and project launch date. The work began to boil.
About launch
Internet banking is a complex and large project, and it is necessary to launch it with caution, so we decided to launch it in several iterations:
1. testing by our QA department;
2. internal testing, in which all bank employees participate;
3. launch of a private beta version for a limited circle of people;
4. public launch.
Along with the launch of the new Internet banking, we decided to leave the old one - for those who do not like everything new or just for users who do not want to dramatically change habits.
Each iteration, of course, could not do without collecting feedback from users, debugging and refinement. Along with this, developers were developing new functionality that was planned to be launched.
The launch turned out to be smooth and painless, and we also bought time to develop a new functionality that we did not manage to finish by the first iteration.
Project crisis
The volume of tasks was very large, and if at the beginning of the work on 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 more difficult.
The most important thing here is the mood in the team, its cohesion and interest in the whole project, and we also need optimism from the helmsman, and indeed from the whole “crew of the ship”.
Why be shy, one of the main merits is a well-assembled team of professionals who are ready to work until everything is done perfectly. Inside the team was this invaluable sense of responsibility, when everyone understands that the overall result depends on his actions and that the team is one large organism, which, due to the failure of one organ, can die completely.
Tinkoff Bank's front-end team consists of professionals and responsible developers. As a leader, 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 everyone's soul: "Part of the team, part of the ship." This is true, the team worked repeating this phrase and did not lose heart. Even when it was not at all laughable, the work did not stop.
It was team spirit that allowed to bring the project to completion in such a short time.
So, there was a huge pool of bugs found at the first iteration, and we had to deal with this somehow. A simple KANBAN was no longer suitable, and soulless control certainly could not give a result. And here we came up with a small but pleasant life hack.
They whipped up a tablet in Google Docs, gathered a pool of tasks distributed by importance and started raking. Every day, the developer who fixed the most bugs was rewarded with something tasty or healthy: they were cakes, pastries, good thermo mugs or just invigorating coffee. On the first day, of course, this didn’t work much, but thanks to the fact that one developer of the team still had strength, he showed by his example that he could clear a bunch of bugs in a day, and got something tasty for it as a prize. The next day, other developers pulled themselves up, the team got a second wind. Yes, I had to cheat a little - all the developers received prizes, and every day there were not one, but even several, in order to maintain the fighting spirit. It worked
As a result, over the week almost all the bugs were closed - the team coped with the first iteration, and then with the launch of the entire project.
PS
1. The team and its mood decide everything.
2. It is necessary to start developing 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 one’s point of view and prove it to the authorities and business.
5. Respect your team, believe in it and the result.
6. Be optimistic: the whole team follows its leader and reacts like it does.
Come to Tinkoff Bank - it’s very cool and interesting here, we are not afraid to experiment and create cool services.
And here they are - the heroes and great fellows of Tinkoff Bank, who developed two large and complex projects over the course of a year (Fanfare sounds, a rumble of applause is heard from all sides).