The beginning

A discussion on the following will be held on the first day if not already done so during the hiring process.

• Objectives
• Discovery & Baseline
• Intro to the wider team members involved (unless the project is fully autonomous)
• Setup of board (JIRA/trello etc)
• Backlog and briefs (requirement gathering)
• Access to repositories
• Access to infrastructure as per requirement
• All other points in this document

Proposals

In order to develop a story with new concepts - to radiate these concepts to the wider team - proposal documents will be used to inform what/how/where these concepts would apply. It is expected that at-least 1 developer would be able to read and approve a proposal put forward (unless the project is fully autonomous).

Work progress visibility

Setting up a separate board to deliver objectives would be best for visibility. However we don't have an issue using the same board as everyone else to track progress if it is easier and provides visibility to other members of the development team.

Development workflow (Board layout)

Todo
In development
In review
Data Testing
Done

Definition of ready (DOR)

The contractor is expected to form the story if not already formed from client requirements. It is expected that the PO would provide the contractor with a brief/requirements or the story to be developed. Relevant wireframes, associated systems should be shared to minimise iteration cycle.

• Story has acceptance criteria
• Story has caveats outlined
• Story has wireframes attached if related to UI feature

Definition of done (DOD)

The definition of done is assumed to be merging of all code into master and deployed onto production. This can be hindered by code previously merged and not deployed. In such cases, the done column would represent only merge into master without deployment onto production.

• Acceptance criteria has been met
• Coding standards are met
• All packages are tagged
• All code checked into master branch
• All database migrations are ready to be deployed (MR raised in case of auto deploy to prod)
• Automated tests are written and passing
• CI passing
• Code has been peer reviewed
• Relevant documentation has been updated

Assumed strategies

• Git branching strategy.
• Semver versioning strategy.
• Fix forward strategy.
• Test automation (Unit/service/behaviour).

Work flow

Stage	Step(s)
Todo	Information gathering Proposal
In development	New feature branch Develop/test automation
In review	Merge request/PR Approvals
Stage testing	Deploy to stage Test on stage with real data
Done	Merge in master Reference document updated Push tag Comms out

Bugs

Bugfixing follows the same process as above, preceded by the encounter step.

Stage	Step(s)
Encounter	Raise issue on tracking board with details and state of system. Comms out to PO/prioritise Triage (Validate, estimate severity and dig out more info - timeboxed)

Hotfixing

In case when something goes wrong on production, a hotfix may need to be released to address the issue as soon as possible. In such a scenario automated testing may be switched up with manual testing.

Stage	Step(s)
Encounter	Raise issue on tracking board
Todo	Information gathering
In development	New hotfix branch Develop/test automation if quickly doable/manual testing (smoke, sanity)
In review	Merge request/PR (Possibly over the shoulder PR) Approvals
Stage testing	Deploy to stage Test on stage with real data
Done	Merge in master Reference document updated Push tag Comms out

Contacts

Contacts when queries arise for different domains.

Domain	Contact	Secondary contact
Infrastructure/DevOps	...	...
Development proposals	...	...
Billing	...	...
Retro Feedback	...	...
Product owner/project manager	...	...

End of contract

It is expected that the client will make some time for a handover/walkthrough for the work that is either partially complete or the team needs the skill transferred to continue developing the tech.