Working on SoftEng project as a Team
===

###### tags: `Guides`

:::info
:warning: This article only represent me, an indie software engineer who likes to explore new things. Read it with a grain of salt!
:::

Having taken the baby step--that is developing your side project apps by ourselves--, the next step for us software engineers is to learn how to work as team in software engineering project. As project get bigger and complex and as stakeholders are increasing, you'll inevitably need help to develop the project and have to work as a team with others.

Therefore, to ensure each member can adapt with the team members and to be able to follow the dynamic of the team, each member of the team has to know and consent to certain ways of doing things, be it protocols, tools, or convention.

This article will serve as an initial guide that ***may*** contain several useful topic to help you get started to work as a team member.

> Even if you are a solo-dev (wannabe), implementing several practices addressed in this article might be useful for you :crossed_fingers:

## :question: What do you mean by "Team"?
<p style="text-align:center;font-style:italic">
Software Development Team taken from <a href="https://alcor-bpo.com/10-key-roles-in-a-software-development-team-who-is-responsible-for-what/" target="_blank">Alcor</a>
</p>

Software development team usually consists of many roles, from technical to managerial roles. Software developer, UI/UX designer, product manager, analyst, etc. The *perfect* team will consists of members whose role are as shown above, but that's rarely the case. The core roles are of course software developers, UI/UX designers, managers, and the product owner. Without these roles, you can't expect the team to function correctly and achieve the goal successfully.

Throughout the project, each member must know each role's responsibilities and issues that arise must be communicated thoroughly and clearly to those who are responsible or directly related to said issues. **Never** announce specific issues randomly to every member as it could cause chaos.

:speaker: Team Communication
---
To ensure everyone is in touch--keep updated with ongoing progress and recent issues--, team has to decide what kind of communication will be done and which platforms to support that. As you may have known, there already exists hundreds of communication or team collaboration apps, but the rule of thumb is to separate daily or casual platform with working (professional) platform, that is use different apps and account to conduct communication related to the project. This is very important to preserve mental health of each member (believe me you don't want to be haunted by project's issues on leisure time and weekend).

There are some popular commuincation apps for this purpose, for example slack and microsoft teams. each app provides communication channel that is *cut-off* from your daily and casual social media, thus giving you better privacy on your daily life. Moreover, those apps are integrated with many software development managerial apps, making it easier to be used seamlessly.

Although team communication requires you to be able to communicate "humane-ly" to other members (that is use clear,articulated and noninsulting words), Never strike conversation related to the project with too casual, incomprehensible and pointless opening, for example :


In this example, the conversation starts with "hi" giving confusion to the recipient how to response this message. You should start the conversation by using simple opening and follow it with the issues you are going to bring up. of course, your message has to be well structured as it will help the recepient to grasp your message and respond with the suitable answer quickly. for further detail, visit [nohello](https://nohello.net/en/)

:dart: Planning and Tracking Progress of The Project
---
Projects that is going to be done has to be planned thoroughly, otherwise the team will have a hard time finishing the project in time. There are many approach or methodologies for this, for this article we will use agile's scrum methodology.

The idea of agile scrum is pretty intuitive, that is break the project down onto several part categorized by its "domain of work". these parts are called sprint and will be designated time limit (deadline) to finish. Each sprint will also be broken down onto smaller task and each task will be assigned members who are responsible. Usually the task breakdown will be done by considering its complexity and prediction of time to finish respective task. this prediction of time is known as story point.
<p style="text-align:center;font-style:italic">
taken from <a href="https://www.wrike.com/agile-guide/story-points-estimation/" target="_blank">Wrike</a>
</p>

Tracking the progress of your project is as important as planning the project, as it ensure that your project is progressing, not stagnant. Tracking the progress can come in any form, it depends to the team, but in scrum there's a thing called scrum board which looks like kanban board.

Scrum board basically looks like a board that has been divided into several section, which represent status of tasks. Whenever task's status changes, the it should be reflected to the board, therefore giving tracking information in realtime. below is the example


For this planning and tracking purposes, there are no specific app to use as it really depends on the team's choice and style. This features are usually available at 3rd party application, for example Jira, Linear and Trello, but actually github has started implementing these kind of feature for awhile called *github projects*. You can experiment with any application, and choose the most suitable one to your (team) preference.

:mage: Contributing to Changes
---

Now that we have discussed the "boring" stuffs, let's discuss the technical stuffs :sunglasses:

As the developers, of course we code and push changes to the codebase repository or perhaps start a new issue based on bugs we found on the production app. ***BUT***, we have to be conscious that now our progress are being tracked, our works are being watched, by other stakeholders. Thus, we have to consider how our works and progress can be understood by every stakeholder, not just by software developer fellas' technical perspective.

One approach to achieve this purpose is by "attaching" related information that consists of both brief and detailed explanation so that every stakeholder can understand.

### :ok_hand: Commit Messages

The idea of commit message is to give concise information related commited changes. Since the commit message has maximum length that is about a sentence only, we have to be able to utilize the length to the maximum. for example, take a look at these example

update user auth

fix: update session validation logic on user auth (#69)

between those 2, the latter is far more better. it gives you context (fixing bugs) of the changes, concise yet informative explanation of the changes as well as the issue related to the problem (#69). This gives a hint to anyone that read or review your code so they can understand your work, moreoever it gives better manageablity to the codebase since every commit has their own concise explanation.

The practice of this kind of commit messages convention is actually, again, no absolute rule or whatsoever, rather your team has to decide a convention and agree on it. There are many convention that's currently being adopted in many project, for example the *conventional commits* pioneered by community of angular/google https://www.conventionalcommits.org/en/v1.0.0-beta.4

In the end it comes back to the devs in the team since they're the most affected by this, but it's better to use the one that is easy to understand.

### :raised_hand_with_fingers_splayed: Issues and Merge Request

Let's start with examples

<p style="text-align:center;font-style:italic">
1st example
</p>


<p style="text-align:center;font-style:italic">
2nd example
</p>

Definitely the 2nd example is better merge request. You can see the fix is clearly stated on the title, the detail explains the impact of the update and it also attaches screenshot of passing test to prove that the update has been "tested" and works.

As a reviewer it is also encouraged to ask the creator of merge request if there are things to be clarified, never be shy or reluctant, it's a must!


<p style="text-align:center;font-style:italic">
Clarifying things on merge request
</p>

For issues, it's even more leeway, in a sense you don't have to follow specific structure of message as long as the issue you raise is clear and the what, how, when, where is explained. take a look at this example


<br>

This is definitely a bad example, why? because the issue is far too ambiguous. the statement *it doesn't work with my system* gives the project contributor 0 knowledge of the unknown issues. Moreover, it will end up to double-barelled question from the contributors end to inquire more detail of the said system :face_palm: . One of the better example looks like this


It might not be the best, but it clearly states the issue, what and why as well as some insight how the contributor should resolve the issue, therefore more efficient.

:books: Conclusion
---
As software engineer, one must learn how to interact and socialize with other stakeholder professionally. To support this, one must be able to communicate well and be in touch with others, plan and track the progress thoroughly with others, as well as creating changes to the product with detailed information to be understood by stakeholders.