The author | nine songs netease intellectual enterprise server development

An important goal of agile development is to build the ability to deliver continuous value. Ultimately, this capability must serve business innovation and contribute to business success.

Problems Facing

In the Internet industry, business often evolves rapidly and with a lot of trial and error. This has a very high requirement for the efficiency and flexibility of the research and development team, which faces many problems in the traditional iterative mode, such as:

  • Requirements are coupled to each other and the line is cross-infected. When there is a problem with a release coming online, with so much going online, it becomes more difficult to pinpoint which requirement change is causing the problem.
  • Temporary adjustment of demand, affecting the whole body. Everyone should have come across the version of the day before the launch, the product said that there is a very important demand must be urgent, not on the line. This temporary requirement adjustment has a significant impact on the delivery of the version.
  • Delayed the launch of the entire release due to a minor requirement. On the day of launch, you may find that there is a problem with a requirement that is not very important, and the whole version must wait for this problem to be solved, which sometimes leads to a delay in the release or a lot of temporary solutions.
  • The whole team launched into the wee hours of the morning. Due to the amount of content delivered, the preparation is long, and the impact is large, the release is usually scheduled in the evening, and as long as there are one or two problems during the release, the release is usually late in the morning or even late in the night.
  • There is still a checklist can not avoid omissions. It is also the case that the larger the version, the more content, the easier it is to omit.
  • The needs of different values affect each other. Multiple priority requirements are often included in a release, and when different priority requirements are being developed and delivered at the same time, there is bound to be interaction issues.
  • Production and research team delivery efficiency is not good. All problems eventually lead to delivery efficiency, delivery quality is not good.

I believe you have encountered similar problems as we have. There are many problems that can be solved with agile delivery.

Agile vs. Iteration

So what is Agile? I believe that we all have some understanding of the Agile model and the iterative model, and I will not elaborate on the theoretical knowledge here.

In the iterative mode, the demand, time and resources of each iteration are determined, and the three factors restrict each other. The biggest advantage is predictability, simple process, fixed time point. But at the same time, the problem is lack of flexibility. After entering the version, the cost of adjusting the demand or time will be very large, and the bigger the version, the greater the risk and uncertainty will be. Most development teams use an iterative model. In Agile, requirements become variables, flexibly adjusting requirements to maximize deliverable value with fixed time and resources.

As shown in the figure, in the iterative mode, the whole team executes step by step and finally delivers in full volume. In the Agile model, a release is broken down into separate requirements that can be delivered to the market in a fixed time frame (iteration cycle), with higher priority (high value) requirements delivered first, and delivered by small, independent teams. The biggest advantage is that it is very flexible and can adjust the requirements at any time according to the actual situation. At the same time, because the delivery unit is limited to the minimum scope, the impact scope of the online launch is minimal, the risk is controllable, and the delivery quality can also be improved. The goal is to deliver the highest possible value in the shortest possible time.

Pilot first and then promote

Before we made the Agile Delivery transition, we did a lot of research and communication to learn from teams inside and outside the company that had already implemented Agile Delivery. Then I developed a preliminary plan and carried out a pilot program in a small scope. During the pilot process, I constantly adjusted the plan and debugged the tools. When the pilot program was successfully implemented, it would be promoted to the whole team. At the very beginning, we chose some small and simple requirements to pilot. In the process of transformation, we have identified four important elements: systems, norms, tools, and organizations.

What do you need to prepare

System architecture

First and foremost, agile delivery requires a development environment that can adapt to the agile model, including a reasonable separation of systems, a well-defined business, and the ability to isolate the environment for independent development and testing. To have the ability to smooth publication, publishing any service at any time should not cause problems because of the publishing action itself. In addition, perfect monitoring is needed to provide real-time feedback on the abnormalities of the system. Especially, there will always be accidents in the early stage of practice, so the research and development should be able to know the abnormalities of the system in the first time. If the R&D environment itself is still very coupled, affecting the whole situation, the requirements responsible person does not know where the scope of influence. It is very difficult to achieve agile delivery. Without accurate anomaly monitoring capabilities, there are significant risks. So a sound architecture is the foundation of Agile.

The process specification

Then there is the process specification. From requirements splitting, time planning, code branch management, technical proposal 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 is. So at the beginning of the transition, it is very necessary to strictly implement the process.

The premise of agile delivery is that requirements must be reasonably split, and our definition of reasonable is that a requirement that can be delivered online independently is called a requirement. If two requirements are coupled to each other, the other requirement cannot be delivered independently without one. Then such requirements are unreasonable and should be consolidated into one requirement.

This is the requirement list of each other for a version, as well as the division of labor, schedule and so on. It can be seen that most of them are normal demands, the yellow part is the large demands that do not conform to the version, and the red and underlined ones are the postponement or cancellation demands. The delivery of requirements becomes a flexible process.

This is our demand branch management, which is very simple. At the beginning of each demand, an independent demand branch is pulled from the online branch. When the demand environment is tested and passed, it is merged into the grayscale branch. It is important to always go from the master and the latest code to your own feature branch.

Implementation of the tool

Tools are the bearer of the process, and it is difficult to execute the process without proper tools. Netease’s internal Ovemrind performance platform can support our process very well, with collaboration documentation, test case management platform and test automation platform, basically can support the whole process very well. The screenshot below shows the release list for a single 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 agile delivery logic. The original organizational form of the team is bounded by functions, all requirements are transferred between functions, and finally the release owner is responsible for delivering online. In this mode, people in each functional team can only get in touch with things within their work scope, so they have different understanding of requirements. When requirements change, they are more likely to resist, and they will pay a great price when there is adjustment or rework.

On the right is an organization that ADAPTS to agile delivery, where each requirement is addressed by a temporary virtual group, and the requirements are only circulated within this group before being delivered online by the requirements owner. In this mode, the boundaries of the team organization are no longer functions, but requirements. Members of a virtual team need to be concerned with the full lifecycle of a requirement and have a better understanding of the requirements. When requirements change, the scope of impact is much smaller. And it is usually during the solution design process that the R&D and the product discuss and adjust the requirements.

Whether it’s the environment, the process, or the tools, it will all end up being implemented by a human being, that is, every member of the team. Therefore, the thinking change of team members is the key point of agile transformation. Before the work starts, there should be enough communication within the team to make everyone understand the value and significance of transformation and make everyone willing to work hard for it. When the team agrees on a goal, success is not far away.

What do you get

This is the demand throughput, defect density, quality and throughput of the last few versions of the intercustomer has been significantly improved.

Of course, I think what’s more important is that we get the ability to deliver value consistently and quickly, and we get teams that communicate well and trust each other. In addition, from the perspective of my personal feeling about requirements, under the agile mode, I will have a better understanding of requirements, and work will become more focused. I will naturally pay attention to the whole process from the review to the launch of requirements, and timely pay attention to the situation of my own needs. For example, the order of a customer is because we have a demand on a data Kanban. The value of the demand will be intuitively fed back to the team in charge of the demand, which can make the production and research unify the goal, promote each other, and create a virtuous cycle.

experience

We’ve stumbled a lot in the process of agile delivery for netease customers, and we’ve learned a few lessons that we hope will help you avoid a few detours.

  • Don’t go for patterns. The goal is quality and efficiency, not patterns
  • Communicate, fully communicate, and reach a consensus of understanding
  • The initial process of transformation should be strictly implemented
  • Demand must be responsible
  • Requirements delivery as far as possible do not merge operations, easy to influence each other error
  • QA is not responsible for quality, it is the individual requirements team
  • The observability of the system is very important, and the development team needs to know the real-time status of the system

Finally, all R&D teams are expected to maximize the value of their limited resources.

More technical dry goods, welcome to pay attention to “netease intelligent enterprise technology +” WeChat public number