Hi there! I'm Alex Omelyanenko, and I lead the Flutter team at Imaga. In this article, I'll share our journey of implementing a component-based development approach for one of our projects and the advantages it brought. This article will outline the main benefits and drawbacks of our solution, while going into practical aspects, including team structure, responsibilities, and documentation procedures.
Methodology Overview
Component-based development involves breaking down the mobile application into distinct components or features. Each element is designated to a developer (known as the Feature Owner). The Feature Owner allocates time to component tasks and technical documentation, such as the roadmap. Additionally, they oversee the work of other developers assigned to the feature.
Essentially, the Feature Owner serves as the team lead within their feature. As a result, they have in-depth knowledge of component development intricacies. Additionally, thorough component documentation lets other developers familiarize themselves with the feature later.
Why did we decide to transition to a new methodology? There were two reasons:
- The project's team lead had limited time and needed some relief.
- The project, which could confidently be called a super-app, was sizable. Typically, it took new developers 3–4 weeks to fully understand the work. We needed to speed up this process.
Next, I'll explain our workflow.
What to consider as a component
When discussing a "component," we usually refer to each significant feature.
If a project begins with pre-existing elements, we don't typically include authentication, networking, or navigation as components. However, if a project starts from scratch without pre-implementing basic functionality, these tasks should be treated as separate components.
Advantages of this methodology
- Team leaders spend less time on the project since they don't need to tackle high-level tasks like reviewing every feature's code or assigning blame.
- All team members know how each component works because everyone has access to the roadmap, specifications, and video presentations, which I'll detail later.
- Getting up to speed on the project and understanding the components takes less time, accelerating development.
Roles and responsibilities in the team
| Teamlead | Feature Owner | Developer | Заголовок 4 | Заголовок 7 | ||||
|---|---|---|---|---|---|---|---|---|
| Assigns feature owners. Approve roadmaps crafted by owners. Conducts code reviews for the component when it’s ready or when merging the component branch into the dev or release branch. Manages Git workflow. |
Develops Component Roadmap. Updates Roadmap as needed. Updates documentation with input from analysts. Develops and executes tasks related to the component. Refines and resolves bugs identified during testing. Assigns tasks among developers. Conducts code reviews for tasks completed by other component developers. Compiles builds for testing. Presents the component. |
Develops and Executes Tasks. Refines and fixes bugs identified during testing |
Нужен блок | Нужен блок с табличкой для статей на вихре | Нужен блок | Нужен блок | Нужен блок с табличкой для статей на вихре | Нужен блок |
Feature owner's role in life cycles
The development lifecycle unfolds as follows:
- Breaking down the application into components.
- Creating an Epic for each component.
- Assigning a Feature Owner to each component.
- Establishing a task pool for each component.
Here's how the component lifecycle looks:
- A component branch is created and named according to the convention "components/component-name/task-number-component-component-name" or "components/auth/MPB2B-123-component-auth."
- Tasks related to the component are added to the backlog.
- The Feature Owner develops the component's Roadmap, coordinates it with the team lead, and adds it to the Epic. Coordination with the team lead ensures consistency in component structures and prevents reuse.
- All tasks must be executed according to their lifecycle (see the following list).
- After completing all tasks, the Feature Owner submits the component branch for code review to the team lead.
- After code review, the team lead merges the branch into the release branch.
- Additionally, after code review, the Feature Owner builds the release branch and hands it over for testing.
- If testing reveals defects, the Feature Owner addresses the bugs.
- The Feature Owner creates merge requests 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 a link is included in the Epic.
Here's what the task lifecycle looks like:
- The project manager or team lead selects tasks from the backlog and adds them to the board.
- The Feature Owner creates a branch from the component branch, named according to the convention "components/component-name/tracker-task-number" or "components/auth/MPB2B-123".
- The Feature Owner begins working on the task. If there are many tasks, they distribute them among themselves and available developers.
- If a developer is working with the component for the first time, they first open an Epic and familiarize themselves with the Roadmap and the specifications.
- If the task was worked on by the Feature Owner, once completed, it's merged into the component branch. If another developer works on it, the Feature Owner reviews the code.
- Tasks marked as "Waiting for test" are assigned to a tester for evaluation in the task tracker.
Component documentation
1- The component Epic gathers links to all documentation related to the component. It's the first thing a new developer will see. Here's what they'll find there:
- Description drafted by the analyst.
- Name and contact information of the Feature Owner.
- Link to documentation approved by the analyst.
- Link to the Roadmap and technical description of the component.
- Link to the video presentation of the finished component.
2- The Roadmap is a technical breakdown of the component's layers, showcasing the hierarchy of files and folders involved in its operation, their interactions, and a brief description of their functions.
The purpose of the Roadmap is to enable an external developer to understand which files they will need to work with upon receiving a task related to the component, significantly reducing the time required to become familiar with the task.
3- The video presentation is essential for ensuring all team members understand how the component functions, the value it brings, and where its scenarios begin and end. These insights are crucial for grasping the overall context of the entire application.
Closing thoughts
Finally, I'll share how this approach was performed. But let me emphasize right away that we were satisfied with the results.
1- This methodology suits large teams comprising at least six developers. It's ideal if some team members are interns or junior developers. In this case, mid-level developers are suitable for the role of Feature Owners, and interns or juniors can be added to their teams.
2- Our contentious issue was recording a video after implementing a feature. While initially stuck to the plan, we abandoned this practice for subsequent projects.
And, of course, let's see if all our expectations were met.
- The team lead indeed began spending less time on the project and focused solely on critical tasks, allowing more time to be allocated to other projects.
- The project documentation proved helpful right from the start. On average, a new developer spends 20% less time researching and communicating with other developers to understand how the feature works.
- As a result, we ended up with a fully documented project. Even if we return to it in a few years, we'll quickly recall how it's implemented, avoiding spending too much time on familiarization. And if another team starts working with it, it will be a manageable task for them.