Note: This article is a collation of the content shared by he Mian in yunqi conference. With slight deletion, click the link below to view the full view
Cloud bizdevops Forum:https://yunqi.aliyun.com/2021/agenda/session173
“R & D efficiency” has been a hot word in recent years, and many organizations will launch special projects to improve R & D efficiency. I have had in-depth exchanges with many of them. Not many of them have reached the ultimate goal. They often start with a high profile and finish hastily. Why is this so?
To improve R & D efficiency, we should first find out what the problem to be solved is, and then the practical method to solve the problem. Otherwise, if the problem is not clearly defined, it will be difficult to have good results.
What problems should be solved to improve R & D efficiency?
I summarize the problems to be solved in improving efficiency as follows:Three efficiency inequalities.
Three inequalities reveal the essence of R & D Efficiency
The first inequality, local efficiency is not equal to efficient delivery?
Everyone should feel this. When we ask various departments or individuals, we all feel thatThey are busy and efficient. However, when we ask business departments or users, it is another matter. They will complain about slow response to product development, late delivery and poor quality.
This is that the local efficiency of the internal perspective of the organization is not equal to the efficient delivery of the user perspective. This is the primary problem to face in improving R & D efficiency. Solving it requires more effective organizational coordination, more reasonable delivery mode and better process quality.
The next question is, is efficient delivery enough? This leads to the second efficiency inequality.
The second inequality is that efficient delivery is not equal to continuous efficiency
Sometimes, for efficient delivery, we can take temporary actions, such as locking a group of people together and setting up a temporary project. In this way, communication and cooperation will be more convenient, which may achieve temporary efficiency. However, if we lack long-term quality thinking, when we are working on the next project, we often find problems. There are various problems in the previous code and design, such as poor modifiability and reusability. They become liabilities rather than assets of subsequent projects, and the long-term efficiency cannot be maintained.
How to change from efficient delivery to continuous efficiency is the second problem to be solved in R & D efficiency. It puts forward requirements for our engineering and technical ability and practice.
The third inequality is that efficient delivery is not equal to business success
The purpose of product delivery is to support business development and business innovation. We must ensure that what we deliver can solve user problems and build a sustainable business model, otherwise there is no point in delivering more.
Today, the uncertainty of the market and users continues to increase, so it is not easy to solve this problem. It requires the whole organization to focus on user problems, fast delivery and trial and error, and form a closed loop of effective feedback and adjustment. Only by doing these three points can efficient delivery be transformed into business success, which is the third core problem to be solved to improve R & D efficiency.
We believe that the essence of improving R & D efficiency is to solve the above three inequalities, so as to transform the local efficiency within the organization into efficient delivery perceived by users, and ensure continuous efficiency and business success. Final realization:“Continuous smooth and high-quality delivery of effective value”. This is the fundamental goal of efficiency improvement.
Practice system for improving R & D Efficiency
Identifying problems is the beginning, and solving them requires a systematic practical approach. Next, we share these practical methods, which are the refinement and summary of our past practice, and summarized as this figure.
The whole diagram is divided into three modules:
On the left is collaboration and requirements practice.At the top left, we call it business driven demand collaboration mode and product oriented interaction mode. At the bottom, we call it end-to-end demand analysis and design. This part of the practice on the left solves how local efficiency leads to efficient delivery.
On the right is engineering and technical practice。 On the top right, we call it Domain Driven Architecture and implementation. In the middle is standardized engineering infrastructure. Below is application-centered continuous delivery. The problem solved in this part of practice is how to make our efficient delivery bring sustainability.
The middle part is innovative practice。 It includes: how to efficiently explore the business, how to continuously and quickly complete the business delivery, and form a closed loop of effective feedback and adjustment. How to deliver business efficiently is the key to success.
Next, let’s take a step-by-step look at the key performance improvement practices of each part.
Collaboration and requirements practice
First, let’s look at collaboration requirements practice.
Before introducing collaboration, we need to understand the context of collaboration – that is, what we are talking about when we talk about collaboration.
Let’s start by combing the internal structure of requirements delivery.
First of all, product delivery is derived from the goal, which may be the user goal, such as: completing a work more efficiently; It may also be business objectives, such as achieving business growth and improving user stickiness. We plan business requirements based on user goals and business goals. In addition to business objectives, the specific demands of customers will also be transformed into business needs.
The realization of business requirements needs to be implemented into products, which will be decomposed into product requirements one by one. Product requirements will be further decomposed into technical tasks. Product requirements will be delivered through the realization of technical tasks, and finally the corresponding business requirements will be realized.
Of course, product requirements do not necessarily come directly from business requirements. Products will also make their own plans, including architecture upgrading and technology reconstruction, or future oriented forward-looking technology layout, such as AI algorithm, blockchain platform, etc. Although this part of product demand does not come from the current business demand, it also serves the business goal, but is only the long-term and future business goal.
After understanding the structure of product delivery, let’s look at how to realize the efficient collaboration of the team under this structure.
Business driven collaboration model
First, our collaboration structure should be consistent with the previous product delivery requirements hierarchy. Business requirements, product requirements and technical tasks are the responsibility of people with different functions. For example, business personnel are responsible for creating business requirements, and business personnel and product managers work together to decompose business requirements planning into product requirements.
Business requirements, product requirements and technical tasks are the basic value units in the process of delivering requirements. Documents, code, tests, data, etc. serve them, and should be associated with them and precipitated into assets.
Business needs to be collected, managed, planned and delivered. There needs to be an independent space to complete these tasks, which corresponds to the “business space” in the R & D collaboration tool. In the business space, you can also see how business requirements are divided into product requirements. We call it the management layer, and we should also look down to the next layer, so as to ensure the delivery of business requirements.
Business requirements delivery is a dynamic process, which requires a clear workflow. It defines the whole process of business requirements from proposing, receiving, planning to publishing and acceptance. Smooth and high-quality delivery is to make the workflow smoother and reduce obstacles and waiting in the process.
Like business requirements, product requirements also need to be collected, managed, planned and delivered. R & D management tools should also provide exclusive product delivery space for product personnel and define the workflow of product delivery.Technology developers also need a workbench that is friendly to them.Here, they accept, manage, plan and complete technical work.
More importantly, we need to turn these three levels into an organic whole, so that we can really work together to deliver business needs smoothly. These three levels of workflow are interrelated. After business requirements planning, they are divided into product requirements, and product requirements will be further divided into tasks. These are top-down.
Look at the bottom-up. After the work at the lower level is completed, its state should be able to be convoluted automatically. For example, after all the tasks under the product requirements are completed, the corresponding product requirements enter the state to be tested. After all product requirements of business requirements are completed, the status of business requirements also needs to be changed automatically.
The linkage and transparency of these three levels make it easier to identify problems and obstacles. For example, when there is a delay in the delivery of business requirements or a problem, you can clearly see which product is causing it and where actions should be taken.
We call this a business driven collaboration model. Different functions and teams in the organization must cooperate with each other to complete business delivery and achieve the goals of users or business. The business driven cooperation mode makes this process more transparent and efficient.
Product oriented delivery model
What I mentioned earlier is the cooperation mode. The business needs of the enterprise should finally be delivered to the product delivery team. In the past, we regarded it delivery team as a cost center, first determining the scope of demand, then determining the time, and then allocating resources, establishing projects and completing delivery. This is also known as project oriented delivery mode.
The essence of project oriented delivery is to allocate people as resources to things. The assumption behind it is that the future is certain and the determined content will be delivered within a certain time. It emphasizes planning and execution and pursues deliveryCertainty of.
Certainty has become increasingly unrealistic today, and organizations must learn to dance with change. In addition, project oriented delivery leads to short-term thinking and lack of awareness of long-term improvement of engineering and technology. At the same time, due to the temporary nature of the team, the delivery efficiency of the team cannot be sustained.
In the digital age, we need to move from project oriented delivery mode to product oriented delivery mode. The essence of product oriented delivery mode is to hand things over to the cross functional feature team, and the relatively stable feature team will continue to accept and complete the delivery of requirements.
The feature team is responsible for the iteration of the product. They embrace the uncertainty of the business and continuously evolve the product for this purpose. To maintain products, the feature team must establish long-term thinking, pay attention to code assets and engineering assets, and continuously improve the team’s delivery ability and delivery process to improve delivery efficiency.
But this is not enough, because if each product goes its own way, the demand overload of any feature team will make it a bottleneck of the whole business. The solution is that multiple feature teams in the same business field share the same demand list. This allows one team to allocate requirements to another team when there is a resource bottleneck, which is consistent with the essence of “one queue with multiple service windows” implemented in many service industries today.
End to end requirements analysis and design
As we mentioned earlier, the enterprise collaboration mode should be business driven and the team delivery mode should be product oriented. They solve the problem of collaborative process, but the process alone is not enough. We must also ensure the quality of input.
There is a famous saying in the IT industry: “what is input is garbage, and what is output will also be garbage”. The input of demand is the delivery process, the source and the most critical part. If there is a problem with the input, the intermediate process of delivery cannot be smooth. What should we do?
The opposite of “input garbage, output garbage” is to start with the end – that is, when the requirements are input, the team should know what to make in the end and reach an agreement between business, products and technology.
So, how can we start with the end? Starting from the end, it is divided into three aspects:
First,For business requirements, we should have clear business objectives and define clear business processes based on the objectives to ensure that the business processes can support the realization of business objectives, which is the work of business analysis.
Second,For product requirements, it should be able to support the realization of business processes. Therefore, we should clearly define the functions of products based on business processes. For each product function, we should first clarify the interactive process used by users, and clarify the acceptance criteria based on the interactive process.
Third,Clarify the structure between business requirements and product requirements, that is, the hierarchical relationship between business requirements and product requirements. This is very important for the later team collaboration. The goal of our collaborative delivery is not product requirements, but business requirements. Only when the structure is clear and the collaboration is, can we know how to align these product requirements to the business and complete the rapid delivery of business requirements.
To sum up, business analysis and product design are divided into a pyramid structure:
Requirements always come from business objectives. Analyze business processes based on business objectives, decompose product requirements based on business processes, and design product requirements.
The upper two floors of the pyramid: it is the focus of business analysis. We introduce the “event driven analysis” method, which analyzes business processes based on objectives and business events, defines product requirements based on business process splitting, and divides the minimum feasible products (MVP).
The lower two floors of the pyramid: is the focus of product design. On the basis of business process design, decompose the product requirements and clarify the product requirements. The best way to clarify and design requirements is to use user examples to illustrate the operation process and acceptance rules, that is, under what circumstances, what operations the user will do and what results will be obtained. We introduce the “instantiation requirements” analysis method to support this process.
Through systematic business analysis and product design methods, the requirements are transformed from GIGO to the beginning, which is an important link from local efficiency to efficient delivery.
Next, let’s explain the collaboration and requirement practice from another dimension. Taking the product screenshot in the above figure as an example, let’s summarize the three points we should do in the collaboration part:
First, we should see and manage the delivery process of end-to-end business requirements, which we call the front and back function connection. These functions may be business, product, development, testing, deployment and operation and maintenance. We need to get through these functions, make them cooperate more efficiently, and make the business needs flow and deliver smoothly from left to right.
Second, align the left and right modules. A business requirement may be decomposed into different products. Each product has its own workflow, and the delivery of products should be aligned with the delivery of business.
Our goal is not to make a product busy, but to make the delivery of business requirements smoother. Therefore, all products should be aligned with the delivery of business requirements. This should also be achieved in R & D management tools, including aligning products and business requirements in planning, aligning products and businesses in the implementation process, and immediately finding obstacles and waiting caused by failure to align.
Third, the quality of the built-in process. Requirements should have clear quality standards at each stage and be implemented in place. For example, the quality of requirements input should start from the end, and there should be clear standards for the quality of requirements testing and test transfer and release. Quality should be based on each stage of each requirement, rather than relying on the final testing stage in batches.
We should make the front and rear functions connected, align the left and right modules, and improve the quality of the built-in process. Finally, the cooperation mode shown in the figure below is formed.
Each node in the figure is a specific activity. These activities have its rhythm, person in charge, input and output, as well as the support of practical methods, such as event driven business analysis and instantiation requirements mentioned above, so as to truly form a whole of business, products and technology and deliver business requirements smoothly and with high quality.
Technology and engineering practice
In terms of technology and engineering, what problems should we solve? Let’s look at a picture first.
In the figure above, the horizontal axis is time and the vertical axis is production efficiency. We hope that efficiency will go up along the green line, but in reality, with the passage of time, the products will become complex and the team size will become larger, but the efficiency will decrease.
The core of distinguishing these two lines is that in engineering and technical practice, it determines whether we accumulate assets or debts, and ultimately determines the long-term efficiency.
Domain Driven Architecture and Implementation
In terms of technology, we should continue to accumulate and maintain domain assets to make them easy to understand, expand, maintain and reuse. Today, the industry generally recognizes the importance of Domain Driven Design and is willing to invest energy. However, it is not easy for domain driven design to work.
Domain driven design is not only a design problem, but also a system engineering involving requirements, architecture and implementation. Demand and business are the source, architecture is the hub, and they all need to be implemented into reality. The most important thing is how to really connect requirements, architecture and practice. What connects them is the domain model.
As shown in the figure above, we analyze business processes from business requirements, decompose and design product requirements based on business processes, define acceptance tests through instantiation requirements, and clarify and refine product requirements. More importantly, in the whole stage of requirement analysis, we should constantly extract and refine the domain model. Because the understanding and abstraction of the domain comes from each specific business and specific requirements, it is called “business led domain modeling”.
Domain model should be the basis of application architecture design. We divide the sub domain based on the domain model, set the context of the sub domain, define the design contract of the interface based on the domain model, divide the sub domain and bound the context, and restrict the boundary of the micro service to make the micro service a reusable domain asset. Bounded context and service contract ultimately guarantee the reusability of domain assets. So we call it “domain leading micro service architecture”.
In terms of implementation, domain model, acceptance test and service design contract are the constraints and guidance of high-quality code. Our code should reflect the domain model, be consistent with the architecture and interface contract, and comply with relevant acceptance standards.
At the same time, the test first approach allows us to have more reliable automated testing, and automated testing will make our reconstruction more secure. Continuous refactoring ensures that the code assets will not decay rapidly and maintain the health of the system.
Today, I still share more at the conceptual level, but I hope I can inspire you in thinking and planning. Unless you think you can sacrifice long-term quality and you don’t need to accumulate a long-term repeatable asset, these are indispensable.
Standardized engineering infrastructure
Next, let’s look at the engineering part. Fortunately today, we see that the technical trend of the engineering part is converging.
We can see that it has become a fact to manage and distribute products based on containers and arrange environmental resources based on k8s. Everyone no longer considers whether to do it, but when or how to do it. This direction probably won’t change. But the problem is that when we talk about containers, we still look at them from the perspective of resources, that is, from the perspective of operation and maintenance, but from the perspective of development, we see the code, and the code corresponds to the application. If only this is done, there is still a gap between development and operation and maintenance, and the objects they face are different.
Another trend we see today is to do application management based on OAM standards. The standard of OAM is an open application model jointly proposed by Alibaba and Microsoft. Based on OAM, you can manage the development, arrangement, operation and maintenance of applications. OAM is a standard. Based on this standard, developers can declaratively arrange applications, and operation and maintenance can also carry out automatic operation and maintenance based on existing declarations.
OAM is the final state of application-oriented deployment and operation and maintenance, which unifies the basic model of application development and operation and maintenance. Firstly, it puts forward the basic model of application description, including application topology, resource dependence, deployment mode, operation and maintenance mode, and then defines the declarative application arrangement, deployment and operation and maintenance mode. Based on application, OAM unifies the basic language of development, operation and maintenance, makes applications the basic object of common concern and operation of development, operation and maintenance, solves the problem of basic technical implementation, and makes real Devops possible.
However, this is still a little short of the real Devops. What we just said is that we have the foundation of Devops. We are based on such standards from the deployment stage, but we have not defined how our applications are delivered. If the application and delivery are included, the real Devops will be realized.
Let’s look at such a diagram, as shown in the figure below. We define the applied change process in this way
First, we should decouple deployment and release. Deployment is a technical behavior and release is a business behavior. We hope that each application can be deployed separately, so we need to decouple deployment and release, and take the application as the unit for continuous integration and deployment.
But that’s not enough. Where do the applied changes come from? Applications come from business requirements. Business requirements are disassembled into product requirements, which correspond to changes in a series of applications.
Each application change has its own process. After the deployment of all application changes corresponding to this business requirement is completed, the business requirement should also be able to complete the release.
Our tools, processes and operations should be able to connect the changes and product requirements of these applications to the business requirements. In this way, we can release business requirements as a unit – when all changes under a business requirement are deployed, the business requirement can be released at any time.
We believe that the best form of continuous delivery is to change and deploy in a single application, and release when needed. On this basis, we have the opportunity to establish the fastest business closed loop.
The above is the form of cloud native continuous delivery, that is, continuous deployment with application as the unit and continuous release with business as the demand unit. The premise is that we unify the basic units of development, operation and maintenance with application.
To sum up,What do we think is the form of bizdevops born in Yunyuan?There are three points:
- Facing the end state, based on the open application model OAM, form the consistency and standardization of the underlying model of operation and maintenance and development.
- Take the application as the core, connect the development, integration, deployment, operation and maintenance of the application, and realize Devops in the cloud native era.
- Connect and align business requirements and application changes, improve the feedback closed loop, and realize bizdevops in the real sense.
To improve efficiency, we must start with a clear definition of the problem.
I summarize the fundamental problems to be solved to improve R & D efficiency into three efficiency inequalities. Resolving these three efficiency inequalities requires systematic practice.
First,Turn local efficiency into efficient delivery. Therefore, we need to implement the business driven cooperation mode and product-oriented delivery, and truly start from the end in terms of demand.
Second,To make efficient delivery sustainable, we should technically achieve Domain Driven Architecture and implementation, and continuously accumulate and optimize domain technology assets. In terms of engineering, we should build cloud native standardized infrastructure,The application center is used to get through the needs of development, operation and maintenance and connection business, and finally realize the continuous deployment of the application center and the continuous release centered on business needs.
Third,Let efficient delivery lead to business success. Therefore, it is necessary to establish a closed loop of rapid execution and feedback between business exploration and continuous delivery.
The commonality of the above three points is that they all take business as the starting point. For example: drive the efficient collaboration of all links and departments in the organization with business requirements; Starting from business objectives, analyze business processes and decompose and design products; Connect business requirements and product application changes to realize continuous release of business requirements; Establish a fast closed loop between business exploration and continuous delivery.
To implement these practices, we must get through business (biz), development (DEV) and operation and maintenance (OPS), make them an efficient whole, build bizdevops practice system, empower organizations in the digital era, and accelerate business development and innovation.
The above is my share, thank you.
Learn more about the latest developments in cloud efficiency DevOps, WeChat search focuses on cloud efficiency official account.
Egg: public background reply [guide], can get the Alibaba DevOps Practice Guide & official account of “10 times research and development efficiency enhancement case”.
After reading it, I think it will help you. Don’t forget to like, collect and pay attention to it;