The author | nine songs netease intellectual enterprise server development

An important goal of agile development is to build the ability to deliver continuous value. This capability must ultimately serve the innovation and success of the business.

Problems faced

In the Internet industry, business often moves at a rapid pace, with constant trial and error. This has very high requirements on the efficiency and flexibility of the R&D team, which faces many problems in the traditional iterative mode, such as:

  • Requirements are coupled and cross – infected online. When a release goes live, it becomes more difficult to locate the problem because of the amount of content that goes live, and it is not possible to determine which requirement change is causing the problem.
  • Temporary adjustment of demand, affecting the whole body. I’m sure you’ve all encountered one day before the release when the product said it had an important requirement that had to be rushed. This temporary requirement adjustment can have a significant impact on release delivery.
  • Delayed the release of the entire version due to an unimportant requirement. On launch day, you may discover that there is a problem with a requirement that is not very important, and the entire release must wait for that problem to be resolved, sometimes leading to a delay in the release or a lot of temporary solutions.
  • The entire team was up and running into the wee hours. Due to the large amount of content delivered by a release, the preparation is long, and the impact is large, the release is usually scheduled in the evening, and as long as there is one or two problems in the release process, the release will usually be late into the morning or even after midnight.
  • Omissions cannot be avoided with checklists. The larger the version, the more content you have, the easier it is to miss.
  • The demands of different values affect each other. A release usually contains requirements of various priorities, and when requirements of different priorities are developed and delivered at the same time, there is bound to be a problem of interaction.
  • The delivery efficiency of the production and research team cannot improve. All the problems finally lead to delivery efficiency, delivery quality.

I believe you also have encountered and we similar to these problems. Many of these problems can be solved by agile delivery.

Agile vs. Iterative

So what is agile? The theoretical knowledge about agile mode and iterative mode, I believe that you have some understanding, here will not elaborate on the theoretical knowledge.

In the iterative mode, the requirements, time and resources of each iteration are determined, and the three factors restrict each other. The biggest advantages are predictability, simple process and fixed time points. At the same time, the problem is the lack of flexibility, the cost of adjusting requirements or time after the release is very high, and the larger the release, the greater the risk and uncertainty. Most r&d teams follow an iterative model. In the agile model, requirements become variables, flexibly adjusting requirements with fixed time and resources to achieve maximum delivery value.

As shown in the figure, in iterative mode, the whole team takes steps to complete the delivery. In the Agile model, a release is broken down into requirements that can be delivered independently within a fixed period of time (iteration cycle), and the high-priority (high-value) requirements are delivered first and delivered by a small, independent team. The biggest advantage is that it is very flexible and can adjust the demand at any time according to the actual situation. Meanwhile, because the delivery unit is limited to the minimum range, the impact range of online release is minimal, the risk is controllable, and the delivery quality can be improved. The goal is to deliver the highest possible value in the shortest possible time.

Pilot it first and then extend it

Before we made the transition to Agile delivery, we did a lot of research and communication, learning from teams inside and outside the company that had already implemented agile delivery. Then I developed a preliminary program and carried out pilot programs in a small scope. During the pilot program, I constantly adjusted the program and debugged the tools. When the pilot program was successfully implemented, it would be promoted to the whole team. At the beginning of mutual customers, is to choose some of the relatively small and simple requirements to carry out the pilot. In the process of transformation, we concluded four important elements: system, specification, tools and organization.

What to prepare

System architecture

First of all, agile delivery requires a research and development environment that can adapt to the agile model, including the proper separation of systems, clear business boundaries, and the ability to isolate the environment for independent development and testing. The ability to smooth publishing, publishing any service at any time should not cause problems because of the publishing action itself. In addition, it is necessary to have perfect monitoring to feed back the anomalies of the system in real time, especially in the early stage of practice, there will always be unexpected situations, and the R&D should be able to know the anomalies of the system in the first time. If the research and development environment itself is still very coupled, the requirements leaders do not know where the impact is. It’s very difficult to implement agile delivery. Without the ability to accurately monitor exceptions, there is a significant risk. Therefore, a sound architecture is the foundation of agile.

The process specification

Then there are the process specifications. From requirements splitting, time planning, code branch management, technical solution review, test report, release review, automated regression. Everyone on the team must follow the process strictly, because the more flexible the solution, the more uncontrollable it means behind it. Therefore, in the initial stage of transformation, it is very necessary to strictly implement the process.

The premise of agile delivery is that requirements must be reasonably disaggregated, and our definition of rationality is that what can be delivered independently is a requirement. If two requirements are coupled, without one, neither can be delivered independently. Then such requirements are unreasonable and should be consolidated into one requirement.

This is a list of requirements for a certain version of the customer, as well as the division of labor, time planning and so on. You can see that most of them are normal requirements, the yellow parts are larger requirements that are not in release, and the red and underlined ones are delayed or cancelled requirements. The delivery of requirements becomes a flexible process.

This is our demand branch management. It is very simple. At the beginning of each demand, an independent demand branch is pulled from the online branch. It is important to always branch from the master to your own feature.

Implementation of the tool

Tools are the bearer of the process, and it is difficult to execute the process without the right tools. Netease’s internal Ovemrind performance platform can well support our process, and with collaboration documents, test case management platform and test automation platform, basically the whole process can be better supported. The screenshot below shows the release sheet for one afternoon, and you can see that there are multiple releases in one afternoon.

Team organization

Finally, we need to adjust the organizational form of the team appropriately according to the logic of agile delivery. The boundary of the original organizational form of the team lies in the function, and all the requirements are transferred between different functions. Finally, the version leader is responsible for delivery and launching. In this mode, people in each functional team can only get access to things within their work scope, so they have different understanding of requirements. When requirements are changed, they are more likely to have resistance, and they will pay a high price when there is adjustment or rework.

On the right is an organization that ADAPTS to agile delivery, where each requirement is handled by an AD hoc virtual team, and the requirement flows only within the team before being delivered online by the requirements leader. In this mode, the boundaries of team organization are no longer functions, but requirements. Virtual team members need to care about the full life cycle of a requirement and better understand the requirement. When requirements change, the impact is much smaller. And often during the solution design process, the r&d and the product will discuss the adjustment requirements.

Whether it’s an environment, a process, or a tool, it ultimately needs to be executed by someone — every member of the team. Therefore, the thinking change of team members is the focus of agile transformation. Before the work is carried out, enough communication should be conducted within the team first, so that everyone can understand the value and significance of transformation and everyone is willing to work for it. When a team agrees on a goal, success is on the way.

What do YOU get

This is the requirement throughput, defect density, both quality and throughput of the past several versions of Mutual customers have been significantly improved.

Of course, I think it’s more important that we get the ability to deliver value consistently and quickly, and get a team that communicates well and trusts each other. In addition, in the agile mode, I will have a better understanding of requirements, focus more on work, naturally pay attention to the whole process of requirements from review to launch, and timely pay attention to my own requirements. For example, a customer’s order is achieved because we have signed up for a data kanban requirement. The value of the requirement will be directly fed back to the team in charge of the requirement, which can make the production and research unify the goal and promote each other, creating a virtuous cycle.

experience

In the process of netease Customer practice agile delivery, we stepped on a lot of pits, and summed up some experience, hoping to help you take a little detours.

  • Don’t obsess over models. Our goal is quality and efficiency, not models
  • Communicate, communicate adequately, and reach an understanding
  • The initial process of transformation should be strictly implemented
  • There must be someone responsible for requirements
  • As far as possible, requirements delivery should not merge operations, which are easy to influence each other and make mistakes
  • QA is not responsible for quality, each requirement team is
  • System observability is important, and the development team needs to know the real-time state of the system

Finally, all r&d teams are expected to maximize value from limited resources.

For more technical content, please pay attention to the wechat public number of netease Smart Enterprise Technology +