Fire-fighting meditation-thoughts on the final stage of the project

Original: http://blog.csdn.net/absurd/archive/2005/12/13/551588.aspx
Contact information of the author: Li xianjing <xianjimli at Hotmail dot com>

In the past few months, most of my spare time has been spent reading books on software engineering and compilation principles. Books on software engineering, including software requirements, risk management, agile modeling, system design, software project management, and some books similar to meditation.

In these books, I only talked about how to make the project develop healthily and finally successfully submit a product. Although they all do the same from different perspectives in different ways. But they almost all support the idea that planning + correction plans (not only design is iterative, but also planning is iterative ). In the words of one of the authors, what hurts you is not something you have not considered completely, but something you have not considered at all.

However, there is almost no book about the fire brigade. Alas, it's strange that foreigners claim that more than 50% of projects have failed, so fire is a common issue in their projects, why don't we talk about the fire fighting tactics? Do they also believe that the devil will not come to the door without naming it?

The only explanation is that it is too difficult to save fire. It may be that foreigners are far inferior to us, so they will not talk about it. I suffered a huge sacrifice in my previous project. under great pressure, I broke up with my girlfriend and suffered great mental and physical harm. Of course, I am not the only victim of that project. Many colleagues, they are very good and helpless. After that, I keep thinking that since 50% of projects will fire, the fire-fighting and planning capabilities are at least equally important. I think for a long time, recalling my previous experiences and searching for relevant materials, but I have little to learn.

The silver bullet that saves fire may never appear. I may write some of my own experiences, which may be helpful to everyone. It would be better if I could achieve the effect of throwing a brick and mortar:

1. In the fix
During the bug process, rebuild continues. If the design is not done well, redo is unlikely, but despair is meaningless. We can only improve it with an idea. Using previous experiences, we continuously refactor the code. Every time we fix a bug, we make the Code better, instead of worse. If we fix a bug, we will lose a bug in the code, instead of introducing more bugs. In fact, the biggest difficulty in refactoring is that there is no complete automatic test program and test cases, which makes it impossible for us to modify the code at all, or to minimize the changes, we should take some compromise measures, this makes the code constantly stinks. In this case, it is recommended to establish an automatic test and then constantly improve the test cases. I think it is not too late to establish an automatic test at any time. If it is really difficult to create an automatic test, list all the test cases and perform the test manually. At this time, the engineer's job is to rebuild.
Bug à test. Some people say that I don't have time to refactor, and I don't have time to test. Well, this reminds me that a person is running around a small circle, and when I am tired, I find that I am still saying that I have no time to see the direction.

2.
Pay attention to common functions. In the final stage of the project, do not be led by qa. If they find a bug, we fix it. Fix a bug, but fix
Bugs are not free. They require both costs and potential risks. The compilation optimization principle is based on: 20% of the Code took 80% of the time. If this principle is true, we recommend that 80% of users use only 20% of the functions. QA is not an end user. The difference between QA and end users is that QA tries its best to discover uncommon problems, and end users often use the most common functions. At this time, we can think of ourselves as end users and list the most common test cases. If they are not in these test cases, even if the bug is serious, we also need to consider whether to modify it.

3.
Determining which bugs do not change is equally important. This must be repeated with 2. In order to emphasize the need to put it forward separately. When analyzing software requirements, analysts believe that it is equally important to determine what is not in the system and what is in the system. Programmers tend to take two extremes in their attitudes towards bugs: one is that Lao Tzu does not change. How can I modify a QA statement. The former is often looked at with incorrect work attitude. The latter is regarded as a good child. In fact, in the final stage of the project, the latter may not be correct. As mentioned above, fix
Bug is not free. At this time, it is necessary to establish an arbitration commission and determine which bugs will not be changed.

4.
Bug classification, clear responsibility. I used to take over one module from another. More than 110 bugs in pending state already exist. It takes several hours to read every bug. If you change a bug, you will always feel like the trees are not in the forest. At first, I tried very hard to modify the bug, but the progress was still very small. Later, I spent a few days analyzing all the bugs carefully and summarized them into several categories: Bugs caused by other modules;
Bugs caused by interfaces with other modules; bugs that exceed requirements;
It is a bug in this module. Then, submit the bugs caused by other modules to relevant personnel, confirm the bugs caused by inconsistent interfaces, and submit the bugs beyond the requirement to the demand control board, finally, the bugs in this module are divided into several categories based on the causes of the bugs. In this way, these bugs are quickly fixed.

5.
Engineers should actively seek help. If you cannot solve the problem yourself, ask someone you know or ask your boss for help. Don't spend a lot of time out of your face or other reasons. In the final stage of the project, every minute is precious. Do not re-invent the wheel. Dedicated personnel should solve common problems.

6.
The project manager should take a global view. The project manager should pay more attention to global affairs and should not learn primary school students who only want to take big flowers. Don't just modify your own bugs. If you have fewer bugs, it doesn't mean that you are a good project manager. When the project fails, you have fewer bugs, it cannot really reduce your guilt. It is said that the software team follows the bucket principle. The lowest piece of wood is the deciding factor on how much water to install, not the highest piece. The project manager should keep an eye on which one is the lowest, and then fill it up. It makes no sense to become the highest one.

7. Person review to increase morale. Well, I don't know if there is any person
The term review is quite good. In the final stage of the project, morale is a very valuable thing. It can be said that morale is everywhere. In the previous company, every Monday, the boss calls every engineer to his office for a chat. The Chat content is not limited. Most of them ask you what problems and opinions you have on your work, after a very frank discussion, he will finally be encouraged and praised. He feels that this is very helpful for improving morale. Of course, the boss should be a good instigator.

8. Bug review. To create a bug Review Team, their main responsibilities are:
Discover common bugs and confirm which bugs need to be fixed. There are common bugs that can be solved or urged by dedicated personnel. Make sure that you have enough reasons for fixing a bug or not.

9.
Strengthen cooperation between QA and RD. Well, according to genetics and the survival principle of the fittest, in the final stage, bugs are very active and often take a long time to reproduce. In addition, the ambiguity of natural language itself is different from the focus on personal issues. QA may ignore the steps that RD makes important reproduction, QA bug descriptions may be quite different in RD's eyes. At this stage, it may save a lot of time to communicate with QA directly at the site. At the same time, we also need to respect the labor achievements of QA so that they can cooperate more actively.

10.
Experience accumulation. Every time you encounter a bug, think about why it appears, why it appears, and what will happen after you modify it. Keeping important records may inspire yourself and others to reduce the chance of making the same mistake.