PROCESS PLANNING – AGILE TECHNOLOGY

SourceCloud follows an Agile development methodology, for small tasks these will be defined as stories in the ‘backlog’ where the product owner (Client) and the development team will define the exact requirement and acceptance criteria.
The development team will estimate the tasks during the same process before it is added to the sprint for work to commence.
For Major Developments, we use a lifecycle, consisting of four phases, Discovery, Design, Development, Deployment.

DISCOVERY

 

At the outset, the requirements are developed working with the client with a series of interviews and workshops.
All documented in Atlassian Confluence detailing the major deliverables, requirements and priorities using the MoSCoW approach. These will form the Product Requirements Document (PRD).

Sample PRD

DESIGN

Sample Backlog

The PRD created in the discovery phase is broken down into Epics, Stories and tasks within Atlassian Jira. Allowing the development team the ability to provide more technical details on developing each task, including initial estimates in terms of effort.
This is also the phase where wireframes are created for user journeys, the style guides and UI/UX designs are also confirmed. Submitted designs can then be sent to the client for review and sign off.
Each set of Epics will typically be assigned to a release version providing a roadmap of feature releases and complete traceability throughout the whole development process.
Our test team will work with the agreed requirements to develop the required test cases to meet the exact requirements.

DEVELOPMENT

The development phase starts a few days before the sprint, where the Product Owner and the Development team order the backlog, adding further details to the stories as required.

A sprint starts with a retrospective and planning meeting, attended by the whole development team including the product owner. The session starts with a demo of a ‘potentially shippable product’ on the User Acceptance Testing environment (UAT). This demonstrates the work completed in the sprint to the Product Owner against the requirements.

This is followed by a review of ‘what went well’ and ‘what did not go so well’. The final part of the session involves discussing each story starting at the top of the backlog with the development team assigning a points value to it, before adding it to the sprint.

Typically sprints run fortnightly, using the tooling provided by Jira we can quickly highlight issues in terms of estimates and overruns.
Code is developed and checked in to our source control several times a day against the specific tasks in Jira. Providing complete traceability and near real-time progress updates as well as securing the code.

During the sprints, SourceCloud will release interim releases internally to continuous integration (CI) system for both automated and manual testing. Ensuring the code meets the Clients requirements at all stages of development.

Our test team will develop test scripts from the acceptance criteria in the stories and use a combination of automated, regression and manual testing, making sure the requirements are delivered. They will test core components as they are released feeding them back into Jira, ensuring defects are captured at the earliest possible point in the development process.

At the end of each major release, SourceCloud would always recommend that the system is ‘Pen Tested’ by an independent 3rd party. SourceCloud uses an external Cybersecurity company, but the client is welcomed to use their preferred company for ‘Pen Testing’ if they so wish.

Sprint Cycle

DEPLOYMENT

The output from each sprint cycle is known as a Potentially Shippable Product and represents the product backlog items for the sprint. In the early phases, this will be in a test environment where the client can review the released features. Versioned releases will also be released as part of the corresponding Sprint cycle.
Versions are usually defined by a wider set of user-defined features and comprise of several sprints. Our test team will complete their testing scripts with each release before releasing to the client.

SourceCloud uses a DevOps pipeline for all projects and is used to using either their own internal pipelines, the clients in house solution or a combination of both.  Internally we use Bitbucket, Teamcity and Octopus utilising Ansible, PowerShell and Liquibase for Windows and Linux solutions.  With our clients, we also use Docker, Bamboo and Jenkins.  Typically, we will define a lifecycle environment containing CI > UAT > Staging > Prod, though these are configurable on per client basis.

DevOps Pipeline

TOOLING

As an organization, we use several products to develop, test and deploy our code. Including the Atlassian suite of products, Jira, Confluence and BitBucket to manage our development lifecycle.
Our internal DevOps pipeline consists of TeamCity, Octopus and Ansible to manage deployments to all our environments. This provides a complete audit trail from a released version, back through release cycles, test cycles, bugs, tasks and design.
Other tools are used for our automated testing including TestRail, Selenium and jMeter. Some clients prefer SourceCloud to use their preferred tools which have included Jenkins, Bamboo and TFS.