Experience in implementing component development
Hello! My name is Alexander Omelyanenko, I work as a team lead for the Flutter team at AGIMA. I’ll tell you how and why we introduced a component approach to development on one of our projects and what results it gave us. In the article I will show the main pros and cons of our solution. I’ll also touch on practical issues: what positions we divided the team members into, what responsibilities they were assigned, and how we documented the work.
Description of methodology
Component development involves dividing a mobile application into separate components (features). A specific developer, the Feature Owner, is responsible for each of them. He devotes part of his time to component tasks, and part to technical documentation (Roadmap). The feature owner also controls the work of other developers assigned to the feature.
Essentially, a Feature owner is a team lead within his feature. Therefore, he knows the smallest nuances of component development. Plus the component itself is well documented. And this subsequently allows other developers to quickly understand the feature.
Why did we decide to switch to a new methodology? There were two reasons:
The team lead had little time on the project; he needed to be relieved of his workload.
The project can easily be called a superapp, it’s big. And it usually took 3-4 weeks for a new developer to fully enter the work. We needed to speed up this process.
Next I will explain how we worked.
What is considered a component?
By component, as a rule, we mean each major feature.
If the project starts out of the box, authorization, networking and navigation should not be included as components. And if the project starts from scratch and the basic logic is not included “in the box,” then these tasks need to be created as separate components.
Advantages of the methodology
The team lead spends less time on the project because he does not have to solve high-level problems (code review of each feature, search for those responsible, etc.).
All team members know how each component works, so everyone has access to the Roadmap, technical specifications and video presentations. I'll talk about this below.
Familiarization with the design and operation of components takes less time, which speeds up development.
Team roles and responsibilities
The role of the Feature Owner in life cycles
What does it look like development life cycle:
The application is broken down into components.
An Epic is created for each component.
For each component, a Feature owner is assigned.
A task pool is created for each component.
What does it look like component life cycle:
A component branch is created for the component. For example, “components/component-name/task-number-component-component-name” or “components/auth/MPB2B-123-component-auth”.
The tasks associated with the component are added to the backlog.
The Feature Owner develops the Roadmap of the component, coordinates it with the team lead and adds it to Epic. It must be coordinated with the team lead so that all components have a similar structure and there is no reuse.
All tasks must be completed according to their life cycle (see the following list).
After completing all tasks, the Feature owner passes the component branch to the code review team lead.
After the code review, the team lead merges the branch into the release branch.
Also, after the code review, the Feature Owner assembles the release branch and submits the assembly for testing.
If testing reveals defects, the Feature owner fixes the bugs.
The feature owner makes MR with fixes for defects directly into the release branch.
The Feature Owner presents the component to all team members. The presentation is recorded on video.
The Feature Owner updates the Roadmap.
The video presentation is added to the documentation and the link is added to Epic.
What does it look like task life cycle:
The project manager or team lead takes tasks from the backlog and adds them to the board.
The feature owner creates a branch from the feature branch. For example, “components/component-name/task-number-in-tracker” or “components/auth/MPB2B-123”.
The Feature Owner starts performing the task. If there are a lot of tasks, it distributes them among itself and free developers.
If a developer is working with a component for the first time, the first thing he does is open Epic and get acquainted with the Roadmap and technical specifications.
If a Feature owner worked on a task, when ready, it is merged into the component branch. If it was performed by another developer, it goes to the Feature Owner for code review.
In the task tracker, a task with the status Waiting for test is transferred to the tester.
Component documentation
1. Epic component collects links to all documentation associated with the component. This is the first thing a new developer will see. This is what he will find there:
Description compiled by the analyst.
Feature owner's name and contacts.
Link to documentation agreed upon with the analyst.
Link to Roadmap, technical description of the component.
Link to video presentation of the finished component.
2. Roadmap is a technical description of the layers of a component, where you can see the hierarchy of files and folders involved in the operation of the component, their interaction and a brief description of their work.
The purpose of the Roadmap is for a third-party developer, having received a task for a component, to understand from the Roadmap which files he will have to work in. This significantly reduces the time required to familiarize yourself with the task.
3. Video presentation It is necessary that all team members know how the component works, what payload it carries, where the component script begins and where it ends. This knowledge is needed to understand the overall context of the entire application.
Conclusion
And finally, I’ll tell you how this approach worked. But let me immediately note that we were satisfied.
The methodology is suitable for large teams – from 6 developers. Ideally, if part of the team is interns or junior developers. In this case, middles are suitable for the position of Feature-owners, and trainees or juniors can be added to their teams.
A controversial point for us was recording the video after the feature was implemented. We stuck to the original plan, but decided to abandon it on subsequent projects.
And of course, let's see if all our expectations came true.
The team lead actually began to spend less time on the project and performed only key tasks, which allowed him to devote more time to other projects.
The project documentation has proven useful already in this project. On average, a new developer spent 20% less time researching and communicating with other developers to understand how the feature works.
The end result was a fully documented project. Even if we return to it in a couple of years, we will quickly remember how it is implemented and will not spend much time familiarizing ourselves with it. And if another team starts working with him, it won’t be a dark forest for them.
If you have any questions, ask them in the comments – I’ll try to answer. Also tell us about your experience working with the component approach. We also have telegram channel for Flutter developers — there my colleague Sasha Vorozhishchev shares the latest mobile development news every day.
