Features of the development of mobile MMO RTS. Part 6
This is the last article in my series. It will be a lot about the managerial and organizational aspects of development.
My previous articles can be found here:
Part 1
Part 2
Part 3
Part 4
Part 5
')
The market and the players are very demanding on the frequency of updates. Therefore, we will be released once every 3 weeks. Of course, the more often - the better, but you should have all the development processes debugged. In addition, you need to accumulate enough functionality for the release. We have built such a pace thanks to feature teams.
When we started the development of the project, we aimed to ensure that the client developer could take on any task. Then we realized that each employee performs some tasks better and others worse. Lead developer began to assign tasks for specialization. This approach took itself and the QA-team.
After a year and a half of such work, the team began to look like this:
15 programmers;
9 testers;
3 Technical Artists.
We began to notice that this approach also has its drawbacks. Developers have ceased to feel the impact on the project, because they performed monotonous tasks. Professional development also slowed down - rarely had to do atypical tasks. There were some areas of "his" code and the fear of making changes to the code that is supported by another developer. Lida teams spent a lot of time on the distribution of tasks, reviews and consultations.
We decided to radically change the approach to development. We created subcommands capable of solving problems of any complexity. This provided a closed development cycle.
After analyzing the specialization of developers, we have identified the following areas:
After that, we evenly divided the development team into 3 feature-teams. Added an equal amount of QA, one Technical Artist each, changed the workflow in Jira and described the rules for working with this approach.
The project manager distributes among the feature-teams the tasks that have already analyzed and described the project coordinators. They already meet the requirements of the developers. After that, the manager needs to note the tasks that are necessary for the next release. Then - clarify the requirements for the timing, organize by priority and make sure that each team has something to do.
The teams themselves determine who to allocate for the implementation of the task. They themselves decide the need for team activities, conduct testing and code review, giving the finished and tested tasks.
Advantages of the approach:
Disadvantages:
We used to use SVN. He did not deliver any problems and arranged everything if the usual flow was not violated and everyone adhered to common sense. Periodically, there were problems with the merges related to lost revisions. It took quite a lot of time to solve them.
In parallel with the creation of feature-commands, we switched to git and introduced GitFlow. The essence of innovations lies in strict rules for working with branches:
More information about this approach can be found here.
Unity has a problem merging serialized resources. We have it is aggravated by the widespread use of PrefabEvolution. Unfortunately, we could not find a good solution. We try not to work on resources that may conflict. For example, NGUI atlases commit to a stable development branch right away, and it diverges across all the brunches. Because of this, there may be unused graphics in the build until the feature branches are frozen.
My previous articles can be found here:
Part 1
Part 2
Part 3
Part 4
Part 5
')
Development approach
The market and the players are very demanding on the frequency of updates. Therefore, we will be released once every 3 weeks. Of course, the more often - the better, but you should have all the development processes debugged. In addition, you need to accumulate enough functionality for the release. We have built such a pace thanks to feature teams.
When we started the development of the project, we aimed to ensure that the client developer could take on any task. Then we realized that each employee performs some tasks better and others worse. Lead developer began to assign tasks for specialization. This approach took itself and the QA-team.
After a year and a half of such work, the team began to look like this:
15 programmers;
9 testers;
3 Technical Artists.
We began to notice that this approach also has its drawbacks. Developers have ceased to feel the impact on the project, because they performed monotonous tasks. Professional development also slowed down - rarely had to do atypical tasks. There were some areas of "his" code and the fear of making changes to the code that is supported by another developer. Lida teams spent a lot of time on the distribution of tasks, reviews and consultations.
We decided to radically change the approach to development. We created subcommands capable of solving problems of any complexity. This provided a closed development cycle.
After analyzing the specialization of developers, we have identified the following areas:
- server part and client model programming;
- core development - the implementation of gaming functionality and UI;
- integration of third-party libraries and services, work with iOS / Android platforms and various payment systems;
- render-development in Unity - for example, writing shaders.
After that, we evenly divided the development team into 3 feature-teams. Added an equal amount of QA, one Technical Artist each, changed the workflow in Jira and described the rules for working with this approach.
The project manager distributes among the feature-teams the tasks that have already analyzed and described the project coordinators. They already meet the requirements of the developers. After that, the manager needs to note the tasks that are necessary for the next release. Then - clarify the requirements for the timing, organize by priority and make sure that each team has something to do.
The teams themselves determine who to allocate for the implementation of the task. They themselves decide the need for team activities, conduct testing and code review, giving the finished and tested tasks.
Advantages of the approach:
- Developers can try their hand at new tasks. They are helped by guys who specialize in these components.
- Programmers interact more closely with testers and feel better about their impact on the project.
- Leads have more time to work with the team, not with Jira.
Disadvantages:
- The fall in the effectiveness of the team as a whole.
- It is difficult to organize work in Jira, to assess the individual contribution and effectiveness of each developer.
GitFlow development
We used to use SVN. He did not deliver any problems and arranged everything if the usual flow was not violated and everyone adhered to common sense. Periodically, there were problems with the merges related to lost revisions. It took quite a lot of time to solve them.
In parallel with the creation of feature-commands, we switched to git and introduced GitFlow. The essence of innovations lies in strict rules for working with branches:
- branch with stable code;
- branch in which only releases fall;
- several branches for the development of new functionality and hotfixes by version.
More information about this approach can be found here.
Unity has a problem merging serialized resources. We have it is aggravated by the widespread use of PrefabEvolution. Unfortunately, we could not find a good solution. We try not to work on resources that may conflict. For example, NGUI atlases commit to a stable development branch right away, and it diverges across all the brunches. Because of this, there may be unused graphics in the build until the feature branches are frozen.
Source: https://habr.com/ru/post/336254/
All Articles