The perfect recipe for the development process

Write Close
Close
Do you have any questions? Contact us!
I agree the Terms of Service
published April 28, 2020

For the fourth month now I've been trying for myself a new role in our company - the role of the project manager. I have a small team working on a hrm system. And in this article, I want to talk a little about the process of work that we have built.

Even though the team is quite small, it is necessary to take the processes as seriously as possible. The normal life cycle of a product is:
  • idea
  • discussion and assessment
  • implementation
  • testing
  • release
Moving away from the standard agile approach, in which each team member performs a specific function: developers - develop, testers - test, managers -
monitor the execution of deadlines and reports, product manager - generates ideas and evaluates the released product, we at Attractor Software resort to merging competencies and organizing cross-functional teams.

What does it mean?

The development team includes all the specialists necessary for the release of the product. In our case, the team has a front-end developer and two full-stack developers who do not specialize in one thing, be it technology or a specific task, they are competent and can deal with both the front and the backend of the application. At the same time, they are testers who independently write and cover the functionality they wrote with tests. Personal interest in the functionality being written and tested in a high-quality manner allows us to significantly increase the work efficiency and the quality of the product we produce.

The first step in the development cycle is the submission of ideas and setting goals. As a rule, the product owner and project manager do this. Usually, ideas come from the owner of the product, and I, as a manager, form and describe product requirements in tickets - explaining what needs to be done and why. It is important that the developers at this stage do not stand aside, but are aware of what is happening and give ideas for the implementation of these tasks. Developers are more deeply devoted to the nuances contained in the project code. They can pre-warn a situation when, due to conflicts of conditions, requirements, or criteria for accepting a task may suddenly change.

To keep developers up to date with current events and future tasks, we call up the whole team daily to discuss current affairs. We also have a general chat, where the owner of the product, from time to time, writes questions for discussion, ideas and describes emerging problems that we need to solve.
We have made the product owner an active member of the team. The owner of the product participates in daily stand-ups, sprint planning, sprint review, and throughout the process, conducts active communication with the team, which allows you to work clearly and smoothly, having a concrete understanding of what the client wants to get on the release. We have gotten priorities thanks to which we began to release exactly the functionality that is needed "here and now" faster. The product owner now always knows what the developers are working on or are planning to work on and can adjust the process based on his current tasks.

This is followed by the evaluation phase, in which developers and the team manager work closely. The purpose of this stage is to discuss solutions for each task and evaluate them in a temporary equivalent. We have already described this process in more detail in this article.

When tasks are set, tickets are described, and there are specific requirements for implementation, the development phase begins. The main task at this stage lies with the developers. In my case, these are three developers - a front-end worker and a full-stack developer, as well as a team lead, which we use for code review and verification of pool requests. Each of them takes on one of the tickets described by me and appreciated by them in the watch and starts working on it, deploying and viewing the result in its local environment.

After writing new functionality, it is necessary to cover it with tests. Tests are the next stage of development. The developers in our team automatically write tests that check the performance of the code they wrote, identify errors, and inconsistencies in the code. When the developer passes all the tests, he draws up a pool request and sends it to the team leader for verification. Since the team leader has another project in which he is engaged on an ongoing basis, once a day, he checks all the accumulated requests, gives comments on them, writes where the errors occurred, and gives the go-ahead for the delivery of this functionality, after correction by his comments.

He final stage is the integration of the new version (deploy). For this, we use Jenkins and the CI | CD method. If you paint it in stages, then the deployment in our case looks like this:
CI:
  • The repository receives new code written by developers
  • Jenkins takes it to himself
  • Collects all the dependencies and stuff for tests
  • Testing application
CD:
  • If the tests pass, then Jenkins starts collecting docker images to exit into the test environment or the developer environment.
  • Fluffs collected pictures in the registry
  • Connects to a production server via docker-machine
  • Pulls new images with registry
Based on them, it launches new containers on production, having previously stopped and deleted the old ones.
Schematically, it looks like this:
As a rule, a sufficient number of changes are accumulated in a week, which is then delivered to the staging server for further functional testing. Usually, it is conducted by the manager and owner of the product. As a manager, I open every ticket currently closed from this sprint and check the new functionality according to all the conditions described in the ticket. The product owner usually tests the update without tickets, arbitrary scripts, and its benefits. There are cases that right here and now the product owner involuntarily implements a scenario not described earlier, which reveals new requirements for the product. Then he writes about it in a chat where the whole team is located and depending on the seriousness of his question, and we proceed to discuss and get this idea into work.

In this mode, our team works throughout the sprint - 10 working days. At the end of the sprint, we all conduct a sprint review, evaluate tickets for a new sprint, and repeat the cycle.

By agreement with customers, we will complete 1-2 sprints; we have a "holiday deployment." This is the process during which we deliver new functionality and fixes to the production version of the product, and they fall into the hands of the end-user of the application.

We have increased the responsibility of the team for the "profitability" of the product. And the conversation here is not only about monetary profit, but also about the convenience of the product for the end-user. The team is interested in their product getting accustomed and bringing real business benefits. Thus, the business and the team have become a single whole, working to ensure that everyone is happy.

So, summing up, we can say how good this process is:
There is no bus factor. We got rid of the problem of the replaceability of team members and the long entry into the project of new developers.
The professional competence of developers has increased. We grow our T-shape specialists.
The correspondence between expectations and reality that the product owner receives in the final of each sprint has increased.
No stop factors. Open communication between all team members led to the fact that everyone's vote is taken into account, developers can talk with the owner of the product and offer him more suitable options for implementing certain wishes. There is more informal communication, which entails a more cohesive, friendly atmosphere in the team.
Of the minuses at first glance, it can be noted that developers are often disturbed and distracted by various activities and communications. To minimize discomfort, we agreed on the rules of work that are convenient for everyone and worked out a "charter." It contains all the agreements on the time of stand-ups on the rules of interaction held during the sprint of events, dates, and hours of communication.

We can build a reliable, effective, and interesting process of working on your product! Contact us!
Did you like this article?
Share article on social networks
Worked on the article:
Maria Ilchenko
PR and Event Manager
Made on
Tilda