Go to "mountain migration"

 

The software engineering instructor asked us to select a textbook, which is 《CodeDaquan, fast software development, and mountain migration. As a beginner, I compared the three books without prior knowledge, and finally chose "the path to mountains".

·Why did I choose "the path to mountains"?

1. the name of "The path to mountain migration" is too domineering to read, and everyone is very fond of value for money, especially Chinese people. Looking at the name, it seems like a method. "Dao" is a very profound problem, shortest method, deep can reach philosophy. With the teacher's recommendation, this book should not be poor, so the name attracted me first.

2. Looking at the thick "code Daquan", it shows you how to write code, such as code layout, comments, and testing. I gave up when I was not very busy. Although fast software development is not very thick, it is not good to compare it with the mountain migration path, and there are illustrations on the mountain migration. It looks quite interesting.

3. of course, when quickly reading these books, I found that "the path to mountain migration" is based on yugong's mountain migration, simulating the scenario. At the same time, the language is quite unique, and there are all kinds of network terms, classical Chinese, lyrics, and modern poetry, it looks attractive.

Based on the above three points, I chose "the path to mountains". Of course, we are here to learn. We are not busy reading this book, and we are also skeptical about this book. Are we going to develop software? Is this book reliable as a teaching material, it's not a waste of time to learn something. In this way, I began to read this book with confidence.

Because software engineering is actually a discipline that focuses most on practice, the best way is to move it out of practice. Software Engineering continues, books are reading, and many problems have been encountered in practice and reading. Next I will briefly discuss my problems and my ideas.

The search engine searches for "the biggest problem in software engineering". In many cases, it finds communication problems. At first, I felt confused, but I used daily scrum to discuss the problem together, individuals basically have their own ideas. Once the ideas are deviated, they will be reflected in the Code and products.

At the same time, in Chapter 2 "Vernacular MSF methodology", it was mentioned that MSF (Microsoft solution framework) has eight basic principles. Article 1 is foster open communications) it can be seen that information communication also plays an important role in MSF.

·How can this problem be solved?

Of course, we can use TFs for help. For example, all the information in TFs is retained and open, just like the fund flow records in the bank account, which cannot be deleted. This external objective restriction makes code and bugs public. Of course, in addition to powerful open communication tools such as TFS, we also have office software email, which can be used to send emails, schedule meetings, make phone calls, daily scrum, and communicate with each other through communicator chat tools. However, these are all tools. A large part of the solution is based on PM (project manager)

From this figure, we can see that PM is a button and a hub for upper-level bosses, customers, and teams. Once a communication error occurs at any stage, the project may fail, therefore, PM plays an important role in the team.

But will the risk factor of PM sitting at the core be very high? In fact, a good development team should reduce the risks of the team and avoid unnecessary communication problems in the team. At this time, I think the preliminary plan is a key step.

The preliminary plan is based entirely on the user's needs, the feasibility, the team's scale, and the team's level. Once the preliminary plan can be reasonably positioned and reasonably planned, we need to proceed step by step as planned. The preliminary plan is a consensus shared by everyone, and is finally assigned a work item that is imported into TFs by task. As long as the previous plan is reasonable and effective, it is very easy to develop later. You only need to work according to the work item, but you can only look at the small work. however, PM cannot be idle here. At this time, we need to do a good job of team communication and always observe everyProgramPersonnel Status, observe their progress, observe the problems they encounter, stand on the top, ensure the overall progress of the team, and ensure the overall work efficiency of the team.

Of course, the Project Manager cannot simply break down the work. Although the simple decomposition will lead to the convenience of project management, in fact, this kind of common layer project management method seems convenient, it seems that the "engineering method" of the module layer-by-layer subdivision is actually the lowest level. Because once there is a problem, we must start from scratch.

The Project Manager cannot be a strong manager. If you feel that you are a manager, you can make the superiors have high requirements on programmers and humiliate the programmers once they do not. I think the project manager should be at the bottom, but the highest level of thinking. The bottom layer of the role allows everyone to raise a difficult question, without having to fear the project manager, so that programmers can truly be themselves, without having to consider other factors. In this way, PM has mastered the status of first-hand programmers, facilitating coordination, problem prevention, and problem solving. At the highest level of thinking, PM should understand optimization, the seriousness of a problem, the impact of a problem, or even the impact of several problems. How can we optimize the time and progress function? Only in this way can we identify the problem and assign the task priority to solve the problem quickly and reasonably.

·What should I do if the assessment indicators are too rigid?

Because of the complexity and uncertainty of program development, it is difficult to quantify the work, and the specific progress of developers is often estimated, which is influenced by personal experience, personal ability prediction, and other factors, there is a lot of uncertainty. It is unfair to simply consider the developers' "progress" indicators from the Progress. Especially when we are just stepping into software engineering, we are not very familiar with development, however, the progress is often determined by our management (boss) and project managers. The technical layer has little decision on the progress. The progress is exactly done by the program developers working on the front line. It is possible that the project requires an ambiguous progress requirement, which the project team has to accept. There are a lot of statistics on the Internet. For example, in software development projects in the United States, more than 70% of projects have been extended, and nearly 31% of projects have to be terminated or abandoned due to schedule reasons.

Therefore, a fully-fixed progress assessment may easily lead to fatigue, low morale, and reduced initiative, thus affecting the stability of the project team.

How can this problem be solved?

In the book "The path to mountain migration", it measures the quality of employees' work (Dev) mainly by two indicators.

(1) Check in quality, that is, the number of times the check in destroys the build

(2) Whether the function is completed on schedule, and whether to communicate with each other in advance if the function is extended

For the overall benefit of the team, we must work hard to complete the plan on time and reflect the rigid side. However, if Dev is really serious and the task is not completed, if it is postponed, there must be a reasonable mechanism, that is, the issue of communication and coordination. When a problem cannot be solved, the PM report should be generated in time so that the PM can preliminarily assess the priority of the task and the impact. If the priority is high, contact other personnel for help. Of course, developers should also do some software development training at ordinary times.

I have explained two common questions in combination with books and practices. Let's talk about some interesting things in this book.

· Do you have to clear the truth?

The author cited in this book that although the referenced items cannot be correctly queried one by one, every time I read them, I feel that a modern software engineering is combined with the Chinese philosophy, or I feel that it is the essence of Chinese culture that can be embodied in software engineering.

At the beginning, the author directly cited Zhu Xi's "view of books" Ask the channel to clear such, to have a source of live water ".

I don't quite understand it, because the first eight chapters are the basis of vsts and MSF. What is the "Source" of the book? The book "clear like this ". In fact, vsts is a tool developed by Microsoft for many years. MSF is a methodology. According to this understanding, it is easy to estimate. Since MSF is a method, it should be the source, only when the high-level approach is pragmatic, feasible, and effective will there be a steady stream of living water. In addition, you can regard vsts as a "water channel", follow the "water channel" to find the root, and trace the source to find MSF. Microsoft has been a leader in the IT industry for many years. The summary of the product team development experience and lessons should have been verified by others, so this source should be pure and can withstand the test of time.

In English, you can move mountains as a symbol of the miracle. The specific implementation of the author's software engineering is compared to the difficulty of migration. However, mountain migration is a step of human progress. If we want to be rich, we need to build roads first, clear the roads, and remove the mountains above, which means that the development of software engineering is very interesting and infinite. In these thousands of difficulties, the author gave two "methods": MSF and vsts. The former is an idea, while the latter is a method tool.

This book is indeed creative, but since I was just engaged in software development, there are many problems in the book, and I don't feel much about it. So I dare not comment falsely, but the online comments are very good. The author wrote this sentence: "I once recommended this book to the college of software. The feedback is that this book is" too active "and should not be used for teaching ." Haha, it may be too lively. In this case, we talk about ancient things. In this case, we talk about sentiment and things. In this case, we refer to the poems and use the poems. In this case, we talk about the combination of Chinese and Western ". History, love, lyrics, celebrities, foreign, and software engineering are the core. If colleges and universities reference this teaching material, how can teachers feel?

Finally, I was very touched: the author of this book completed it in his spare time. As a project development manager, everyone knows that it must be very busy. I really don't know how the author's time is squeezed out. Curious and admired.

 

By Haifeng Liu