Coding Compass —— to create a software factory like cloud and flowing water

This article is organized and updated based on the sharing made by , 16194e0be8ea81, Product Director of At the end of the article, you can go to the official website of the summit to watch the replay and download the PPT.

DevOps has moved from the tool stage to the process stage

Software engineering has developed from the 1960s to the present, and there is no doubt that it is in the era of DevOps, which is also confirmed by the industry's vigorous DevOps transformation in recent years. Up to this stage, companies have continued to invest in the transformation and landing for so many years, and they are eager to see results. Everyone is generally thinking about a question, that is, does DevOps really help business development and digital transformation, or is it just for the R&D team to cheer?

In the process of assisting customers in the implementation of DevOps products in the past year, we have become more and more aware: R&D management can really not only rely on building a tool chain, but also need to apply these tools to the actual business process of the enterprise. We should actually reduce the burden on development, rather than increase the burden on business development. Only in this way can we effectively improve the efficiency of research and development and better meet the needs of business development.

If we say that DevOps was still in the tooling stage before, and various tools are emerging one after another, then in the context of the rapid development of digital business, DevOps is entering a new stage: process stage .

Enterprises still have challenges in using DevOps tools

Starting from a typical user feedback, let’s take a look at the current user’s dilemma:

The above customer has used CODING in depth for more than a year, and they have enough say in whether the product is easy to use. By sorting out the feedback results, it can be seen that there are still deficiencies in the product in the tooling stage. On the one hand, the customer fully affirmed the original decision to choose CODING DevOps, each role in the team can work on a one-stop platform, well achieved the goal of R&D integration; on the other hand, despite our one-stop The platform provides the ability modules required by the team, but the collaboration between different modules is not yet well reflected.

1. For the product, the demand activities that it pays attention to are not well related to what the development is actually doing, so the progress and risks cannot be fully controlled.
2. For development, updating the task status is very important, but since this matter does not block oneself, whether to update in time depends entirely on the level of self-consciousness. So many times, developers who are busy with collaborative programming tend to forget to do this.
3. At the same time, as a relatively post-test, once the test is raised, various items are checked even more. It takes a lot of time to check and update various information. In addition, there is not much time left for testing. Especially embarrassing.
4. And let alone the operation and maintenance colleagues in the back, they can only repeatedly urge to make full preparations before the release, and all verification checks cannot be discounted, and then they can only pray that they will not always appear in the sensitive release window. Inexplicable question.

In general, although the different tools on the same platform are used smoothly by everyone, from the perspective of the whole process, I always feel that something is missing. Switching back and forth between tools still requires a lot of effort, and the correctness of the information cannot be ensured. All these are the shortcomings of tool-based products.

Companies increasingly pay attention to the overall efficiency of R&D management

This case is not a case, but a sign that DevOps transformation has come to a new process stage: Companies are increasingly concerned about the overall efficiency of R&D management, from emphasizing the local optimization of a certain tool to emphasizing the global optimization of collaborative processes.

Tools cannot be equated to overall efficiency. The classic theory of organizational effectiveness management PPT pointed out: Among the three elements of an organization, People and people are the foundation, Tools and tools empower people and make work more efficient, and Process , Process is the carrier for keeping people's behavior consistent with their goals. It is meaningless to complete something that you shouldn't have done perfectly, and it can even cause damage to the whole. Considering the overall situation, a good process is indispensable.

DevOps products should be built into a new type of production relationship that further liberates productivity

In the context of digitalization, the rapid development of business has brought about the high complexity of software systems, and individuals need to deal with more things, resulting in a decline in single-person efficiency. In order to improve the work efficiency of each role in the team, companies are pursuing DevOps transformation, hoping to use emerging technologies and tools to quickly improve team productivity. However, as the investment in technology and tools increases, and the size of the team continues to expand, it also brings complexity to the overall collaboration. These complex dependencies are transmitted to the team members layer by layer like a pyramid, forming a huge impact on the original work habits and even the understanding and cognition. Even a simple delivery requires many operations and the coordination of different roles, and the entire delivery process is therefore fragile and inefficient: for example, the lack of contracts and specifications between the upstream and downstream of the work, the lack of transparency in the research and development process, and the need for different tool platforms Switch back and forth between and so on.

How can different tools coexist organically in a complete process? How to create an efficient process for the team so that people can smoothly complete high-quality software development and release it to the production environment? In this process, team members do not need to deal with unnecessary complex issues, get caught in the minutiae, or wait for a long time and delay. We should liberate the productivity of team members so that development can focus on work that can truly generate business value. This is something worth thinking about now: Just like productivity determines production relations, we need more advanced R&D management products to empower R&D teams to meet the needs of today's digital business development.

CODING Compass: R&D process management product in the process of DevOps

By sorting out the problems that have been highlighted in the implementation of DevOps practice, we have come to the following two aspects:

1. DevOps transformation at the organizational level requires domain experts

In the "Survey Report on China's DevOps Status Quo (2021)" released by the Institute of Information and Communications Technology in July, it was pointed out that nearly 30% of enterprises lacked DevOps experts, which led to slow implementation. When we serve customers, we often need to provide consultations, through expert diagnosis, formulate procedures, and then set goals to be improved and specific implementation paths based on actual conditions. What DevOps products do is: extracts effective R&D management experience in the industry, and embeds it into the product, and guides the customer team to solidify excellent habits and continue to optimize, so as to achieve efficient R&D management.

2. The biggest pain point of team members in collaboration is "knowing everything"

Based on the existing tools provided, the team can initially collaborate with a simple understanding of DevOps. However, the collaboration problems faced by users do exist: for example, lack of cross-functional activities, lack of coordination specifications between activities, difficulty in identifying risks in the R&D process, too many contexts that individuals need to understand in their work, and Many cross-functional operations can only be handled manually and so on. These seem trivial, but the accumulated delays in solving these problems will cause great "heart loss" for team members, and even lead to outstanding employees' doubts about building an efficient organization.

The deep development of DevOps to the present stage represents the industry's new expectations for R&D management products: from agile to DevOps, combined with the concept of Lean lean thinking, it is developing in the direction of enhancing visualization and traceability, pursuing norms and efficiency. Based on the perceived pain points, CODING combined its own practice and industry achievements and experience, and made efforts to upgrade its products to help customers better improve their R&D management capabilities.

Compass = Workflow + Specification + Automation

Coding has created a brand-new R&D process management product Compass , including 3 main capabilities: (collaboration formed by various activities in series) workflow , and (standards for improving the consistency of R&D activities), specifications , 16194e0be8efa1 And (triggering post-activation) automation . It means that CODING DevOps integrates the Know-how part on the basis of the original DevOps tool chain, allowing customers to fully learn from the industry’s effective practical experience and achieve efficient R&D management.

How Compass Improves R&D Management Ability

Simply put, the product logic of Compass is to define processes, standardize processes, efficient circulation, identify bottlenecks and guide improvements.

1. First of all, there are various activities in the research and development process.

For example, product managers will create requirements into the backlog, team development planning will be included in the iteration, and task decomposition, task claim or assignment will be carried out, development will create branches, write code, submit and merge, etc., while testing is a design use case, Perform the test, and then the team raises the test, passes the quality access control, and creates a release order, etc.

We know that some of the roles listed here happen within the same role, while some require different roles to coordinate. In fact, there is a sequence of their progress.

2. Second, identify key collaborative activities and connect them in series to form a complete workflow.

After categorizing these activities according to different roles, you will find that some activities of the same role are objectively prerequisites for other activities. For example, after a requirement is created, it is possible to be included in the iteration. After the branch exists, the corresponding code submission and MR can be obtained. After the use case is designed, the corresponding requirement can be associated on its basis. These internal relationships have led to their activities to be completed spontaneously.

For the remaining key nodes, we artificially define their order of dependence from the perspective of overall R&D and according to actual work conditions, and connect them in series. For example, after the task is disassembled, the corresponding feature branch can be created. After the MR and the requirements are associated with the test case, the test can be raised, then the test is executed, the test report is issued, and the release form is finally submitted. This forms a complete workflow.

3. Once again, through regulations to ensure the robust flow of activities, and automation-driven activities for efficient circulation.

In order to ensure the robustness of the circulation of activities, we can set access and exit regulations for some of these activities, and give warnings and prevent the continued circulation if they do not comply with the regulations. For example, the requirements included in the iteration should be given acceptance criteria as a basis for use case design, and the pass rate in the test report must meet a certain value to create a release list, and so on. In addition, for certain activities that can be created or triggered in a standardized manner, automation rules can be set. When the prerequisites are met, it will automatically flow, and there is no need for team members to switch to another tool to update the status or manually create the next step of the task. In this way, an orderly teamwork workflow is formed.

4. Finally, map the specific R&D steps with the defined value stream stages of the business to provide insight and analysis.

Standardization and automation can produce accurate activity records, so as to provide real and reliable data for efficiency measurement, carry out effective insight diagnosis and guide improvement. For example, the difference between lead time and processing time, task completion rate/accuracy rate, etc. This is the foundation of Value Stream Management.

The above is the product design philosophy of Compass. We hope to drive development behavior in collaboration through the process, so that everyone in the process can focus on their own value. At the same time, the deposited process data can accurately see the research and development process, and based on the data insight analysis to guide the continuous improvement of the research and development process.

Summarize

CODING Compass is a R&D process management product based on CODING's original DevOps tool chain, including process orchestration, process driving, rule constraints and value transfer. It is hoped that it can help the company pull the manager’s goal expectations and the specific implementation of the R&D team together, and achieve the highest responsiveness with the smallest collaboration cost, thereby maximizing R&D efficiency.

Compass is currently undergoing internal testing, and it is expected to open public testing at the end of the year, so stay tuned!

Go to watch the CIF summit replay