How We Create Software: Development Process at Cleveroad
Customers always expect more: faster development, innovation, exceptional quality, and first-rate service. To ensure better application performance our Cleveroad team continually improves its business processes, providing a flexible approach to software development.
The seemingly incomprehensible process of software development can be a little frightening and tangled from client's point of view, while experienced developers think it's a piece of cake and don't usually bother to clarify this process to the clients. You will never notice anything like that at Cleveroad. We treat our clients as partners and try our best to make the entire process completely transparent and collaborative. As our client, you will be involved in all stages of the web or mobile development process.
So, let's clear the air about what these stages are and examine the whole mobile applications development process in detail.
Development Process at Cleveroad: How We Create Software
Agile approach to software development
At Cleveroad we stick to basic methodologies in the development process. Splitting software building into different stages with certain activities for the purpose of more effective planning and management is the way that lets us deliver solutions our clients expect. Scrum is a flexible iterative and iteration based development strategy which consists of so-called Sprints the basic unit of development.
Scrum Development Process
What is the role of Sprint in the app development?
In order to understand the mechanics of the software development process, we should get a deeper insight into what a Sprint is and what rules it should follow.
Every Sprint starts on any given working day depending on the availability of the project manager (PM) and after the negotiated start date with the client. The beginning of the week, say Monday or Tuesday, is a perfect time to start. In order to prevent any possible misunderstandings, the agreed date must be included in the contract.
Usually, every Sprint lasts for two weeks. The length of Sprint can be discussed with the client and vary from Sprint to Sprint depending on the tasks and features to be covered.
Take a look at this article if you need more information about Scrum: What Is Agile Methodology For Mobile Development?
Tasks planned for each Sprint can be very different, however, there are basic rules that should be followed.
First of all, here is a list of things that should be done only on the first day of the First Sprint:
- DevOps must configure Continuous Integration and Continuous Delivery for the Project.
Continuous Integration (CI) is a common approach to the development when all working copies are gathered and built to deliver a working product for testing.
Continuous Integration approach
Continuous Delivery (CD) means development in short cycles which ensures the product is ready for the release at any time.
Continuous Delivery approach
Every time a build fails during CI or CD, all stakeholders must be informed about this via email.
- DevOps must provide all necessary credentials to the team members.
- If specification requires to develop a server side backend, DevOps must prepare two examples on their servers:
Besides these must-be-done steps during the first Sprint, there are a few things that all Sprints have in common, and these basics are also essential. So, the following things are done on the first day of any Sprint:
- PM creates tickets in Jira using Jira terms for managing Project Development: Epic, User Story, Task, Sub-Task, Component if they weren't created before (during Sprint Zero for Sprint 1, or during Sprint N for Sprint N+1);
- Quality Assurance Specialist (QA), assigned to the project, starts working on a Test Plan for the Feature List. After its completion, the Test Plan must be approved by the client no later than the middle of Sprint. The client can change Test Plan if needed but all the changes must be agreed with the PM and QA.
Development Stage during each Sprint
The first thing team members must do is to follow Code Convention related to their development environment in order to bring a high level of quality to the project.
Code Convention (or Coding Convention) is a set of guidelines and recommendations that are aimed to ensure software structural quality. This means the team follows a set of rules for a specific language that recommend methods, practices and coding style of a program written in that language. Following these rules helps to improve readability of the source code and simplify software maintenance.
Every time a team member starts working on any task (it can be a sub-task as well), they must enable a time tracking timer. Once they pause development or complete the task, they must stop the time tracking timer.
Testing Stage during each Sprint
Every time the team member completes a feature, he must test it before changing the status of the task to "Ready to Test". If CI Build System can't build a project, or automated tests didn't pass, the team member must fix all issues. He is not allowed to postpone these issues to future Sprints.
You can learn more about testing stage in software development process if you read the article: Testing and Quality Assurance: All You Need to Know
Once the status of the task is changed to "Ready to Test", QA team starts testing the implemented feature. If a bug is found, then the task must be reopened and a new comment with the issue's short description, steps to reproduce, a crash log and/or screenshots must be added.
Creating design in software development process
If specifications require creating design to be created by Designers Team, Sympli service should be used. Sympli is a sophisticated collaboration platform for designers and developers. Here are some basic rules we follow to avoid all possible misunderstandings and make the app development which is followed by creating design run smoothly.
- All screens must be designed following the guidelines of specific platforms (for example, Material Design for Android). This includes proper values of margins, paddings, icons sizes, fonts sizes, etc.
Material Design Layout
- If specific fonts are used in the application, these fonts must be provided to developers (preferably TTF, as OTF must be tested by developers).
- All clickable elements must have a default state, hover/pressed state, and a disabled state. This applies to the element's background and text color.
- Sprites must be provided to web developers manually.
- All screens that display lists must have an empty state.
- If an animation is used on screen, GIF images or frames are required.
- In some cases, information can't be displayed properly due to lack of space.
Learn about the UX techniques our designers apply to make your product look and feel perfect: 6 Quick UX Design Techniques That Really Work
Designers Team should propose a solution for such situations (for example, if the text is so long that it would be truncated, it should be displayed on multiple lines, etc.)
What happens at the final stage of each Sprint?
Note. During the Sprint, it may happen that there is remaining time after all features have been delivered. In this case, PM can request the client to determine additional feature(s) to add to this Sprint. On the other hand, if it is obvious that not all features can be delivered, then PM works with the client to determine which features can be delayed or perhaps split in order to deliver the most value by the Sprint deadline.
At the beginning of the third quarter of the Sprint, QA performs Smoke Testing to find issues in already implemented features: features from Sprint Backlog should be checked first, then the whole system should be checked for integration problems. The results of Smoke Testing are listed in Test Plan.
Preparing a Product Demo
Before displaying a Demo to the client a few important things should be done:
- Team members must implement all planned features from the Sprint Backlog and fix all issues related to them;
- If possible, Regression Tests should be performed to detect any issues related to integration of new features with old ones;
- QA must provide a Test Plan report to the PM with Pass/Failed checks;
- PM must prepare Delivery Reports with information about time that was spent and time that initially was planned.
Delivery Report usually includes:
- features that were implemented;
- features that were planned but weren't completed for different reasons with some explanation of why they weren't finished;
- change requests that were introduced and were implemented during the Sprint;
- change requests that were introduced but weren't executed during the Sprint with the explanation of why they weren't finished;
- known bugs;
- time consumption (including fixing bugs), change requests, and completing on time.
Delivery Report components
Note 2. If the change request affects the main functionality, completely changes it, etc. the Sprint must be stopped for a discussion with the client.
The time required for preparing a demo varies from 2 to 6 hours depending on the release type (intermediate, final, etc.) This time is considered in a Sprint planning.
At the end of Sprint, a demo is shown to the client. They can then test it during some agreed upon amount of time (for example, till the end of working day). In case the client finds any issues, they create a list of issues which will be reviewed by the PM. Then the PM checks and detects any improvements masked as issues. Improvements should be discussed with the client and added to the Project Backlog. Real issues are then added to the Project Backlog, fixed and are not billed.
Team members don't leave their work spaces until the client accepts the Sprint. They have to make hotfixes if the client requires major issues to be fixed ASAP before an application release to Play Google, AppStore, etc. Once the client is satisfied with the results, all project materials noted in the contract (source code, application executables, etc.) are delivered.
Find out more about project delivery process: Successful Project Delivery and How To Control It
I suppose, this detailed and somewhat formal information about app development workflow at Cleveroad will help you understand this complicated process better. Still, if you have any questions left, feel free to ask and get a qualified explanation regarding anything concerning a project that you might have. We will be happy to hear from you!