Minicabit is a platform for private and business users allowing them to book a cab. Users can get the best price on a minicab or taxi by comparing cabs across 550 towns and cities. In general, the system consists of a few components designed for different types of clients as well as for taxi companies.
The main problem we encountered at the beginning of the project was a poor development process that didn’t give any outcomes at all. Scrum methodology was completely not suitable for the team and the project. The team was struggling to deliver work via Sprints, but in reality, sprints became more and more overwhelming giving poor results and affecting priority lists and critical tasks. Lack of project management resulted in an unclear state of affairs, while lack of documentation resulted in the absence of schemes showing the communication between admin panels, unsettled workflow, and the situation where even the client couldn’t determine the gaps in the project. Considering all the above-mentioned facts, one can tell that there was lots of work and challenges awaiting us but we’ll get to that a little later. When it comes to the project complexity, we should mention that several systems were developed in different programming languages (e.g. a part of admin panel was written on the outdated PHP version, while some parts are written in Node.JS), there was a complete absence of deploy, that is the process of code result transfering, and everything was coded in one branch.
As the project was undergoing for a long period of time before getting into the ASD team’s hands, we had to do a careful study of the project itself both in terms of the code and any associated documentation. Apparently, we started with the team composition based on the clients’ requests, and only after that, the setup of the actual development process began. Firstly, we were coding along with the client’s in-house development team but moved from Scrum to Kanban development methodology. Kanban methodology helped the team to deliver tasks gradually giving the possibility to focus on tasks and better quality of the code. Next step, we managed to deal with the unreleased code, split it where possible and deploy parts which were blocking us from developing further. Moreover, our tech lead established a new development flow in GitHub explaining how to create and manage branches, and the team started to work according to it. Subsequently, as we marked the beginning of a new development workflow, the client decided to go with the development team on our side only, reducing all the development personnel on their side. During the changes in the team composition, there were 1,5 months of knowledge transfer sessions, where our team was gathering all the project information, based on which we started developing project documentation.
After 2 months of ongoing projects, we extended the development team with a Business Analyst, who was communicating with the client, organizing tasks and creating user stories. As the process began being arranged, we switched the methodology to Sprints again since at that moment we had a clear understanding of how everything should work, including the workflow, the schemes, and the transparent and documented deployment process.
Hence, as of April 2022, we successfully organized release management (setting up releases based on sprints), developed clear user story task descriptions, and optimized database which is now ready for the 5.7 version upgrade. Also, we included demo presentations at the end of each sprint so the client could get the full picture of what is being developed during a certain period of time plus provide some edits for the functionalities to be included in the beta release. The cooperation is still ongoing and the development process is in full swing.