Development
approach
Work teams
The work team always consists of at least three people: a developer (frontend, backend or full stack), a Project Manager or a Lead Dev (hereinafter PM) and a QA. It is often the case that if a project is very dynamic there are involved two QAs or even more in order to ensure better performance and flexibility.
We usually make teams including 3 to 7 people. Not all team mates may be 100% involved into a project. For instance, PM may have to allocate only one or two hours a day to a particular project, while QA may spend 4 hours. However, developers are fully involved into the project spending on it 8-10 hours a day.
You are looking for getting a high quality result minimizing the costs at the same time. The approach we offer is exactly the one that helps us achieve this. Everyone is doing his job, which allows us to cut the costs and make it less time consuming, while keeping the top quality.
Scrum, kanban,
task by task
Choosing an appropriate methodology among Scrum, kanban or task by task depends on a number of parameters, which is the project size, the client’s wish, whether it is an in-house work or collaborating with the client’s team. All our guys have clear regulations covering each of such cases, allowing us to be productive and flexible at the same time. A particular methodology can only provide with recommendations, and not strict guidelines.
There is still one thing that our company is very proud of and that is always subject for improvement; it is our loyalty to and strict compliance with Scrum basic concepts. We have of course reconsidered the idea a bit taking into account our mentality.
Note: We work with clients from different countries. Everybody has their own specific features in terms of communication and mind set. We do our best to take them all into account. But if it might seem to you that we tend to ask too many questions, that we are too straightforward or even rude. However, this is just a part of our mentality, and it only reflects our desire to solve as many issues as possible very quickly. In rush, unfortunately, we may disregard the difference between our linguistic and cultural background and that of the other nationalities. Despite this, please be assured that we deeply respect each of our clients. And we strongly believe that there is nothing better than work delivered with high quality and in the due time to show our affection and loyalty to the client.
Task processing
The project is usually divided into smaller parts. Each part can be divided into independent functional blocks. It is done so that each block, once the work on it has been completed, is able to be uploaded to dev server and then deployed to prod server.
Each functional block will be divided into smaller parts and will go through a few stages. The first comes Discovery Phase, including the task description and additional technical description of the project, choosing implementation medium, making a check list, approving it by the team, working on the task, self test performed by the developer, going through the check list by a developer, going through the check list by a QA specialist, working on a bug report, going through the check list again, delivering to the PM, showing the work to the rest of the team (if necessary), monkey-testing, delivering to the client on a dev server, and deploying to the prod server. After that comes going through the check list again, performing a smoke test or a regression test. And finally the task is ready to be delivered to the client.
Note: In the description above there were omitted some technical processes such as branch merging, conflict solving, seeders update, checking the app on different devices and OS, checking with the help of Google Page Speed, Google Lighthouse, webpagetest.org and other operations included into task processing.
One day in the life of the team
The guys come to work by 8am (GMT +3). PM and Lead Developer set time for the daily briefing on each project (stand up). Everybody prepares to the briefing. During the briefing the team discusses some bottlenecks and a current plan (sprint plan, weekly plan or a current task pool plan). After that they decide on what exact tasks are to be solved in that day. The day plan consists of the tasks and checkpoints. After a short briefing when everybody understands what he/she is due to do, they start working.
Let’s take a simple example. A developer has three tasks for today, and checkpoints are at 10:30, 14:00 and 16:30. It ensures that at least two out of three tasks will be performed and checked by a QA within this day. And if nothing goes wrong, the third task will also be completed and checked by the end of the day or the next day in the morning before the briefing.
At the end of the day it is summarized what has been done during the day. If something hasn’t been done, the reasons are being discussed and sorted out. This way, we try to totally stick to the day schedule, which allows us to complete the sprint (weekly plan) in time, and at the same time keep the highest quality.
It really works
With the help of our guys’ efforts and continual discussion with clients we detect all the problems in a timely manner and eliminate them during the development process. If there are no force majeure problems appearing during the development, it will be done in time. Otherwise, all participants of the project will know about the problems firsthand, and altogether we will be able to work on the possible workaround.
Hourly work is truly breaking new ground of agile work. Implementing Scrum concept and its methods allow us to deliver a product which meets the needs of clients in terms of web development.
One project could contain
of Test Cases or Checklists
(slicing)
of Test Cases
or Checklists