Project Organization
Each team member has a specialized role while working together as a group.
Yasara Peiris - Web UI Design and Development
Ning Xie - DevOps Engineer and Project Manager
Ali Yassine - Product Owner
Yuchen Zhang - Java Systems Engineer
Throughout the project we have followed an adapted Scrum methodology, whereby we tried be as flexible as possible while still maintaining the scrum principles.
We had set a rough overall roadmap in the beginning stages of the project, where we defined and organized four Epics/Phases (more details in sections below). A weekly meeting was also set where we would begin by everyone presenting their updates and progress, then we would define and assign new tasks as need and setting priorities. After each sprint of the project, the weekly meeting would take the form of a sprint review and the next sprint planning.
To facilitate the scrum process we setup a scrum board in Jira. In addition, we used Zoom for our weekly meetings, and has setup a WhatsApp group to facilitate communication.
In the sections below you will find more details concerning different aspects of the project organization.
Below is a Gantt chart of our roadmap, which is divided into 4 main Phases, and you can also see the durations of the five sprints.
Phase 1 summary:
Sprint 1 mainly consisted of coming up with an idea and defining the project. This included defining the requirements, solution, architecture, and operational model (including technologies & languages).
For Sprint 2 we set out to define an initial UI design prototype, setting up the development environment (GitHub Repo, connecting Jira, CI/CD), and to get familiarized with the Google Maps API and start development on the different microservices and front-end.
Phase 2 & 3 summary:
Sprint 3 consisted mainly of software development on the microservices and the front-end. This is where we had to go over multiple iterations until we had a minimum viable product. Alongside development testing was also given a priority.
Then, Sprint 4 was mainly focused on improving the web application which included removing bugs, adding quality of life improvements, UI improvements. This sprint also included polishing the source coding and removing code smells.
Phase 4:
Sprint 5 also included improvements and minor fixes, but was focused on final testing, and setting up the system to be deployed into production. It also focused on setting up documentation and reports on the project.
We have completed 46 issues and released the version 1.0.0.
A detailed view of each sprint (including stories and subtasks) and project status can be found in our Jira Dashboard.
For storing the source code, we chose to follow a Monorepo structure as our project is quite small and only has two micro services. We are keeping all the modules, including the client and back-end microservices within one repository. The GitHub Actions CI/CD pipeline allows the workflows to be triggered on individual subdirectories, therefore we are able to build, test and deploy each micro service and client module separately while keeping them in the same repository.
In order to see the git branching graph please download and open the file: https://github.com/ningxie1991/AScout/blob/develop/images/Wiki/commit-graph.html
For versioning control, we reserve the main branch for release activities, and the develop branch is used for development. In order to connect the development activities with the Jira stories, the naming convention for each feature branch is prefixed with the corresponding Jira story ID. The CI pipeline is used on the develop branch and the CD pipeline is used for both develop and main branches. Because we are keeping a Monorepo structure as mentioned above, the SonarCloud Plugin workflow has some limitations since it can only scan and generate report for one module at a time. In order to scan and generate SonarCloud reports for the two microservices separately, we created two branches specifically for Sonar scanning. The two branches are scan-browse-service and scan-calculator-service.
You can find how pull requests were handled here: Pull Requests