1. Introduction

A template or starting point for the guidelines for remote teams which are the new norm in the software industry.

As we are a decentralized team working from different locations and timezones, its very important that we use technology to mimic working from the same office. This document assumes that the project management tool, source code repository and time tracking is done with Phabricator

A KPI can be created based on this guidelines.

2. Software Development Process

We have a challenging technological task to undertake and since the underlying technology is new to majority of the team members, detailed documentation is needed to get everyone upto speed. Once we achieve the initial ramping up, its possible to adopt an agile development model with weekly deliverables (SCRUM sprints). The Waterfall model expects to have Architecture document, High Level Design Documents, Low Level Design documents with interface and API specification, Release Management documents etc. To keep the ever changing real world demands, we will not be define and baseline (finalize and approve) all the documents. So we will reduce the category of documents and will combine them into fewer points.

At any point in time, required reference documents for at-least one month worth of deliverables should be readily available to the technical team.

3. Documentation

The project involves blockchain technology which is new for many of the team members. This makes it important to have to detailed documents capturing the design, features, APIs to developed, Coding Standards, Data structures to be used, Development tools, linting tools, Databases etc. Once we have a formal document outlining the above we can create use cases.

Since we have to follow a mix of traditional waterfall model and agile model to enable efficient functioning of the development, QA and design teams, the required documents are defined as below. Top level documents provide the guidelines for the ones below it and any changes to the top level documents will result in the related documents.

1. White Paper and Story line - Technical or non-technical overview
2. Architecture - The high level architecture of the project, system concept, Design Patterns etc are to be captured in this document.
3. Design (FDD, LLD) & use cases Document
4. API documentation

3.1 Document Review

Team members should review and the version in the repositories should be considered.

4. Task management and tracking

At any point in time any team member should be able to provide one more Tasks she is assigned and working on. Further she shoul be able to map this particular task to version controlled & reviewed documents.

We use phabricator and similar tools for project management. Phabricator has an option to track time and make sure that at any point in time, you have a task assigned and you are tracking time against it. This will help everyone else to see what is being worked on.

4.1 Types of Tasks

New Feature - A new feature and can always be mapped to a use case in the Design and Use case document

Change Request -Use case or scenario changes must be addressed via change requests and original use case behavior and new behavior should be clearly captured in this case.

Bug - Any deviation from an expected use case result due to an implementation bug or external factors. A bug should always have associated severity and priority.

Maintenance - regular maintenance activities like clearing system logs

New features are welcomed but bugs, change requests and maintenance are not necessarily productive.

4.2 Priority of Tasks

The tasks should be attempted in the order of priority & time of completion will be mapped to the priority of the tasks or feature.

4.3 Severity of Tasks

Seriousness of a bug or a tasks is captured and represented in the the severity

5. Communicate using chat tools

Always use the chat tools like Slack or Rocket.Chat to communicate. There is nothing like over communicating. Don't forget to introduce when a new member is joined. Send your photographs, family photographs, photos of your home etc to make everyone understand your backgrounds. Share your hobbies and things that you like Soccer.

6. Use screen shots and screen sharing

Always use screen shots and screen sharing tools to communicate. Tools like Firefox screen capture, Snagit, MURAL.co etc are extremely useful. Use the screen sharing feature of slack or tools like teamviewer.

7. Respond to emails ASAP

Make sure that the emails are responded in near real time and in the worst case scenario, within 8 hours.

8. Quality of work

The code that write should be well documented so that everyone in the community can understand, error messages and other details should be clearly displayed, how tos and guidelines should be provided. Code must be accompanied with test cases or test procedure.

9. Coding Standards

Irrespective of the programming language that you are using, they must adhere to the respective coding standards and style.

Python: PEP8

PHP :

Javascript:

C++:

10. Tools

Code Editor and General Editor - Visual Studio Code

Editor in servers - Vim or Emacs

Markdown Editor - Typora

Compilers - gcc, g++

Chat - Slack

Build tools - make, cmake

Screenshot tools - Snagit

Documents - Microsoft Word, LibreOffice and Pages on macOS

Connecting to servers - ssh, tmux, mosh

security scans - Nessus, OWASP Zap

API doc - Swagger

linting - arcanist

4. SCRUM

For the software development process we will be using the agile SCRUM model with small weekly milestones aka sprints. Every Tuesday we will do a release of the code for the QA. The weekly milestones are created to achieve fast iterations.

4.1 Weekly sprints

We will have weekly milestones terms as sprints where we will implement features. Every team member will have multiple tasks to complete in every milestone. The task completion will mean completing the documents, feature description in Gherkin or a similar language to make sure of test driven development, committing the code to the repository, implementing suggestions from the code review tools and manual code reviews.

Git tags

PROJECT_MAJOR<RELEASE>_MINOR<RELEASE>_sprint_<MILESTONE_NUMBER>_DATE<OF_COMPLETION>

Development and QA can be denoted using tags.

www-01_sprint_<NUMBER>__<DATE>_ : version numbering for a sprint in web wallet
www-01_sprint_<NUMBER>__<DATE>_QA : versioning / tag for QA
www-01_sprint_<NUMBER>_<DATE>_RELEASE : Production Release

Patches should follow the name convention as follows (need to follow gitflow)

www-01_sprint_<NUMBER>_<DATE>_RELEASE_Patch<NUMBER> : This can be the patch against a specific release

CI

Jenkins, Travis and such tools can be used. But in the current scenario, the preferred choice will be use the advanced features from Gitlab.

CD

Continuous Deployment to be added.

FAQ

I am committing code, how to do it ?

We use Git as SCM (source code management tool). Every commit made in Git should have an associated task with it. You should clearly mentioned what will you achieve with this commit and how to test it.

While committing code to Git

• Provide git commit messages explaining your commit
• attach the commit to a specific task which can additional details about the commit
• Code reviews should be raised - this is important
• linting - code should be linted and evaluated to follow acceptable coding standards
• Capture the special cases
• Every commit MUST accompany automated test cases or a procedure to test.

How to create a bug / Task

If its a task, clearly mention the feature name, use case code etc. Expected out come and special scenarios should be captured.

For a bug,

Clearly mention the steps to re-produce the bug. Environment like OS, browser etc must be mentioned.

While closing the bug, if there are code changes, the code commit should be attached to the bug. A small description of what was done to fix the bug should be provided. Steps to test and any special cases that is ignored MUST be captured.

FAQs

Its a great idea to have an faq session which will address most of the questions developers will have.

I am a Javascript developer who also used CSS and HTML what should I do ?

Code should be bundled, modularized, and always minified. White space removal, minification etc are mandatory for any HTML, CSS and Javascript that we deploy to testing, sandbox and live environments.

---

Vote for me as STEEM witness

1. You can do so by clicking the link above & enter your private key when asked for.
2. Alternatively, visit https://steemit.com/~witnesses