Professional Services Project - Developer Resources and Processes

Objectives:

This article is designed to document the expectations for a developer on a Flywheel professional services project.

Our processes and systems may change over time and this document should be kept up to date to reflect that. 

Terminology:

Throughout this document the following terms will be used:

CSM - Customer Success Manager. The Datasync employee who is managing the project.

Developers - the developers (usually Devtac) who will be working on the project. 

Customer - the Flywheel end-user organization

Project - a project for a customer. Each project will have a signed Statement of Work Document and a defined scope. Sometimes referred to a  'Phase'

Systems:

Asana - Business Requirements

Jira - Technical Requirements

Bitbucket - Code repository and package builder

Package Builder - the Grunt-based package compiler

Digital Ocean Spaces - Scrubbed instance storage

Harvest - Time entry

Requirements - Business and Technical

Business requirements will be stored in Asana. These will be taken from the SOW Document. 

The customer will have a User in Asana.
Developers will share a user in Asana.

Developers will not be responsible for moving items in this board. The CSM will own and manage this tickets

Technical Requirements will be stored in Jira. Datasync will enter the high-level requirements before the project starts. 

These will usually be as Stories. The Story will have a link to the corresponding Business Requirement(s). 

Each Project for a given Customer will be linked to a Release in Jira.

Developers will be responsible for breaking the stories into logical Tasks. 

Developers may be required to enter Estimates. If so, these should be at the Story Level. 

Developers will be responsible for moving the Jira tickets through their lifecycle. 

Development - code:

Developers must be very familiar with Datasync's "Appropriate Flywheel Customizations" guide. Any customizations that do not comply will be rejected.

Datasync will create a Bitbucket repo for each Project

The repo will start with Datasync's Package Builder.

The developer should make commits which should be tied to the corresponding Jira tickets. 

At logical intervals, the developer should generate and commit a package.

The Package Builder ensures that packages are built in a consistent and linear fashion. It handles proper versioning and timestamps.
The developer is expected to read the Package Builder documentation (in the readme file) and to follow the instructed process. 

Development - instance:

Datasync will make available scrubbed versions of customer instances.
These will be uploaded to the Flywheel Proserve Digital Ocean account. 

Datasync will upload one copy at the beginning of the project. 

If the Developers request it, Datasync can automate this so the copies are created daily. 

Developers are expected to be responsible with the backups. 

Quality Assurance:

Developers must QA their own code before moving a ticket to QA or Done. 

Datasync will perform QA on our own copy of the customer instance. Datasync will move tickets or generate Bug issues as needed. 

Current Limitations and Future Goals:

Currently, it will be somewhat difficult to have multiple developers on a project - they would have to coordinate closely regarding building the package. Eventually, we would like to apply the Continous Integration package builder that is in place with the Flywheel core project.

Eventually, we'd like to provide access to a server with a QA instance. For now, Developers will need to develop and QA on a local copy. 

Eventually, it may be nice to use a Pull Request process. For now, Developers will need to be responsible.

Communication:

Communication should be in the appropriate scope. If the Developer needs to communicate with the customer, then this should be done via Asana. If the developer needs clarification on a technical item, then he should tag the CSM in a Jira comment.

For the most part, Datasync will attempt to mainly communicate with the Developer through Jira. 

Time Entry:

All time should be entered within the related Jira Project, under the applicable story or task.  IMPORTANT! - All time entries should be entered into the system by the end of business.  This requirement exists so that we can ensure close monitoring of the customers budget.