Make Your Clients Happy - How we ensure quality in XR Applications/Games
Developing an Immersive Experience Application was never too hard. With proper developers, designers and Analysts, Developing is never a problem. But Quality Assurance is. As the technology is quite new and people are not aware of its full potential, They often forget to make sure the quality of the product, which led to client dissatisfaction, waste of time, and eventually high development cost.
At Brain Station 23, we solely focus on client satisfaction and the best quality product we can deliver. To make sure that we deliver the most polished, scalable, and immersive experience, we follow some strategies from the moment we get a project confirmation to the delivery of the project. So far, using this strategy, our clients are very happy with the workflow. We keep everything transparent between us and our clients. Which makes them more confident and leads to new clients or returning clients. Let’s talk about how we make sure that we deliver the most authentic experience to our clients.
The Development Pipeline
Our Development Pipeline initiates when we get confirmation of a project. There are several key points that help to make your application great. I will be discussing the most important points below. All the points consist of 3 things.
- Duration- How Long it takes to finish that part
- Members- Which members are to be engaged with the process
- Description- Brief discussion on what, how, and when.
Project Initiation
Duration: 2–4 Weeks
Members: Business Analyst, Project Manager, Tech Lead
After starting the project, The very first thing we do is to define the scope of the project. We list down everything we know we are going to do. Then we discuss it with the client for confirmation. After we complete defining the scope, We choose which developers and designers will be suitable and feasible for the project and assign them to the project.
Now, Specially in Immersive Experience Applications, there will be some gray areas in the development. There will be some tasks which either you don’t know how to do or you don’t know if even it is possible. We list those Risks and Discuss them with the client about that (PLEASE DO THAT). And if needed, We assign people to create a proof of concept to minimalize the grey areas.
For the rest of the duration, we create software design documents (SDD) and other related documents. Meanwhile, we initialize the version controlling for the project and set up the Jira.
The most important task of this phase is to keep the client updated about everything and take confirmation. If you can do that, there will be no confusion in the future regarding scopes and deadlines. This will clear any confusion the client has and increases their trust in us. which makes working on that project hassle-free.
Starting The Project
Duration: 1 Week
Members: Project Manager, Tech Lead
After finishing the initialization, All members of our team know the dos, Don’ts, and limitations of the project. We are all on the same page. Then, The project manager prepares for the war.
We initially define the first 2 sprints. We list down all the tasks we want to do in those sprints. Then we give each task a deadline. After that, we write down all the possible test cases for the system. This is important because as the project grows, it becomes too hard to test everything manually. So setting up and defining test cases before the start of the development will save you a lot of time. As the sprints are now defined and we are ready with deadlines and test cases, We start development.
Sprints
Duration: 1–2 Week(s)
Members: Project Manager, Tech Lead, Business Analyst
Our full development of a system consists of multiple sprints. Before a sprint starts, the project manager makes sure that everyone is on the same page. Everyone has the same vision of what we are going to create. Then we start creating each task in Jira. Each branch and commit is then get connected to the Jira for CI/CD pipeline. Then we assign tasks to developers and designers.
From the second sprint and later, if anything is left undone from the previous sprint, We assess the situation, find what went wrong, and acknowledge the whole team regarding it. If a sprint is longer than a week, The project manager doesn’t wait for the whole sprint to end as he keeps track and reviews the project weekly.
Tasks
Duration: Maximum 4 Hours
Members: Tech Lead, Business Analyst, Developer(s)/Designer(s)
Now it's time for the developers and designers to do their part. The tech lead and the business analyst sit with the developer/designer and explain each task and expected outputs. We make sure that before starting a task, it must be done in a separate branch as it must be connected to a project management tool (Jira) for automation.
We define each task such that no task takes not more than 4 hours. It is very crucial as it makes sure we remain aligned with the objective and also for the developer/designer to have more room to breathe. The most amazing thing of our workflow is that we never overburn our resources. Happy resources translate to great products, which produces happy clients.
After getting reassured by the developer/designer about the task, we consider the task is in progress.
Task Development
Duration: Maximum 4 Hours
Members: Developers, Designers
Now it’s time for developers/designers to start doing their work. They must make sure that they understand the requirements and limitations of the task. As the deadline is set by the tech lead, if they don't think that the deadline is proper, he makes sure to clarify that with the tech lead before he starts the task.
After that, Developers finish their tasks in the given time. While developing, they make sure that there are no environmental issues. This guarantees a develop and solve work style which ensures the developer has tested every known scenario while developing.
After the developer is happy with the current result. He creates a pull request from the task’s branch. While creating a pull request, he has to fill out a form. Where he has a checklist of what to do before submitting. This guarantees that he has written and ran all the necessary test cases, has done proper commenting on scripts, and others.
If the reviewer reports any issues, he fixes that and creates a new pull request. This process repeats until the pull request is accepted.
Task Finalization
Duration: A Few Hours to Days
Members: Business Analyst and Quality Assurance Engineer
Once a pull request is accepted, the QA starts to test the system for that specific task. Before everything else, he runs all the test cases in the project. It’s a fail-safe strategy to make sure everyone is doing their part. Then comes the labor part. The QA test the specific task features manually. He will try to simulate all the possible actions of that feature. He also makes sure it runs properly on every target platform.
After all this rigorous testing, if any issues are found, they create the issue on Github and notify the PM personally.
Task Closing
Duration: A Few Hours
Members: Business Analyst and Project Manager
If any issues are found, we have 2 approaches. If the issue can be fixed in less than 2 hours, we fix these before closing the sprint. If not, We add it as a new task for the next sprint. If no issue is found or the issue has been fixed, we close the task.
Sprint Closing
Duration: 1-2 Day(s)
Members: Everyone Related to the project
On the final day of a sprint. We all sat down and go through the current state of the system. We make sure that every task in the sprint has been closed. If any task is not done, we learn the reason(s) and take necessary steps so that it doesn’t repeat.
After we are ready with what we wanted, We take a meeting with the client and show them the progress. We take their feedback and note those as tasks that are added to the next or any later sprints depending on the priority.
Then we close the sprint and Start the next sprint.
Client Showcase
Duration: Depends on Milestone
Members: Project Manager, Business Analyst, and Tech Lead
There are several milestones in a project. Each milestone addresses a major feature of the project. Every milestone consists of multiple sprints. After the final sprint of a milestone, We push the build to our distribution branch in git which is automated so that every stakeholder of the project gets a copy of the build to test.
This pipeline ensures that every stakeholder is being notified and delivered a build so that there is no issue in distributing the build to the client. Which makes the build process faster and smoother.
Before I Go
Each team has a unique approach to how to complete a project. In our team, we tested that this approach results in the highest client satisfaction and overall team happiness.
If you want to see more of our works and have something to discuss, You can visit our Website.
I am really glad to be able to share our work model with you guys. Hope this helps you or your team to make the next client say “Awesome”. Because We, The Devs are Awesome.
