The maintenance process, like the development process, consists of a sequence of milestones. Each milestone ends with the release of the next version of the program. Only, unlike the versions released at the development stage, the versions of the application delivered at the maintenance stage can be fully used in work.
Conditionally, the maintenance process can be represented by a sequence of alpha versions, which ends with the release of the beta version, and then the final version.
Only in real life, it never comes to the release of the final version. The practice of using the application makes its own adjustments, and customers make more and more new requirements for the application, which are implemented during the next milestone. Perhaps in the future we will think about a numbering system for product versions, but this is not required yet.
Milestone
The duration of the milestone at the maintenance stage is usually 3-4 weeks. This is less than the average duration of the milestone during the development phase. This is explained by a decrease in the number of tasks that need to be implemented. This is understandable, since the main functionality was implemented during development.
Tasks that are performed during the maintenance stage can be conditionally attributed to one of two types:
- Removing barriers
- Expanding functionality
- Removing barriers
One of the important goals that we pursue at the maintenance stage is to make the tool extremely user—friendly. To achieve this goal, we try to eliminate all obstacles that interfere with normal use.
How do we identify such obstacles? We just give the version of the application to customers and ask them to work with it in the field. Based on the results of the work, we ask:
- What’s in the way?
- What is annoying?
- What is missing?
We analyze the received answers and develop solutions that eliminate the problems.
Expanding functionality
The experience of using the application in real activity allows you to prioritize requirements that have not yet been implemented. If, reasoning abstractly, in isolation from real practice, customers tend to fantasize or request features that they have spied somewhere, then with regular work with the application, it immediately becomes clear what is missing right now, and what can wait.
The experience of real use of the application allows you to formulate new requirements and re-evaluate existing ones.
Conclusion
The article discusses the development process in the game studio’s toolkit department. The proposed process has been applied for two years. He helped to significantly improve the quality of the developed tools. From the “knee” software, it was possible to move on to the development of programs that have a professional look.
During this time, the department has developed 2 serious applications: one for visual effects designers, and the other for 3D animators. The first application is already actively used in the development of the game and has received positive feedback from users. It also made it possible to abandon the previously used third-party application and, thus, save money on paying for the license. The second application was released recently and is currently being actively implemented in the development of the game.
In two years, the department has grown by 2 times: from two programmers and the 1st quality engineer, who worked on the project only from time to time, to 4 programmers and the 1st quality engineer full-time. With the current process, the department has the potential to grow up to 6-7 programmers. With further growth beyond this number of developers, it is likely that changes in the process associated with greater formalization will be required.