The perfect recipe for the development process
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 a new role in our company - the project manager's part. I have a small team working on a hrm system. And in this article, I want to talk a little about the work process that we have built.
For the fourth month now, I've been trying a new role in our company - the project manager's part. I have a small team working on a hrm system. And in this article, I want to talk a little about the work process that we have built.
Even though the team is relatively small, it is necessary to take the processes as seriously as possible. The average life cycle of a product is:
- idea
- discussion and assessment
- implementation
- testing
- release
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. Simultaneously, 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 product owner, and I, as a manager, form and describe product requirements in tickets - explaining what needs to be done and why. It is essential that the developers do not stand aside but are aware of what is happening and give ideas for implementing these tasks. Developers are more deeply devoted to the nuances contained in the project code. They can pre-warn a situation when 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 product owner, from time to time, writes questions for discussion, ideas and describes emerging problems that we need to solve.
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. Simultaneously, 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 product owner, and I, as a manager, form and describe product requirements in tickets - explaining what needs to be done and why. It is essential that the developers do not stand aside but are aware of what is happening and give ideas for implementing these tasks. Developers are more deeply devoted to the nuances contained in the project code. They can pre-warn a situation when 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 product owner, 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. Throughout the process, the product owner conducts active communication with the team, which allows us 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 precisely the functionality needed "here and now" faster. The product owner now always knows what the developers are working on or plans 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. This stage aims 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 developer, a full-stack developer, and a team lead, who helps us with the code review and verification of pool requests. Each of them works on one of the tickets described by me, follows the time estimations made by them, deploys, and views the result in the local environment.
After writing new functionality, it is necessary to cover it with tests. Tests are the next stage of development. Our team's developers write automated unit tests that check the code's performance, identify errors, and inconsistencies in the code. When the developer completes 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 approves the delivery of this functionality, after code correction by his remarks.
The 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:
This is followed by the evaluation phase, in which developers and the team manager work closely. This stage aims 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 developer, a full-stack developer, and a team lead, who helps us with the code review and verification of pool requests. Each of them works on one of the tickets described by me, follows the time estimations made by them, deploys, and views the result in the local environment.
After writing new functionality, it is necessary to cover it with tests. Tests are the next stage of development. Our team's developers write automated unit tests that check the code's performance, identify errors, and inconsistencies in the code. When the developer completes 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 approves the delivery of this functionality, after code correction by his remarks.
The 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.
- Collects all the dependencies and stuff for tests
- Tests the application
CD:
- If the tests pass, Jenkins starts collecting docker images for passing to the test environment or the developer environment.
- Stores the collected pictures in the registry.
- Connects to a production server via docker-machine
- Pulls new images with registry
As a rule, all the changes are accumulated in a week and 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 completed ticket 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. He then writes about it in a chat where the whole team is located, and, depending on the seriousness of his question, 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.
After completing 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. We refer to the monetary profit and the convenience of the product for the end-user. The team is interested in creating a product that can bring real business benefits. Thus, the business and the team work as one unit to ensure that everyone is happy.
So, summing up, we can say how good this process is:
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.
After completing 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. We refer to the monetary profit and the convenience of the product for the end-user. The team is interested in creating a product that can bring real business benefits. Thus, the business and the team work as one unit to ensure that everyone is happy.
So, summing up, we can say how good this process is:
There is no bus factor.
The professional competence of developers has increased. We grow our T-shape specialists.
The correspondence between expectations and reality that the product owner receives at 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 product owner and offer him more suitable options for implementing specific wishes. There is more informal communication, which entails a more cohesive, friendly atmosphere in the team.
The only downside is that developers are often disturbed and distracted by various activities and communications. To minimize discomfort, we agreed on the rules of work convenient for everyone and worked out a "charter." It contains all the agreements on the time of stand-ups, the rules of interaction held during the sprint of events, dates, and communication hours.
We can build a reliable, effective, and exciting process working on your product! Contact us!
We can build a reliable, effective, and exciting process 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
