Mid-term Summary, Answers to 3 Typical Questions and How to Study Efficiently #

Hello, I am Shi Xuefeng. Unconsciously, the column has been online for almost two months, and overall progress has exceeded half. At the beginning of writing this column, I set a small goal for myself: to treat every comment seriously. So far, just replying to comments, I have already written more than 30,000 words.

In fact, for me, every time I read and reply to comments, it is a process of continuous reflection and learning. In reality, many times, many comments and discussions are even more exciting and down-to-earth than the articles themselves.

Today is the mid-term summary, and I will divide it into two parts:

• Part 1: I have selected 3 typical questions from numerous comments and will further explain them.
• Part 2: I want to talk to you frankly. Two months of intensive writing has also made me re-examine “how to study effectively” from the perspective of a lecturer. I will share these thoughts with you in the hope of helping you improve yourself.

Typical Problems #

First, let’s look at some typical problems.

Problem 1 #

Agile development mode does not spend a lot of time studying the business. Will this result in a deviation of direction and even find that the overall business architecture is unreasonable and require rework halfway through system development?

As you may know, implementing DevOps helps deliver products quickly and with high quality. So, I want to ask: Does delivering quickly and with high quality necessarily mean business success? Obviously, it’s not that simple.

In fact, there are many factors that affect business success, such as industry trends, product competitiveness, user consumption habits, policies, laws, and regulations, and so on. Among these many factors, the quality of requirements, or in other words, whether the requirements are reliable, is also important.

After all, if a bunch of useless requirements are delivered, it not only cannot improve the business but also wastes a lot of time and energy, missing out on truly valuable opportunities.

We are living in a rapidly changing era, and companies are not clear about what users want. Many requirements are made by people’s guessing. How much is the value of a new requirement? It is not only difficult to predict but also difficult to measure.

Therefore, product teams tend to use the “casting a wide net” approach to propose a lot of requirements to increase the chances of hitting the mark. After all, if one guess is wrong, then guess again.

From this perspective, whether using the agile development mode or the waterfall development mode does not directly depend on whether the requirements are reliable. Even in the waterfall model, there are still cases of “great efforts resulting in tragedies,” such as the Iridium satellite project of Motorola.

Since it is impossible to predict in advance whether the requirements are reliable, solving this problem requires close collaboration between the business team and the delivery team.

From the business side, it is necessary to adopt the lean startup mindset, decompose the requirements through the minimum viable product, and reduce the trial and error cost in the market through prototype products. This leads to the introduction of a series of means and methods I mentioned in the lecture on “Business Agility”, such as impact mapping, Kano model, user stories, and so on. The core of these methods is to adopt a continuous iteration and small steps approach to obtain market feedback. It is precisely because of this that the agile development mode, which is more flexible and embraces change, is widely accepted.

After discussing the business side, let’s take a look at the delivery side.

After an idea is proposed, it needs to go through the software development and delivery process before it can be finally delivered to users. Therefore, every possible means should be used to shorten the duration of this delivery chain.

If the development time cost is fixed, then the remaining part is the problem that various engineering practices in DevOps try to solve.

For example, by using continuous integration to reduce the cost of solving software integration issues and the cost of fixing software defects discovered at the last minute; by using automated testing to reduce the cost of executing a large number of manual regression test cases and the cost of fixing existing functions due to new features. Other parts of the software delivery process are mainly the same, which is also the reason why each field has its own collection of practices. On the other hand, after the feature is launched, it is still necessary for the delivery side to extract, summarize, and provide timely feedback on key performance indicators to demonstrate the reliability of the requirements and help the business side make more informed decisions. Stop the features that are not performing well in a timely manner, and allocate more resources to the features that are performing well.

In this way, the business side breaks down and analyzes the requirements, reducing the granularity of the requirements and improving their reliability; the delivery side’s engineering practices greatly shorten the delivery cycle, improving the overall quality. This helps the business validate more requirements without increasing costs. The lower the cost and the higher the frequency of this process, the higher the chances of survival and overall competitiveness of the company. This is also the core problem that DevOps seeks to solve.

Question 2 #

The company doesn’t pay much attention to configuration management. Are there any good practical methods to establish a complete configuration management system?

In Lecture 10 of the column (Chinese content) that I shared, I introduced the knowledge of configuration management based on four core principles, which resonated with many students.

Indeed, as a long-neglected but particularly important practice, configuration management is not only the foundation of many DevOps engineering practices but also the culmination of engineering capabilities.

Because of this, the construction of a configuration management system is not just about doing configuration management well. In fact, it also depends on the joint implementation of other engineering practices.

As for how to implement configuration management, let me share a case with you.

In this company, there was no dedicated configuration management team at first, and software integration and release were managed by the development teams themselves. The opportunity to establish a configuration management system arose when the company decided to accelerate the release rhythm from one version every three weeks to one version every two weeks. While it seems like only one week has been shaved off the release cycle, as I demonstrated in Lecture 4 of the column (Chinese content) with the deployment gravity map, achieving this goal requires effort from all aspects, including configuration management.

Therefore, the company decided to introduce the role of configuration management. In the early stages, they focused on two things:

• Redefining branch strategies, transitioning from long-lived branches to a short-lived branch plus feature branch model;
• Managing integration permissions, transitioning from unlimited integration at any time to controlled integration according to version cycles.

In this process, the configuration management team redefined the directory structure and storage method of the code repository and established an online testing platform based on the development process, thereby achieving the onlineization of the development process and automating permission management.

Next, by combining configuration management with platforms and processes, the development process starts to expand forward and backward.

• Forward ：During the requirement management stage, establish specifications for the relationship between requirements and code, strictly enforce code submission checks, and include build tools and environment configurations in unified control with historical change traceability.
• Backward ：During the deployment and operation stage, define version release and deployment rules, establish a single trusted release channel, and provide unified access to information about all formal release versions, including the associated requirements, code, and test information. After the team got on track with orderly development, they gradually strengthened the construction of the platform and automation capabilities to address the identified problems.

• Code submission out of control: Integrate online, automatically merge code after passing testing and acceptance.
• Large environment differences: Achieve unified initialization through containerization and server configuration management tools.
• Slow build speed: Improve build speed through network transformation and incremental compilation, etc.

As a result, the process of version release, which used to be time-consuming and labor-intensive, has become a one-click operation, and the team has also achieved the goal of bi-weekly version release.

In this case, configuration management is more focused on processes and platforms, reshaping the entire development collaboration and delivery process through rule formulation, access control, unified information sources, and version control means.

Therefore, based on grasping the principles, in the face of various practices, it is best to determine which practices can solve practical problems by reverse deduction from the expected results.

If you are not sure where to start, you can check whether the current software delivery process is driven by configuration management, whether there are any data in a state of being out of control and chaotic, and whether the information about versions is unable to be fully traced. If so, then there is much to be done.

In summary, any company that wants to implement configuration management can start with standardization, then move to automation, and then move on to data management and service-oriented approach. This is a relatively universal path and a general guide to implementing configuration management.

Question 3 #

How should metrics be associated with organizations and individuals? With so many metrics, how should they be connected to projects?

In the 19th lecture, I introduced the practice of positive metrics, which triggered a small climax. After the article was published, many students added me as a friend and had in-depth discussions with me about measurement construction. This shows that currently, enterprise research and development measurement is a popular topic.

However, metrics, the more you do, the more you will find, is an endless endeavor. So, at the very beginning, are there any reference steps that can guide practice? Of course, there are. I have summarized four steps: finding the starting point, focusing on the bigger picture, identifying gaps, and classifying into levels.

Step 1: Finding the starting point.

For the construction of a measurement system, many companies are actually very similar. At the beginning, the core is to have a starting point to sort out the entire development process. This starting point is often the requirement. Because requirements are the only thing that runs through the entire development and delivery process.

Of course, you can also think about whether there are other options besides requirements. So, the core indicators around requirements are the first thing that needs to be extracted. If there is no information on the flow time of a requirement at each stage of the delivery cycle, then that measurement is unacceptable.

Step 2: Focusing on the bigger picture.

Focusing on the bigger picture means that after the measurement system extracts and calculates indicator data according to the definition of the indicators, the most important thing is to verify the truth and validity of the data and make the team recognize this objective data.

Often, if a company does not have an authoritative set of indicators, each department and system will have their own measurement standards. If this issue is discussed without consensus, it would be basically meaningless. Therefore, in essence, these figures must be accepted by the team.

Step 3: Identifying gaps.

Having a starting point and crucial figures, and gaining recognition for the objectivity and effectiveness of the measurement data, there are still obvious inconsistencies in some areas at this stage. At this time, further breakdown of this domain is needed. For example, the testing cycle is only a number in the larger stages, but in fact, it includes many processes; such as functional testing, product review, and buried point testing, etc.

If the surface problems are not broken down into the actual situation of each step, it would be difficult to clarify which step is causing the problem. So, under the premise of reaching consensus, identifying content that can be improved is a milestone.

Step 4: Classifying into levels.

Not all metrics can be associated with individuals. For example, does it feel strange to calculate an individual’s requirement prepose period? The same goes for metrics like application crash rates, which are difficult to attribute to a specific department.

Therefore, we need to divide metrics according to different perspectives and dimensions. For example, we can divide them into organizational-level metrics, team-level metrics, and project-level metrics.

The core of dividing metrics is from large to small, starting from the target audience of the metrics and the problems they are trying to solve. Break them down step by step to reach the root cause of the problem, such as user operation issues, data calculation issues, automation platform issues, etc. This is a very meticulous work.

Let’s review. We have just analyzed three typical DevOps problems in detail.

First, you need to clearly understand that when facing unknown requirements, DevOps has a problem-solving method and approach, which is to analyze reliable requirements from the business side and deliver them with the fastest and lowest cost from the delivery side. They are inextricably linked and share the same fate.

Configuration management, as the core foundational practice of DevOps, is not limited to a single domain during implementation. In fact, it should be driven by optimizing the research and development process, enabling standardization, automation, and data visualization.

Finally, regarding metrics, what you should pay attention to is that upwards, they should support core indicators; downwards, they should be decomposed layer by layer to show real details.

After explaining these three typical problems, we will enter into Part 2, which is also the part I strongly requested to add. In fact, I just want to talk to you about my feelings.

How to Study Efficiently? #

Just like you, I am also a user of Geek Time, subscribed to many interesting courses. During the learning process, I have always been thinking about how to study efficiently in limited time. It wasn’t until I became a course instructor myself and thought about this issue from both the perspective of a user and a teacher that I gained some insights I would like to share with you.

Busy is a true reflection of the lives of most people today. We are busy from morning till night, busy with work, busy with meetings, busy with scrolling through our phones… Busy to the point of being overwhelmed.

However, if you were to ask yourself what you were busy with the previous day, either your mind was completely blank or you were just going through a list-like account of what you did. It can be seen that many of the things we are busy with every day are not really valuable.

In fact, many things are not as important as we imagine. We often focus on what is right in front of us and make it the whole world. But if we were to extend the time frame to a week or even a year, you would find that these things make little difference whether we do them or not.

Because we are always in a busy state, setting aside a dedicated period of time for learning becomes a luxury. But I congratulate you because at least you are more conscious and aware than most people, willing to use bits of fragmented time to enrich yourself.

Since you have spent such precious time, you certainly hope to gain something from it, whether it’s in terms of knowledge, skills, or insights, so as not to waste this time in vain.

So, I want to ask you: have you really gained anything?

Stephen Covey once said that most people listen with the intent to reply, but not with the intent to understand.

Most people listen with the intent to reply, but not with the intent to understand.

The “intent to reply” mentioned here may be a bit exaggerated, but in reality, I find that when I am engaged in communication, my mind unconsciously imagines how to respond to the other person instead of listening attentively to what they are saying, understanding their intentions and emotions.

So, you see, this way of listening is always influenced by our inherent thought patterns. In other words, we often put ourselves in the position of a commentator.

So, what is the identity of a commentator? It means standing in a position detached from the matter, taking a critical perspective to view everything, and trying to find some problems. Of course, these problems are discovered within the limits of our existing knowledge.

This feedback is actually a good thing for the producer of knowledge because it allows them to constantly examine and reflect on themselves, and find their shortcomings.

But for learners, can we temporarily give up the identity of a commentator and become a practitioner during the learning process?

For example, taking Geek Time’s column as an example, what different perspectives do you have on the content mentioned by the author? Faced with the same question, what better approaches do you have?

In fact, every author has their own unique insights, which is why they are authors. So, being able to make use of their thoughts, complement our own knowledge with theirs, and become winners in communication is a better choice that honors our time.

Finally, taking Geek Time’s column as an example, I believe that:

• A 60-point experience means that you have read all the manuscripts, not just listened to the audio of the course;
• A 70-point experience means that you have studied the additional resources in the manuscripts carefully, such as code, flowcharts, and supplementary learning information. These are selected contents that can help you expand your knowledge beyond the 15-minute limit;
• An 80-point experience means that you actively participate in the comments and discussions of the column and even engage in deep conversations with the author about your own questions, establishing a connection;
• A 90-point experience means that you can combine the practical scenarios in your work to give your own thoughts and answers, accumulate a whole set of knowledge system of your own, and even output it to others;
• A 100-point experience means continuous improvement. I think having the mindset to continuously improve is probably more important than the 100-point milestone itself.

So, how many points of experience do you want to achieve? You can think about it for yourself.

Alright, moving on, we are about to enter the “Tools and Practices” section. I hope you can maintain your enthusiasm for learning, persist, and look forward to the occurrence of great things naturally.

Discussion Questions #

Do you have any points of confusion about the content that has been updated so far? Or during your implementation process, do you have any questions?

Feel free to leave your thoughts and answers in the comment section. Let’s discuss together and learn from each other’s progress. If you found this article helpful, please feel free to share it with your friends.