How do we put the company "pig"

Once again faced with the problem of collecting money, we decided to see what are the ready-made solutions on the market. We carried out an analysis of existing products, revealed their shortcomings and decided to make our product (after all, in IT their “bikes” are always closer).

In this small article I would like to share the experience of gathering a team, interacting with related units within a large company and trying to use ready-made solutions that at first glance fit our needs.

Team gathering:

After the approval of the project at the top and the emergence of the product owner, the question arose "who will do it?". According to the existing procedures, tasks should have been scattered into different groups: front-end, back-end, database. With different queues of tasks, priorities and owners. About each little bit.

Front-end - I needed integration into the site of a small form, and there were no problems at the beginning - they said that there was a resource and everyone would do it in a couple of weeks. But the joy did not last long - apparently, according to the totality of the parade of planets, the full moon and other mystical events (as if we never knew), we were not allowed into the "closed club". The resource was not issued and the task was postponed until later.

Back-end - it was easier here, we were immediately told that there was no resource and would not be in the near future.

The product owner lost the desire to go on and find out "and when will the resource be?", "And maybe select a couple of sprints?". Then she complained to us, in general - aster.

But, after successfully turning up Agile training, where we were energized for success and told that any project can be done by any team, we decided to create a project by the team, which is indirectly related to web development. So began the story of one small, but proud team.

Start:

Having received the go-ahead at the top, try a new format for doing the project, we started.
We collected the backlog, brought the board, discussed the MVP, began to assign roles.

A curious thing came out with the latter, since each participant should have a role that is useful for the team. This, in my opinion, is a plus of this approach, since only the "right" people remain in the team. Managers, for example, have become testers.

We chose weekly sprints, despite the fact that they are usually two weeks in the company. As it turned out, not for nothing - a short sprint had a positive impact on the project, and the team was more often aware of the progress of work, it was easier to take into account and influence changes around the project.

Suddenly, one of the difficulties was to get people to come in time for the morning daily meetings. For what even the tax on tardiness in the form of sweets was introduced, as a result the team gained a little weight :)

Technology:

The product got into the overall concept of products in the company very well, and we wanted to use ready-made solutions and architecture to the maximum. But in the end, the main pain of using ready-made "bicycles" was that it was often a monocycle, it was only going to the right, and how to turn its pedals, a couple of people knew from the force.

Front-end:

In order not to wait for the resource to be introduced into the site, the best option for us was to make our own site for the product.

For the development of the site, a combination of SPA, React JS, Redux was taken as the basis of the architecture.
It was decided to abandon the isomorphic application, in order not to get involved with NodeJS (although it didn’t do without the node), the SPA stood out in this respect favorably.

At first everything went well. The application gained more and more functionality, giving the team confidence. Problems began after pentesting. It turned out that the authorization scheme contained an architectural error. This made us run across several divisions and simultaneously reject a similar scheme in a neighboring project. But the solution was finally found.

The next rake we hit is SEO. Robots do not know how to work with javascript rendering. As a result, there were two options:

• Prerender.io is a third-party service, and it has a certain interval for creating cached pages. We needed to get static in real time.
• Your prerender is bingo !!!, your crutches are always better

To distribute statics to robots, NodeJS was used.

Back-end:

It was required a little from the backend: to accept requests from the front, work with the base, communicate with other services in the QIWI loop. Load laid like the main site. The project came at the wave of active implementation of microservice architecture in the company, which allowed us to reduce development time, since already ready microservices took on a part of the functionality of the environment.

After assessing the requirements and capabilities, the question arose “what to write on?”. Among the applicants were Java, NodeJS, Golang.

• Java is the main development language of the back-end in the company, which was actively advised to us because many of them can do it. However, having studied a single project, we came to the conclusion that many "know how" in their own way. In addition, there are many options for solving one problem over the years of the existence and change of trends in Java.
• Node.js is a trend that is fairly easy to understand and master. After discussing this option, we came to the conclusion that it is very easy to shoot yourself a leg, incidentally damaging something else. JS is JS, with all its pluses and minuses.
• Golang - All the necessary tools are available from the box in Go, including lightweight multi-threading, testing and benchmarks. There is also an impressive list of third-party libraries for all occasions. The claimed support for backward compatibility of Golang versions also looks good. Only channels that could not be used in the code, and the auto-formatting with syntax had to get used to for some time, were embarrassed.

As a result, the choice fell on Golang, which was backfired to us in the future in terms of organization, since administrators did not know how to build and deploy applications, and IB did not have tools for analyzing the code. But, of course, all the problems were solved as a result.

We chose PostgreSQL as the base - it handles the data storage task, and that’s enough for us.

Testing:

The team was not originally a professional tester, so at some point there were a lot of tasks for testing, and it began to strain. In fact, it was a classic situation for beginners in agile - a blockage of tasks in one place that needs to be cleaned before continuing to develop. But we found a way out: scored retreated from Agile and continued to work.

As a result, we did not take the tester to the team, but used the QA team as a service unit, giving the test tasks. Unexpectedly for us, the approach turned out to be successful: the outsourcing guys very quickly and well went through our product, finding a bunch of bugs and adding new stickers to the board. This brought joy and understanding that the project was moving towards production.

How to run:

The pilot launch took place inside the company, which allowed us to collect suggestions, suggestions, bugs, but overall the reviews were positive. Having fixed all critical bugs right in the sale, we sent a little traffic from the main site, having tested it on real users. After that, users were telephoned and a small survey about the product was conducted. We found out that the product is understandable and useful for users. In addition, they threw us some more good ideas in backlog, and we decided to scale up and immediately launch the second phase of the project with modifications that will make the lives of users even easier.

Total:

In the course of the project were both positive and negative points. Having traveled this path with the team, I gained invaluable experience for myself and made some conclusions:

1. Agile turned out to be a very convenient toolkit for launching a product.
2. But for the implementation of agile unit manager must admit to its uselessness.
3. People work in adjacent teams too.
4. But more often you start looking at these people differently, despite the fact that they have been working in the company for a long time.
5. IB is in its context and it is not always clear what should be done and why, so it is better to ask again and clarify once again.
6. Do not be afraid of new things and do something that you never did.
7. SPA, React, Redux - nice and fashionable, but without NodeJS anywhere.
8. Go easy, fast and stable, for non-critical products fits perfectly.
9. Regular stand-ups are a good practice to keep your finger on the pulse.
10. When decisions are discussed and made collectively, each team member feels his contribution.
11. Grooming is not only dog ​​grooming, but also a great way to plan activities.

PS

What does this person write about and what does the "pig" mean? I am about our new product. Meet QIWI Piggy Bank - a service for simple and convenient collective collecting money. You just need to create a thematic piggy bank and share the link with your friends to replenish it. No extra details.