The success of the project depends on many factors: a well-chosen team, the correct distribution of tasks, quality feedback from both the customer and the developer, the attitude of specialists, the availability of all the necessary resources and information for working on the project, and even timely payment. It would seem that there are so many conditions, but who cares about their fulfillment? Who conducts the project “by the hand” from the beginning to the release?
Today we are going to talk about project management and project managers. We will take a detailed look at the stages the project goes through and find the answer to the question: “Why it is important to have a professional project manager?”
And before you start reading the article, we advise you to refer to the dictionary with the terms used by the project managers, in order to understand their language.
- Workflow: The sequential steps or stages that must be followed to achieve a specific goal.
- Sprint: A short period of time (usually 1 to 4 weeks) during which the development team focuses on completing a specific number of tasks.
- Epic: It is a significant or large-scale task or several related tasks or functionality that needs to be achieved in the development process. It usually describes a more general goal to be achieved and can be broken down into smaller tasks or subtasks for easier planning and execution.
- Story: An independent task that must be completed as part of the development process. Stories (or user stories) are usually written in the format “as [ user ], I want [functionality], in order to [goal].”
- Sub-task: An extra task that can be related to the main task or story. Subtasks help break more complex tasks into smaller ones, making them more manageable units of work.
- Hotfix: A quick way to fix a bug or problem that is done outside of the normal development and testing cycle. Hotfix is used to solve urgent issues and ensure continuous operation of the system.
- Rollback: The process of rolling back a system or application to a previous stable version. The rollback is performed as necessary to restore the system’s functionality, if the new version of the software causes problems or produces unexpected errors (and if it is not possible to fix with a Hot-Fix).
- Automatic/manual deploy: Deployment refers to the process of installing and running software on a target system or server. Automated deploy means that this process is performed automatically using special tools or scripts, while manual deploy requires human intervention.
- Repository: Centralized storage which gives the ability to store and direct source codes and project files. A repository is often used for version control and for developer collaboration.
- Dev-server: The server environment is used by developers to create and test software. On the dev server, developers can conduct experiments, make changes and check the performance of their applications.
- Staging server: The server used for testing and checking the website before its deployment in the working environment (production). Final checks and bug fixes are performed on the staging server before the application is released.
- Production server: The environment in which the final version of the application or website is deployed and works. A production environment is intended for use by real users and usually has a high level of reliability in the form of uninterrupted operation.
- Release notes: Documentation that contains information about new features, bug fixes, and other changes in each version of the software.
When we made everything clear we can safely move on to the most interesting – the stages that the project goes through
Call with client
A technical call with the client usually takes place after the call with the design team. It means that we already have an approved design and during the technical call we only discuss the development process, what resources the team needs for further work.
Hosting Selection Process
Hosting is the service of providing an Internet resource (website, program, files, etc.) with access to the Internet so that users can access this resource through their browsers or other programs.
The main principle of choosing hosting depends on the complexity of the project and the tasks that this resource should cover, as well as on its reliability and quality of support at a reasonable price.
When we have already chosen the hosting and environment for programming, we can proceed directly to the development process. At this stage, the project manager chooses a work methodology (scrum, waterfall, lean, kanban).
In our company, PMs usually use a mix of methodologies (scrum and kanban), which makes work more efficient.
Next, the project manager allots tasks. Usually, teams work in sprints, the volume of work is formed in epics, which are further divided into story tasks and sub-tasks. But first, the developer performs an estimate of the tasks assigned to him by the PM.
“Backlog” – this status is assigned to a newly created task that is in the plan for the next release. This is a certain “queue” of tasks that have not been completed yet, but are planned to be implemented.
“To do” – the status assigned to a task that is included in the release list. The developer takes the next task to perform from the list of tasks with the status “To do”.
“In progress” – the task is transferred to this status by the developer who started its execution. In this status, one performer can have a maximum of 2 tasks.
“Paused” – the task is transferred to this status if the priorities have changed and a critical task has appeared. The criticality and priority of tasks is determined by the project PM.
“On hold” – the task is transferred to the “On hold” status, if the developer does not have enough data to implement the task, there are delays on the “third party” or the bug is not reproduced, etc. When transferring to this status, the performer must write in the comment the reason why the task goes to “On hold”.
“Code Review”– this status is assigned to a task that has been completed and is ready for review. After review, the task may undergo adjustments or changes if necessary, after which it may move to “In progress” status for further correction.
“Ready for QA”– the task is transferred to this status by the executor, the “Assignee” is also changed to the next responsible person.
“QA Done” – the task is transferred to the “QA Done” status, as a rule, by the tester. This status means that the task has passed verification and is ready for release. When changing the status, you must fill in the “Test cases” block.
“Reject” – the task is usually transferred to this status by the tester. This status means that the task has not passed the check and required revision. When changing the status, you must fill in the “Test cases” block.
“Done” – the task is transferred to this status exclusively by the project manager. It means that the task is done, the release to the PROD-server has been completed and it can be closed.
Each sprint ends with a finished functionality that can be shown to the client. This is also the responsibility of the project manager. After the demonstration, the PM makes release notes and a report, which he submits to the client along with an invoice for payment.
The development process also includes covering the code with unit tests. This process is carried out to ensure that the code meets the architecture requirements and has the expected behavior.
The main reason for writing unit tests is to test individual modules. Since each module is written separately, it can also be tested in isolation, without connection to others. In this way, a simple scheme is obtained: the developer wrote the module → tested it → continued development for communication with other modules and other tests.
If you skip the unit-testing stage, it will not be possible to understand what exactly caused the error at later stages. You will have to figure it out, spend time and still test individual units.
Unit testing is an important stage of work that takes a lot of time. A specialist can conduct testing both manually and automate this process, for example, involve artificial intelligence tools in the testing process. Read more Will AI Replace Your Workers?
Automatic / manual deployment
When we have a live product, we want it to work accurately and when it updates, users should not meet with errors in the operation of the system.
In order to ensure uninterrupted releases of new versions of the product, you need to pay attention to the method of deployment and application of the new code base on servers, whether automatic or manual. It is better to use manual deploy only on the Prod-server, instead, automatic deploy is more suitable for processes on Dev- and Stage-servers.
It is worth remembering that the development process at many stages is unique and requires the attention of specialists, so that everything works perfectly.
After the code is written and tested, it must be checked for quality. There are two ways the development team can do this.
The first option (solo review) – one chosen person who independently reviews the written codes and gives feedback (the task goes further along the flow or is returned for revision).
The second option (cross review) – developers check each other’s work, and the form of feedback remains unchanged (the task goes further along the flow or is returned for revision).
All processes go not only step by step but also across. That is, when a certain functionality was written, it was immediately covered with unit tests, checked for quality, then for the accuracy of tasks in different environments. Such thorough checking reduces the risk of errors in the product release itself.
However, there are cases when everything went according to plan, but the system gives an error on the release. For such cases, the developers also have a plan: Hot-fix or Rollback. The fundamental difference lies in the speed and the environment that is used to correct the error.
A Hot-fix is a small piece of code generated to fix a major software bug or system malfunction quickly. Rollback, in turn, solves more complex errors. After Rollback, the system returns to the last stable state.
All Hot-fix changes are made in Hot-Fix repository or directly to the Stage-server (intermediate server for testing before publication), by passing the Dev-server, then changes made at this level must be duplicated to lower levels.
The purpose of duplicating changes to lower levels is to ensure synchronicity and consistency between development and test environments. This ensures that all changes made at intermediate levels are reflected and available for further development and testing at lower levels.
Release ver. 1.2.5
We will add more interesting information at the end and tell why the release is marked with three numbers.
Release versions are usually changed according to a certain principle, which may differ depending on the version control scheme chosen by the development team. However, the most common practice is to use three numbers in the format “major.minor.patch”.
Here’s how these numbers are usually interpreted:
- Major: This is the number that changes when a major version of the product is released with significant changes and new features.
- Minor: This is a number that increases when a new version of the product is released with minor functional improvements or changes that do not significantly change the operation or compatibility with previous versions.
- Patch: This is a number that is incremented when bug fixes or small updates are released that do not introduce new features or changes to existing functionality.
So, in the example “Release ver. 1.2.5” the major version is 1, the minor version is 2, and the patch number is 5. This may indicate that this is the second major update of the product with some functional changes and patch five errors.
As you already understood, the role of the PM is very responsible. They make sure that his team has everything they need, from information on the project to all the necessary technical aspects of work. The work of a project manager is about people and their interaction. And high-quality interaction is the key to the success of the project.
We are proud that Cadabra Studio employs truly professional and qualified project managers who build strong relationships between the team and the client.
Do you feel like you’re ready to entrust the project to our project manager’s hand? Then Contact Us, and we bring your dream to reality.