Developer's guide to remote collaboration

Pre-requisites

This article assumes basic git and GitHub understanding and use

So, collaboration...

The first step of effective collaboration is identifying a software development methodology to use - or Software Development Life Cycle(SDLC)

As a software developer, it is inevitable that you have/will encounter Agile methodology. A good place to start is by reading the Agile manifesto and the principles behind the manifesto. It is brief, yet complete. It was written by 17 software developers who sat together to uncover better ways of developing software. However, agile development is beyond the scope of this article but may be something of interest to you as it focuses on a developer's mindset and values, not tools or processes.

Tools

Because we still value these items on the right, we need to consider various technologies that will make remote software development and collaboration seamless and effective.

Definition of scrum terms

Scrum is an agile project management framework that describes a set of meetings, tools, and roles in team work.

1. Scrum master - is ideally dedicated to just one team, to avoid context switching. She/He is in charge of leading daily standup, addressing blockers, merging approved pull requests, and coaching the team on best practices.
   • The SM role assumes servant-leadership, a way of leading people without having formal authority over them. The SM resorts to setting a shared vision, involving everyone in the decisions, coaching the group.
2. Scrum team - the team of developers and designers working on the project. A scrum team is ideally self-managing and cross-functional.
3. Backlog - master list of work that needs to get done to complete a project
4. Blocker - an obstacle faced in the tackling of an assigned task
5. Standup - in a team of developers working on a project, short meetings are held daily, usually in the mornings. The term comes from the fact that during the meetings, a developer literally stands up and states briefly:
   • What did I do yesterday? -achievements-
   • What do I plan to do today? -tasks-
   • Am I facing any challenges? -blockers- Note: Standups can be run as often as suits the team
6. Sprint - a time period, usually between 1 week and 1 month, but typically 2 weeks, in which a team works to complete a set amount of user stories. A project is generally divided into sprints in which, each sprint should produce a usable end-product. - increment-
7. Kanban board - a basic board divides a sprint into cards'To do', 'In progress' and 'Complete'. It can be altered to suite the needs of the team with cards like 'In review', 'Resources'

Breakdown of tools and processes

Processes:

• Organize product backlog from stakeholder feedback and requirements
• Plan sprints, set timelines and allocate tasks
• Run sprints with daily standups
• Production

Tools for:

1. Communication
   • Slack is a great tool for general communication and integrates with numerous developer tools.
   • Google Meet is great for running standups even in large teams. It allows for screen sharing and has no time limit for a large number of attendees. Google calendar also comes in handy when scheduling recurring meetings.

2. Project management
   
   Kanban boards come in here.
   
   Each GitHub repository has a Project section for managing tasks within the repo. Some external resources include:

   • Trello
   • Atlassian Jira

3. Design and prototyping
   
   Design is an important part of a collaborative project. It helps front-end developers from straying from the agreed upon design saving hours of back and forth.

   • Figma - web-based, collaborate as you would on a google doc

Coding

When it comes to coding in a collaborative environment, coding best practices play a major role in it's effectiveness.

1. A good place to start
2. A good article - The perfect code review process. The writer of the article, Robert Cooper, takes you through a fictional scenario of Jimmy and his team
3. Gitflow is a branching model in which every developer in the team works on independent features. A feature should not be dependant on another feature. Programmers should be able to work on features simultaneously without having to wait on the work of another developer.
   • Naming convention - each developer works on a feature branch eg: ft-header, ft-authentication, ft-models
   • Pull requests are made to a development branch not main/master. At any given time, the master branch should contain deployable work (no bugs, no incomplete work). An incomplete branch should never be merged
   • If modifications are requested after your branch has been reviewed, interactive rebasing should be done, no extra commits.

Extra remarks

• Take some time and listen to some of Uncle Bob's talks on Youtube
• Read: Best practices when it comes to git commits
• Always keep in mind:
  • Code is read more often than it is written.
  • It is your duty as a programmer to write readable and maintainable code.

Happy hacking!