Application of scrum in large game teams

When the game encounters scrum
Scrum is not an advanced management method. In the scientific principles of scrum, nothing is worth taking out and put in academic discussions, it also uses the seemingly General poker card estimation method, which is really difficult to climb to the ground. The guiding principles of scrum are very simple. I didn't specify everything in software development in detail. Maybe it can be said that Scrum only elaborated on a very small number of issues, and scrum tolerated chaos, it is even a compromise on chaos. But scrum has succeeded, and has achieved great success in many fields. The reason is that Scrum has grasped the final factor in software development: human management. Unlike the traditional development methods, which focus on the exploration and persistence of the Process, scrum has completely put away the tedious process and re-deployed software development to people. Scrum compromises and confusions are tolerated, without using complicated and advanced management methods, he wants to integrate people into a team and let the team complete the software, rather than let the rules, standards, processes, and documents complete the software.
My scrum and game development management experience comes from my work. My company is a software development and management tool supplier that helps game companies around the world manage their development processes, it also includes Chinese gaming companies. I have been deeply engaged in more than 10 large game companies, all of which have expressed a strong interest in Agile development, I also personally helped several game project teams of some gaming companies practice agile development and have achieved good results.

Earlier this year, I used the scrum master certification granted by the scrum alliance. When I took the certification course, I was deeply reflected on scrum and game development.

Common core values
After reading the scientific principles of scrum and the problems encountered in game project development, we can easily find that there are many problems between them.

Similar value.

Scrum hopes to achieve the most valuable functions in the shortest time, and the same is true for games. The planners will put forward massive demands and will never be able to finish the functions. They will go online at the specified time, this makes the game development team have to add the highest value in the prescribed time.

Scrum embraces changes and does not provide perfect Requirement documents. Instead, it re-examines the product backlog after each sprint, actively accepts changes, and changes the product backlog, to ensure that the most important content can be developed in the next sprint. The same is true for game team development. planners need to constantly adjust game plans based on player feedback, market changes, and other factors. The development team needs to actively deal with planning changes.

Scrum does not have a perfect development plan. In a multi-change environment, no plan can be well executed. If we cannot execute an established plan, we 'd better not develop such a plan, instead, the development work is completed in another way based on the commitment. People who have experience in Game Development know that game development cannot follow the established plan, but it cannot be managed without planning. Scrum officially proposed this non-Plan-driven R & D management method.

The value of many documents in the game is very low, such as functional analysis and design documents. After the product is created, these documents have no value. One function is associated with other functions, they also have detailed records in the planning documents. Therefore, during the development process, we will not look for the methods of document development in traditional software development. Similar to the scrum method of agile development, it also sticks to delivering valuable functions to minimize unnecessary documents, which is exactly the same as the practice of game development.

Games have extremely high requirements on product quality and are generally higher than general software. Traditional development methods, whether it is waterfall or RUP, will always encounter major bugs in the later stages of development, the team is struggling to cope with bugs. For games with high functional coupling, this is almost fatal. Scrum advocates risk Advance and clearly defines the concept of "completion". Each Sprint uses product demonstration and review as the end sign, which plays a key role in improving product quality.

From the above points, scrum's values are exactly the same as those of Game Development Management. Scrum can be applied to game development.

However, after the project managers of the game team read a lot of classical works of agile development and scrum, most of them proposed scrum to advocate weak division of labor and small teams to apply it. In a strong division of labor and a large team of game development projects, has scrum lost its foundation?

The same question is raised:

Scrum means change

Implementation agility, especially the implementation of scrum, means that we need to completely change the traditional, Plan-driven development method. This change not only includes the change in the thinking of project management, the division of the team, the project process, and even the working method must be changed. At the same time, there are two-way changes. Developers must change scrum based on the actual environment of gaming companies. The key to successful implementation of scrum is to make a good transition from traditional to agile. The biggest risk of implementation of scrum is scrum but, which means that although we have implemented scrum, but we did not follow the core requirements of scrum to do things, that is, we did not make a thorough change. Scrum but led to a large number of scrum team attempts failed, and a serious misunderstanding of agile and scrum.

The next article will detail the changes made by the team in using scrum, as well as the starting point and importance of these changes.

Mr. T and his Project Team

Sorry, due to business confidentiality issues, in this article, I cannot describe the actual management methods of any game company I have been using, I can't even use the name or other information of the company or any of them. So in the following article, I will use company T to represent all the game companies I have come across, the company, project, personnel name, and time points used in the following text are fictitious. Do not check them.

T is an online game development and operation company in China. It has its own development and operation team. T has been operating in the game development field for many years and has rich experience in game development. Since last year, company T has been trying to use agile development methods in one of its project groups. Prior to this, company T has been trying to integrate agile factors into its development methods, however, there has been no formal use of pure agile methods.

This project is a new online game R & D project. The project manager is Lao Ji. Although Lao Ji is called Lao Ji, he is not very old and has a deep qualifications. He has been a programmer for a long time, later, I led two game projects and achieved good results. Lao Ji was not a loyal supporter of agile development, the knowledge of agile development is gradually accumulated in the Process of agile practice. But he was happy to accept the benefits of agility and scrum, so with our help, he quickly practiced scrum in his project team and achieved good results.

The following is a story about how scrum is applied in the agile development practices of the old project team of company T. In the following practice, you may find that we have made a lot of changes to the traditional scrum, but we still grasp the core essence of scrum, the scrum team architecture, there are also the most important practical activities of scrum.

 

Define the role of scrum

Scrum no longer contains product managers and project managers in the traditional sense, but uses new roles such as product owner, scrum master, team, and stake holder, when the project team changes from the traditional development model, we need to redefine these new roles.

Team

All teams here refer to the teams in scrum, not the entire game project team. When implementing scrum in game development, the team is the biggest change in the personnel structure.

In traditional scrum, a team is a cross-functional team, which consists of analysis designers, developers, and testers. The division of labor is being weakened, everyone is involved in design, development, and testing. The reason why we can implement this cross-functional team is that in traditional software development, we only write code, text and art pictures, which are just a completely negligible aspect of software, customers will not recognize the same software because of their beautiful texts and beautiful interfaces. They want software functions. Let's look at the various roles in the traditional software team who are dealing with Code directly. The analysts and designers are usually programmers, and the white-box testers also need to write code, this allows the so-called division of labor in traditional projects to be completely broken.

It is quite difficult for game teams, especially large online game teams, to achieve cross-functional teams. Most gaming companies adopt a matrix structure. Based on their functions, they are divided into planning, development, art, testing, and other departments. Based on the project, the game companies are dispatched from each department to form a project team. The planners work on text, while the artists work on 2D and 3D images. They do not deal with the Code. Only the programmers and testers can work on the code. Hypothetical, if we let the planning, artist, program, and test sit together, we will discuss the value size, script actions, planning cases, coding, writing scripts, and drawing models together, it must be crazy. Everyone hopes to find a large number of developers who can plan coding and drawing to develop the game, but the reality is that they cannot find one.

Lao Ji did not find these talents. His staff were also planners, programmers, artists, and testers. The matrix structure made a project team composed of people from different functional departments. Lao Ji is eager to form a large-scale cross-functional team, but found that it is not realistic: The planners are the demand initiators and should be classified as the product owner. The Art Team is a bit like internal outsourcing, regularly feedback completed works. Only programmers and testers can form a team, so Lao Ji formed all developers and testers into his team.

This team can also be cross-functional. The cross-functional here is a small range of cross-functional, compared with traditional development methods. In a traditional game development team, each program is responsible for a specific function module, such as someone responsible for the code of life skills, someone responsible for the chat system, and everyone has a clear division of labor, this is not only the case for programs, but also for testers. For the cross-functional teams of scrum, we hope to break the division of labor between programmers and testers. We hope that all programmers can respond to code with multiple functions and modules, testers can also understand the business logic of multiple modules. In this way, in actual development, team members can help each other, and team members can express their opinions during the evaluation process to deepen their understanding of functions, improve team production efficiency.

In many gaming companies, testers are divided into two categories. One is people sitting with programmers and performing unit tests. Generally, they are called program tests, the other is the personnel who perform functional, system, stress, and integration tests on the server. We are generally called system testers; when organizing a team, you must put both types of testers into the team and work together as part of the team.

Lao Ji's game company represents the organizational structure of the vast majority of game companies. In fact, in almost all of our agile game companies and project teams, both use the same team definition as Lao Ji.

Scrum master

The SCRUM master is the soul of the scrum project. According to the definition in scrum, the scrum master is no longer a leader in execution management skills, but a first assistant to order maintainers, coaches, and team members. To teach scrum knowledge to the team and the product owner and maintain the scrum order, the scrum master must have a high prestige in the entire project team, and even have the ability to allocate testing, art, and planning resources, in company T, Lao Ji is a Senior Project Manager and No. 2 in the project team (No. 1 is a shareholder of the company and does not ask specific project issues ), as a result, old Ji takes the role of scrum master.

When the team size is small (in the initial stage of the project, when there are less than five people), the scrum master will also work part-time for development and other things, when the team began to expand to about 10 people, the scrum master was required to be full-time and to maintain the team with one mind. When the team continues to expand and there are more than 10 people, we need to consider splitting and use the scrum of scrum management form. In the traditional definition of scrum, Scrum of scrum is the bench of the scrum master, there is no scrum master of scrum, but in the game project team, we must have a scrum master that can manage the whole world. He needs to coordinate resources of other departments, they can directly face strong master planners and producers and tell them what the team should do and what should not do. This Scrum of scrum master's final personnel, it is still at the head of a good project manager.

In Scrum of scrum, project members of a sub-team may make some changes in each sprint, but make sure that the scrum master in the sub-team should not change frequently, this is extremely unfavorable for ensuring the development efficiency of the team.

Product owner

In traditional agile projects, the product owner is mostly the responsibility of the original product manager, that is, the person directly responsible for the product. The product owner is responsible for maintaining the product backlog, sorting the product backlog, explaining the product backlog one by one for the team, and answering the team's questions.

According to the simplest ing relationship, the product owner should not be the game owner who plans Mo shujia. He is directly responsible for the game and manages the game requirements. However, gaming projects differ greatly from traditional software projects, and simple ing relationships cannot be established.

Traditional scrum requires that we only have one product owner. for traditional agile projects, there are only 5-9 project members, and the user story can be at most 10 million members, one product owner is sufficient. However, in the development of large-scale online games, when the game is developed to a later stage, thousands of planning documents are frequently generated, and hundreds of pages of documents are rarely described, if you set these planning documents to user story, there will be thousands. If you have a primary planning to maintain this massive product backlog, I am afraid all the primary plans will be scared away. In reality, planners (including the primary policy) are working together to maintain a large planning library.

Therefore, we should take all the planners together as the product owner group. In this group, each planner maintains a part of the game's functional plan, and the main plan serves as the total owner of the product owner group. The product owner group discusses the division of game functions and creates and maintains the game product backlog. At the planning meeting, each plan will explain the backlog entries in charge of the game, help Team members answer questions during team development. During the review meeting after the sprint, all the planners should also participate in the review and give their own comments.

Although we have made great changes in the scope of the product owner, we have not made any changes to the functions of the product owner and the discipline that the product owner should abide. The biggest risk for scrum is that we implemented scrum.

Scrum of scrums

With the development of the game project, the project team will gradually expand. For the project team led by Lao Ji, there were only 10 people, 5 planners, and 4 programs in the first phase, the project team has grown to more than 90 members, nearly 30 planners, nearly 40 programmers and testers, 20 artists and several product team members.

According to our definition of the team, the development team of Lao Ji has reached the size of 40 people in the later stage. With regard to the team size, traditional scrum has always considered 5-9 people as the best scope, and the team is too small, the management cost is too high, and the team is too large, which is not conducive to team communication and reduces team work efficiency. To continue using the scrum method effectively at the scale of 40 teams, the only way is to split the team and adopt the scrum of scrum method.

When the development team is small, if there are no more than 10 people, we can adopt a scrum team management approach, where the project manager is the scrum master. If the team is expanded to more than 10 people, we have to split the team. In fact, it is not difficult to split a team. When the Team expands, it naturally forms a Division. For example, some people are responsible for developing skills and tasks, others are responsible for the development and maintenance of copies, so that we can closely associate the development content with a group of team members. The number of members is limited to around 5-10, in this group, another technical and management capability balanced member is appointed as the scrum master of the group, managing the sub-teams and listening to the project manager.

When we started implementing scrum at company T, Lao ji had only four programmers, who were scrum masters. When the team was expanded to 12 members, Lao Ji split the team into two sub-teams, one dedicated to the help system, four fixed personnel, and one temporary member, lao Ji selected a member who joined the project team as the scrum master of the sub-team. The other seven members form another sub-team, responsible for development work other than the helper system, and still use Lao JI as the scrum master.

In the process of team splitting, the most common problem is to drag teams based on their work functions, such as logical programmers, script programmers, and testers; this is absolutely unacceptable. We have worked hard to reduce the division of labor among our teams and form a cross-functional team. If we were grouping in such a wrong way, wouldn't our work be all in vain?

With the expansion of the old Discipline Team and the progress of the project, the old discipline later split and merged the team several times. The reorganization of the team is carried out between each sprint. Each reorganization is the result of negotiation with the team members, and the scrum master of the sub-team has never been changed. The Scrum of scrum team has been running well since 4th months of the project.

The number of planners accounts for a considerable proportion in the game team. When the Team expands, the planners must also group the team. Traditional planning groups are grouped by game function modules. For example, they are divided into skill groups, replica groups, Camp groups, and task groups. Each group has a leader responsible for managing this group, report the progress to the main planning team. When we adopt the scrum method, the planners should communicate with the scrum team when deciding the group, especially after the team implements Scrum of scrum, should be as consistent as possible with the group of teams. It is best for a group of planners to be able to correspond to a scrum sub-team and form a relatively stable scrum combination, which is conducive to improving the efficiency of the team.

 

In the software development field, changes have always been the biggest headache. Many theories and methods have been put forward for how to eliminate and control changes. Helpless change is like a tough little strong, stubborn to survive with software development for more than half a century. In today's Internet era, not only has it not been suppressed, it is even more rampant. So how do we face changes in Xiaoqiang's most prosperous game circle?

On the whole, the gaming industry (especially the online gaming industry) is passionate and hateful about changes. It is very tangled and painful. Therefore, in the online gaming industry, change management is not a simple laissez-faire or control, but a balance between changes and changes. In a word, the management method is: carrot + great stick policy.

Two opinions of gaming companies on changes
Main change: Planning and producers; viewpoint: changes are the foundation of game survival

Changes are fundamental to the survival of online games. The most important criteria for judging the development momentum of an online game are the number of online players and the update frequency. A game whose update frequency tends to slow down can basically be said to be about to enter its extinction period. Follow the changing tastes of players, lead new trends in the game circle, and create higher gold absorption efficiency. These are all based on constant changes.

Therefore, the game must be changed. If you don't want the game to change, it's just like the game's life. Even limiting changes is equivalent to blocking the survival of the game.

Unchanged School: development team and project manager; viewpoint: changes are a waste and hidden danger

In the end, games are software, stand-alone games, and online games. They are nothing more than software running on computers. Changes are disastrous for software development. All software developers have a deep understanding that changes will lead to a lot of repetitive work and seriously affect the development progress; it will have an impact on all completed work and lead to more unexpected bugs. Unwell-designed changes may even directly threaten the stability of the software architecture, this poses great potential risks for the future. These software problems also apply to game development.

Even worse, frequent changes will make the development team feel a strong sense of frustration. What they have worked so hard to do has not been completely changed in a few days, it feels like you have done a lot of useless things. In the long run, the development team will be frustrated, resulting in low development efficiency.

It seems that contradictions are inevitable. So who exactly listens to it? Listen to the planning, or listen to the development? Judging by the natural laws of natural things: who is strong, who is listening.

Who is better? Planning or program? If I dig a hole here and build a building, I believe it will be quite popular if I invite you to evaluate it.

Implementation proof, planning and procedures are all important.

Which types of changes can be changed? Which cannot be changed?
If we classify game demand changes based on whether changes affect development work, we can divide them into two types: 1. it has a direct impact on the current game development work; 2. it does not directly affect the current game development work.

The current work refers to the work that is being processed by developers, testers, and artists, or to be processed within the current iteration cycle. If a direct impact occurs, it means that the current development work will be interrupted. For example, a game requirement: the player's custom chat channel function. Now this requirement is in the hands of a program, the Code has been written. If a planner initiates a change, it will have a direct impact on the current work. In another case, the demand is still in the planning stage and has not been sent to programmers and art personnel. At this time, the planners initiate a demand change, it does not directly affect the current development task, because no one is developing this function yet.

If we carefully analyze the reasons why programmers oppose the change, we will find that, in fact, programmers only oppose changes that will have a direct impact, but for those changes that will not have a direct impact, it is not very opposed. Changes that do not have a direct impact will have some indirect impact on the existing work, but the impact will not be great. We will discuss this issue later.

Carrots + sticks
Based on the classification method of changes mentioned above, we can get a method for managing changes:

When a requirement (or planning case) is still in the planning stage and has not been sent for development and implementation, we allow this requirement to change, or even allow it to change, there are no restrictions. Once this requirement is sent for development and implementation, we will no longer allow any changes to this requirement, and the demand and design will be locked, developers will follow the locked version for development.

If the planner is unable to propose a change during the development process, he has only two options:

1. Ask the project manager to completely terminate the current development work of the requirement, and cancel the requirement from the current development list. After the requirement change is modified, then, they will be incorporated into the next development plan;

2. After the development is completed, make modifications (as a new requirement) on the basis of the development requirements, and incorporate the changes into the next development plan.

After a requirement is completed, if the planner needs to change the content, then he needs to propose a new requirement called "Modify the custom chat channel ", this requirement is included in the requirement library, and the project manager is required to be included in the subsequent development cycle as a new development task.

Are the above assumptions feasible? Has anyone ever practiced this? The answer is yes. Agile development methodology (both scrum and XP) manages demand changes in this way, and the results of practice are quite good. In addition, some of my gaming companies are using similar methods to manage changes (some of Jinshan's project teams do this and the results are good ). For more information about agile change management, refer to the Agile Project Management with scrum by Ken schwaber)

The above practices basically meet the different requirements of planning and procedures: planning needs to be changed, and development does not need to be changed. Developers should be very satisfied with this method. Since the change is unstoppable, it is acceptable as long as it does not directly affect the current work. But the planners are still upset: cannot be changed during a long development cycle. Is it too inhuman?

Apply the correct development model
Online Game Development should be cyclical. Short iteration cycles of incremental development are relatively good development models. The waterfall model certainly won't work. If companies are developing online games using the waterfall model, alas, they can only wish them all the way. Long-cycle iterations (one period in half a year) are not feasible. This is not a problem in this method, but a long iteration is too painful for this rapidly changing and changing world.

However, in our interview records, we found that many game companies do not have any development models. They are completely chaotic development methods. They buy a ready-made game engine and develop what they think, I feel like I have just launched a package. I didn't use any development model, and there was no clear development cycle. Everything was done with my feeling. This is a very dangerous thing. Many such companies will find that the game production work is in a mess after the game is launched, and no Bureau-level method can provide effective help, in the end, the company entered an endless loop, and the final solution became cruel: either dead or thoroughly reformed.

Any solution to specific software development and management problems must be effective within the framework of the software development model. It is impossible for us to use the planning method in the waterfall model under the agile development model, and we cannot use the card Estimation Method in the waterfall model, because these methods are only available under the framework of a specific development model. Just like the ecosystem, the crocodile in the tropical rain forest cannot survive in the desert. Therefore, if a game company does not even introduce basic development models, do not consider how to manage changes, just as no creature can survive in a vacuum, in an environment without a development model, no development management method can achieve results.

Therefore, this requirement (Planning) Change management method mentioned above must work in the agile development environment. In waterfall and long-cycle iterative development models, will not have any positive effect.

Iteration cycle Selection
The general consensus is that a relatively long sprint iteration cycle can effectively improve the development efficiency. Some tasks in a sprint cycle cannot be omitted, such as backlog sorting, estimation, planning, review, reflection, code integration, testing, and packaging, these activities generally take a lot of time. The longer the sprint cycle, the less time these activities will take, and the more time they will leave for developers, the higher the efficiency.

The shorter the sprint cycle, the faster the response to demand changes. The ability of people to grasp future changes is actually very weak. The shorter the time, the stronger the grasp, and the more detailed the considerations (such as two months later ), there is almost no ability to grasp.

The choice of a sprint cycle is a balance between development efficiency and response speed.

Generally, during the development period, a relatively long sprint cycle will be selected, for example, about 1-2 months. At this time, the planning is relatively clear and no player or operation feedback has been introduced, the demand changes are relatively small. Selecting a relatively long development cycle can ensure the game development efficiency during the development period and strive to reach the launch standard as soon as possible. At this time, we also hope that the planning team can minimize uncertain changes as much as possible. If a function or gameplay cannot be confirmed, it is better than before the change, so do not rashly propose changes, it can save a lot of work after hearing feedback from gamers.

Since the launch of the game beta test, the sprint cycle has been gradually shortened to adapt to the increasing number of bugs, adjustments and changes. After the official operation of the game, generally, the sprint cycle is controlled around 1-3 weeks, which is usually synchronized with the update cycle of the game. From the management point of view, in order to adapt to a shorter sprint cycle, many management rules and processes need to be simplified accordingly to meet the high speed requirements.

 

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/yock_zhang/archive/2010/03/03/5343110.aspx